musl-llvm and crtbegin/crtend

musl-llvm and crtbegin/crtend

[writeonce]

Greetings,

First issue, and probably an easy fix, is the link to crtbegin.S and 
crtend.S on the musl wiki page entitled BuildingLLVM.  The current links 
are broken, and should (probably) point to 
http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/csu/ (the actual files are 
under arch/{$ARCH}

More importantly, though: from very recent communication on the clang 
developer list, it is my understanding that the NetBSD crtbegin/crtend 
are the _de facto_ standard for self-hosting clang toolchains.  If that 
is the case, does anyone know of a special license exception pertaining 
to these files?  If I read the license correctly, then every binary 
containing the resulting crtbegin.o and crtend.o would have to include a 
copy of the license with its documentation.  If there is such exception, 
then I'd suggest that the wiki page includes a link to it.

Kind regards,
zg

Re: musl-llvm and crtbegin/crtend

[Rich Felker]

On Tue, Apr 22, 2014 at 05:53:14PM -0400, writeonce@midipix.org wrote:
> Greetings,
> 
> First issue, and probably an easy fix, is the link to crtbegin.S and
> crtend.S on the musl wiki page entitled BuildingLLVM.  The current
> links are broken, and should (probably) point to
> http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/csu/ (the actual files
> are under arch/{$ARCH}
> 
> More importantly, though: from very recent communication on the
> clang developer list, it is my understanding that the NetBSD
> crtbegin/crtend are the _de facto_ standard for self-hosting clang
> toolchains.  If that is the case, does anyone know of a special
> license exception pertaining to these files?  If I read the license
> correctly, then every binary containing the resulting crtbegin.o and
> crtend.o would have to include a copy of the license with its
> documentation.  If there is such exception, then I'd suggest that
> the wiki page includes a link to it.

I'm not aware of this, but you might want to check and see if this
junk is even needed. My understanding is that these files do nothing
useful whatsoever unless you're using the old _init/_fini based
ctor/dtor system. GCC at least has switched to generating __init_array
and __fini_array which are much saner and I would guess clang has too.

Note that these files aren't needed at all for pure C code anyway,
only for C++, GNU C, or other langs with static ctors/dtors.

Rich

Re: musl-llvm and crtbegin/crtend

[writeonce]

On 04/22/2014 06:38 PM, Rich Felker wrote:
> On Tue, Apr 22, 2014 at 05:53:14PM -0400, writeonce@midipix.org wrote:
>> Greetings,
>>
>> First issue, and probably an easy fix, is the link to crtbegin.S and
>> crtend.S on the musl wiki page entitled BuildingLLVM.  The current
>> links are broken, and should (probably) point to
>> http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/csu/ (the actual files
>> are under arch/{$ARCH}
>>
>> More importantly, though: from very recent communication on the
>> clang developer list, it is my understanding that the NetBSD
>> crtbegin/crtend are the _de facto_ standard for self-hosting clang
>> toolchains.  If that is the case, does anyone know of a special
>> license exception pertaining to these files?  If I read the license
>> correctly, then every binary containing the resulting crtbegin.o and
>> crtend.o would have to include a copy of the license with its
>> documentation.  If there is such exception, then I'd suggest that
>> the wiki page includes a link to it.
> I'm not aware of this, but you might want to check and see if this
> junk is even needed. My understanding is that these files do nothing
> useful whatsoever unless you're using the old _init/_fini based
> ctor/dtor system. GCC at least has switched to generating __init_array
> and __fini_array which are much saner and I would guess clang has too.
>
> Note that these files aren't needed at all for pure C code anyway,
> only for C++, GNU C, or other langs with static ctors/dtors.
>
> Rich
>
>
Thanks, Rich.  From the sources of gcc (4.6 -- 4.8) and llvm/clang (3.4 
-- trunk) it appears that gcc introduced __init_array in version 4.7;  
when used, __do_global_ctors_aux is absent, however the implementation 
of __do_global_dtors_aux is still there (in crtbegin.o).

When clang invokes the linker, it asks for crtbegin.o and crtend.o to be 
included regardless of the executable type (c/c++), which might be worth 
a patch (clang/lib/Driver/Tools.cpp).  On the other hand, it does 
support __init_array (by default, I believe, and also through 
-fuse-init-array), and there are also relevant bits in the code for 
llvm's native linker (lld).

Given that clang also supports the old ctor/dtor system (through 
-fno-use-init-array), the status of crtbegin/crtend seems to be still 
relevant.

zg

Re: musl-llvm and crtbegin/crtend

[Rich Felker]

On Wed, Apr 23, 2014 at 04:47:55AM -0400, writeonce@midipix.org wrote:
> Thanks, Rich.  From the sources of gcc (4.6 -- 4.8) and llvm/clang
> (3.4 -- trunk) it appears that gcc introduced __init_array in
> version 4.7;  when used, __do_global_ctors_aux is absent, however
> the implementation of __do_global_dtors_aux is still there (in
> crtbegin.o).
> 
> When clang invokes the linker, it asks for crtbegin.o and crtend.o
> to be included regardless of the executable type (c/c++), which
> might be worth a patch (clang/lib/Driver/Tools.cpp).  On the other
> hand, it does support __init_array (by default, I believe, and also
> through -fuse-init-array), and there are also relevant bits in the
> code for llvm's native linker (lld).
> 
> Given that clang also supports the old ctor/dtor system (through
> -fno-use-init-array), the status of crtbegin/crtend seems to be
> still relevant.

My point was just that if you're using exclusively new .o files built
with init-array, I think it's possible to compile without crtbegin.o
and crtend.o (or equivalently, with empty .o files dropped in their
place).

Rich

Re: musl-llvm and crtbegin/crtend

[writeonce]

On 04/23/2014 10:47 AM, Rich Felker wrote:
> On Wed, Apr 23, 2014 at 04:47:55AM -0400, writeonce@midipix.org wrote:
>> Thanks, Rich.  From the sources of gcc (4.6 -- 4.8) and llvm/clang
>> (3.4 -- trunk) it appears that gcc introduced __init_array in
>> version 4.7;  when used, __do_global_ctors_aux is absent, however
>> the implementation of __do_global_dtors_aux is still there (in
>> crtbegin.o).
>>
>> When clang invokes the linker, it asks for crtbegin.o and crtend.o
>> to be included regardless of the executable type (c/c++), which
>> might be worth a patch (clang/lib/Driver/Tools.cpp).  On the other
>> hand, it does support __init_array (by default, I believe, and also
>> through -fuse-init-array), and there are also relevant bits in the
>> code for llvm's native linker (lld).
>>
>> Given that clang also supports the old ctor/dtor system (through
>> -fno-use-init-array), the status of crtbegin/crtend seems to be
>> still relevant.
> My point was just that if you're using exclusively new .o files built
> with init-array, I think it's possible to compile without crtbegin.o
> and crtend.o (or equivalently, with empty .o files dropped in their
> place).
>
> Rich
>
>
Thanks for clarifying this, I'll test this with both systems (gcc & 
llvm) and get back to the list.
zg