* [gentoo-musl] [GSoC] native-clang: daily report 06/29
@ 2016-06-29 15:52 Lei Zhang
2016-06-30 8:59 ` Jens Staal
[not found] ` <6ebcb95d-409a-cbb1-6980-cf8688901164@gentoo.org>
0 siblings, 2 replies; 6+ messages in thread
From: Lei Zhang @ 2016-06-29 15:52 UTC (permalink / raw
To: Luca Barbato, soc-admins, gentoo-musl
Plan for today:
- investigate clang's poor performance
- study catalyst and stuff
Progress:
- I find out that optimization flags are not correctly passed to
compiler when building the freestanding clang. The cause is a bit
complicated:
clang has to be built in-tree (i.e. along with LLVM); compiler-rt can
be built out-of-tree, but it's a little inconvenient so I also built
it in-tree. This means clang, compiler-rt and LLVM are built
all-together. compiler-rt's sanitizer has some issue with musl, so I
disabled building the sanitizer via some option. It turns out this
option somehow leads cmake to forget passing optimization flags to
compiler. The solution is simple: build compiler-rt out-of-tree. Or I
can resolve the issue between compiler-rt's sanitizer and musl, when
I've got time...
- I'm thinking about how to glue all the parts together. Now I have a
seed tarball by putting the freestanding clang and C++ libs into it,
but some pieces are still missing before I'm able to build stage1-3
tarballs. To name a few:
1. How do I tell catalyst to compile the kernel with gcc, while
compile user space stuff with clang? Is this achievable by simply
creating a customized profile (likely based on hardened musl)?
2. I need some special flags to build the freestanding clang, libc++,
etc, so probably I need an overlay or something to override their
default ebuilds
3. I need to create ebuilds for compiler-rt, libcxxabi and NetBSD's
crtbegin/end; perhaps I should also replace libcxxrt in the default
repository with libcxxabi
4. gcc-config doesn't support clang; I need to fix that (the name
"gcc-config" will be misleading)?
These are too many things to do at once... I'd better sort them out
first. Advice?
Plan for tomorrow:
- study catalyst and stuff
Lei
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [gentoo-musl] [GSoC] native-clang: daily report 06/29
2016-06-29 15:52 [gentoo-musl] [GSoC] native-clang: daily report 06/29 Lei Zhang
@ 2016-06-30 8:59 ` Jens Staal
2016-06-30 9:24 ` Lei Zhang
[not found] ` <6ebcb95d-409a-cbb1-6980-cf8688901164@gentoo.org>
1 sibling, 1 reply; 6+ messages in thread
From: Jens Staal @ 2016-06-30 8:59 UTC (permalink / raw
To: gentoo-musl
On onsdag 29 juni 2016 kl. 23:52:38 CEST Lei Zhang wrote:
> 1. How do I tell catalyst to compile the kernel with gcc, while
> compile user space stuff with clang? Is this achievable by simply
> creating a customized profile (likely based on hardened musl)?
Alternatively, make a package with patches from www.llvmlinux.org and not ship
gcc at all in the stage 3 musl/clang/libc++ tarball?
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [gentoo-musl] [GSoC] native-clang: daily report 06/29
2016-06-30 8:59 ` Jens Staal
@ 2016-06-30 9:24 ` Lei Zhang
0 siblings, 0 replies; 6+ messages in thread
From: Lei Zhang @ 2016-06-30 9:24 UTC (permalink / raw
To: Jens Staal; +Cc: gentoo-musl
2016-06-30 16:59 GMT+08:00 Jens Staal <staal1978@gmail.com>:
> On onsdag 29 juni 2016 kl. 23:52:38 CEST Lei Zhang wrote:
>> 1. How do I tell catalyst to compile the kernel with gcc, while
>> compile user space stuff with clang? Is this achievable by simply
>> creating a customized profile (likely based on hardened musl)?
>
> Alternatively, make a package with patches from www.llvmlinux.org and not ship
> gcc at all in the stage 3 musl/clang/libc++ tarball?
Thanks for mentioning it. I have considered that option. To do that
both clang and the kernel need patching and I have no idea how well
they work. For now I prefer the lazy route: just use gcc to compile
the kernel.
BTW, I've met with some packages that simply won't be built by clang
due to its lack of support for some GNU extensions, so I'm really not
sure if it's wise to not ship gcc at all...
Lei
^ permalink raw reply [flat|nested] 6+ messages in thread
* [gentoo-musl] Re: [GSoC] native-clang: daily report 06/29
[not found] ` <6ebcb95d-409a-cbb1-6980-cf8688901164@gentoo.org>
@ 2016-06-30 15:40 ` Lei Zhang
[not found] ` <8f6ced62-ed80-fc11-346c-fd72b1a1b3e6@gentoo.org>
0 siblings, 1 reply; 6+ messages in thread
From: Lei Zhang @ 2016-06-30 15:40 UTC (permalink / raw
To: Luca Barbato; +Cc: soc-admins, gentoo-musl
2016-06-30 15:48 GMT+08:00 Luca Barbato <lu_zero@gentoo.org>:
> On 29/06/16 17:52, Lei Zhang wrote:
>> Plan for today:
>> - investigate clang's poor performance
>> - study catalyst and stuff
>>
>> Progress:
>> - I find out that optimization flags are not correctly passed to
>> compiler when building the freestanding clang. The cause is a bit
>> complicated:
>>
>> clang has to be built in-tree (i.e. along with LLVM); compiler-rt can
>> be built out-of-tree, but it's a little inconvenient so I also built
>> it in-tree. This means clang, compiler-rt and LLVM are built
>> all-together. compiler-rt's sanitizer has some issue with musl, so I
>> disabled building the sanitizer via some option. It turns out this
>> option somehow leads cmake to forget passing optimization flags to
>> compiler. The solution is simple: build compiler-rt out-of-tree. Or I
>> can resolve the issue between compiler-rt's sanitizer and musl, when
>> I've got time...
>
> Sounds a good plan =)
I just found that compiler-rt is built as part of clang/LLVM in the
default ebuilds. Perhaps I should leave it that way: not to create a
new package for compiler-rt. That means compiler-rt still needs to be
built in-tree, and I'll have to deal with the optimization flag issue.
I also noticed that gcc's sanitizer doesn't work on the musl based
system, so is it forgivable to not support clang's sanitizer either?
(clang's sanitizer is implemented in compiler-rt)
Lei
^ permalink raw reply [flat|nested] 6+ messages in thread
* [gentoo-musl] Re: [GSoC] native-clang: daily report 06/29
[not found] ` <8f6ced62-ed80-fc11-346c-fd72b1a1b3e6@gentoo.org>
@ 2016-07-01 1:58 ` Lei Zhang
2016-07-01 5:01 ` Felix Janda
0 siblings, 1 reply; 6+ messages in thread
From: Lei Zhang @ 2016-07-01 1:58 UTC (permalink / raw
To: Luca Barbato; +Cc: soc-admins, gentoo-musl
2016-06-30 23:50 GMT+08:00 Luca Barbato <lu_zero@gentoo.org>:
> On 30/06/16 17:40, Lei Zhang wrote:
>> I also noticed that gcc's sanitizer doesn't work on the musl based
>> system, so is it forgivable to not support clang's sanitizer either?
>> (clang's sanitizer is implemented in compiler-rt)
>
> package mask the useflag for now, it is less important.
>
> Make sure to open a bug about it on llvm and gcc.
compiler-rt's sanitizer uses some non-POSIX features like <obstack.h>;
I guess gcc's situation is similar. It's not necessarily a bug though.
Actually compiler-rt uses stuff like "#if __linux__ && !__ANDROID__"
to protect code that uses GNU extensions. The fix is simple: replace
it with "#ifdef __GLIBC__". But I'm not sure if this fix has unwanted
impact on other libc like uclibc. It looks uclibc supports certain GNU
extensions that are absent in musl, like <obstack.h>.
Lei
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [gentoo-musl] Re: [GSoC] native-clang: daily report 06/29
2016-07-01 1:58 ` Lei Zhang
@ 2016-07-01 5:01 ` Felix Janda
0 siblings, 0 replies; 6+ messages in thread
From: Felix Janda @ 2016-07-01 5:01 UTC (permalink / raw
To: Lei Zhang; +Cc: Luca Barbato, soc-admins, gentoo-musl
Lei Zhang wrote:
> 2016-06-30 23:50 GMT+08:00 Luca Barbato <lu_zero@gentoo.org>:
> > On 30/06/16 17:40, Lei Zhang wrote:
> >> I also noticed that gcc's sanitizer doesn't work on the musl based
> >> system, so is it forgivable to not support clang's sanitizer either?
> >> (clang's sanitizer is implemented in compiler-rt)
> >
> > package mask the useflag for now, it is less important.
> >
> > Make sure to open a bug about it on llvm and gcc.
>
> compiler-rt's sanitizer uses some non-POSIX features like <obstack.h>;
> I guess gcc's situation is similar. It's not necessarily a bug though.
>
> Actually compiler-rt uses stuff like "#if __linux__ && !__ANDROID__"
> to protect code that uses GNU extensions. The fix is simple: replace
> it with "#ifdef __GLIBC__". But I'm not sure if this fix has unwanted
> impact on other libc like uclibc. It looks uclibc supports certain GNU
> extensions that are absent in musl, like <obstack.h>.
uclibc defines also __GLIBC__. So changing from
"#if __linux__ && !__ANDROID__" to "#ifdef __GLIBC__" doesn't mean any
change for uclibc. (Code not working on uclibc would need to use
"#if __GLIBC__ && !__UCLIBC__".) However notice that there are non-linux
systems using glibc (kFreeBSD & Hurd), so (if they are relevant here)
the test might need to be "#if __linux__ && __GLIBC__".
Felix
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2016-07-01 5:03 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-06-29 15:52 [gentoo-musl] [GSoC] native-clang: daily report 06/29 Lei Zhang
2016-06-30 8:59 ` Jens Staal
2016-06-30 9:24 ` Lei Zhang
[not found] ` <6ebcb95d-409a-cbb1-6980-cf8688901164@gentoo.org>
2016-06-30 15:40 ` [gentoo-musl] " Lei Zhang
[not found] ` <8f6ced62-ed80-fc11-346c-fd72b1a1b3e6@gentoo.org>
2016-07-01 1:58 ` Lei Zhang
2016-07-01 5:01 ` Felix Janda
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox