Suppress the fetch of an archive member via --defsym (glibc/elf/librtld.map.o)

Suppress the fetch of an archive member via --defsym (glibc/elf/librtld.map.o)

[Fangrui Song]

cd /tmp/p
git clone git://sourceware.org/git/glibc.git; cd glibc
mkdir Release; ../configure --prefix=/tmp/opt
make -j

When linking elf/librtld.map.o

% gcc -nostdlib -nostartfiles -r -o /tmp/p/glibc/Release/elf/librtld.map.o -Wl,--defsym=calloc=0 -Wl,--defsym=free=0 -Wl,--defsym=malloc=0 -Wl,--defsym=realloc=0 -Wl,--defsym=__stack_chk_fail=0 -Wl,--defsym=__stack_chk_fail_local=0 '-Wl,-(' /tmp/p/glibc/Release/elf/dl-allobjs.os /tmp/p/glibc/Release/libc_pic.a -lgcc '-Wl,-)' -Wl,-Map,/tmp/p/glibc/Release/elf/librtld.mapT

Without -Wl,defsym:

dl-allobjs.os has an undefined __libc_scratch_buffer_set_array_size
__libc_scratch_buffer_set_array_size fetches libc_pic.a(scratch_buffer_set_array_size.os)
libc_pic.a(scratch_buffer_set_array_size.os) has an undefined free
free fetches libc_pic.a(malloc.os)
libc_pic.a(malloc.os) has an undefined __libc_message
__libc_message fetches libc_pic.a(libc_fatal.os)

libc_fatal.os will cause a multiple definition error (__GI___libc_fatal)
>>> defined at dl-fxstatat64.c
>>>            /tmp/p/glibc/Release/elf/dl-allobjs.os:(__GI___libc_fatal)
>>> defined at libc_fatal.c
>>>            libc_fatal.os:(.text+0x240) in archive /tmp/p/glibc/Release/libc_pic.a

glibc/elf/Makefile uses -Wl,--defsym= (rtld-stubbed-symbols) to suppress libc_pic.a(malloc.os):

% readelf -s elf/librtld.map.o | grep ABS | grep -v LOCAL
    712: 0000000000000000     0 NOTYPE  GLOBAL DEFAULT  ABS __stack_chk_fail_local
    826: 0000000000000000     0 NOTYPE  GLOBAL DEFAULT  ABS malloc
    876: 0000000000000000     0 NOTYPE  GLOBAL DEFAULT  ABS __stack_chk_fail
    905: 0000000000000000     0 NOTYPE  GLOBAL DEFAULT  ABS calloc
    975: 0000000000000000     0 NOTYPE  GLOBAL DEFAULT  ABS realloc
   1174: 0000000000000000     0 NOTYPE  GLOBAL DEFAULT  ABS free

My question is: does the suppression via --defsym work reliably?

# a.o
call foo

# b.a(b.o)
.globl foo, free
foo:
free:


# GNU ld --defsym is order dependent.
ld.bfd a.o b.a --defsym foo=0  # b.a(b.o) is fetched. free is present
ld.bfd --defsym foo=0 a.o b.a  # b.a(b.o) is not fetched. free is absent

# gold --defsym is order independent. For the more complex glibc elf/librtld.map.o case, it happens to match GNU ld.
gold a.o b.a --defsym foo=0    # b.a(b.o) is not fetched. free is absent
gold --defsym foo=0 a.o b.a    # b.a(b.o) is not fetched. free is absent

# lld --defsym is order independent. --defsym is processed the last. For elf/librtld.map.o it will report a multiple definition error.
# https://sourceware.org/pipermail/libc-alpha/2020-March/111899.html is required to bypass a configure check
ld.lld a.o b.a --defsym foo=0  # b.a(b.o) is not fetched. free is absent
ld.lld --defsym=0 a.o b.a      # b.a(b.o) is not fetched. free is absent

Re: Suppress the fetch of an archive member via --defsym (glibc/elf/librtld.map.o)

[Fangrui Song]

On 2020-03-15, Fangrui Song wrote:
>cd /tmp/p
>git clone git://sourceware.org/git/glibc.git; cd glibc
>mkdir Release; ../configure --prefix=/tmp/opt
>make -j
>
>When linking elf/librtld.map.o
>
>% gcc -nostdlib -nostartfiles -r -o /tmp/p/glibc/Release/elf/librtld.map.o -Wl,--defsym=calloc=0 -Wl,--defsym=free=0 -Wl,--defsym=malloc=0 -Wl,--defsym=realloc=0 -Wl,--defsym=__stack_chk_fail=0 -Wl,--defsym=__stack_chk_fail_local=0 '-Wl,-(' /tmp/p/glibc/Release/elf/dl-allobjs.os /tmp/p/glibc/Release/libc_pic.a -lgcc '-Wl,-)' -Wl,-Map,/tmp/p/glibc/Release/elf/librtld.mapT
>
>Without -Wl,defsym:
>
>dl-allobjs.os has an undefined __libc_scratch_buffer_set_array_size
>__libc_scratch_buffer_set_array_size fetches libc_pic.a(scratch_buffer_set_array_size.os)
>libc_pic.a(scratch_buffer_set_array_size.os) has an undefined free
>free fetches libc_pic.a(malloc.os)
>libc_pic.a(malloc.os) has an undefined __libc_message
>__libc_message fetches libc_pic.a(libc_fatal.os)
>
>libc_fatal.os will cause a multiple definition error (__GI___libc_fatal)
>>>>defined at dl-fxstatat64.c
>>>>           /tmp/p/glibc/Release/elf/dl-allobjs.os:(__GI___libc_fatal)
>>>>defined at libc_fatal.c
>>>>           libc_fatal.os:(.text+0x240) in archive /tmp/p/glibc/Release/libc_pic.a
>
>glibc/elf/Makefile uses -Wl,--defsym= (rtld-stubbed-symbols) to suppress libc_pic.a(malloc.os):
>
>% readelf -s elf/librtld.map.o | grep ABS | grep -v LOCAL
>   712: 0000000000000000     0 NOTYPE  GLOBAL DEFAULT  ABS __stack_chk_fail_local
>   826: 0000000000000000     0 NOTYPE  GLOBAL DEFAULT  ABS malloc
>   876: 0000000000000000     0 NOTYPE  GLOBAL DEFAULT  ABS __stack_chk_fail
>   905: 0000000000000000     0 NOTYPE  GLOBAL DEFAULT  ABS calloc
>   975: 0000000000000000     0 NOTYPE  GLOBAL DEFAULT  ABS realloc
>  1174: 0000000000000000     0 NOTYPE  GLOBAL DEFAULT  ABS free
>
>My question is: does the suppression via --defsym work reliably?
>
># a.o
>call foo
>
># b.a(b.o)
>.globl foo, free
>foo:
>free:
>
>
># GNU ld --defsym is order dependent.
>ld.bfd a.o b.a --defsym foo=0  # b.a(b.o) is fetched. free is present
>ld.bfd --defsym foo=0 a.o b.a  # b.a(b.o) is not fetched. free is absent
>
># gold --defsym is order independent. For the more complex glibc elf/librtld.map.o case, it happens to match GNU ld.
>gold a.o b.a --defsym foo=0    # b.a(b.o) is not fetched. free is absent
>gold --defsym foo=0 a.o b.a    # b.a(b.o) is not fetched. free is absent
>
># lld --defsym is order independent. --defsym is processed the last. For elf/librtld.map.o it will report a multiple definition error.
># https://sourceware.org/pipermail/libc-alpha/2020-March/111899.html is required to bypass a configure check
>ld.lld a.o b.a --defsym foo=0  # b.a(b.o) is not fetched. free is absent
>ld.lld --defsym=0 a.o b.a      # b.a(b.o) is not fetched. free is absent

Sorry, clarify the behavior of lld.

# lld --defsym is order independent. --defsym is processed the last. For elf/librtld.map.o it will report a multiple definition error.
ld.lld a.o b.a --defsym foo=0  # b.a(b.o) is fetched. free is present
ld.lld --defsym=0 a.o b.a      # b.a(b.o) is fetched. free is present

Re: Suppress the fetch of an archive member via --defsym (glibc/elf/librtld.map.o)

[H.J. Lu]

On Sun, Mar 15, 2020 at 10:02 PM Fangrui Song via Libc-alpha
<libc-alpha@sourceware.org> wrote:
>
> On 2020-03-15, Fangrui Song wrote:
> >cd /tmp/p
> >git clone git://sourceware.org/git/glibc.git; cd glibc
> >mkdir Release; ../configure --prefix=/tmp/opt
> >make -j
> >
> >When linking elf/librtld.map.o
> >
> >% gcc -nostdlib -nostartfiles -r -o /tmp/p/glibc/Release/elf/librtld.map.o -Wl,--defsym=calloc=0 -Wl,--defsym=free=0 -Wl,--defsym=malloc=0 -Wl,--defsym=realloc=0 -Wl,--defsym=__stack_chk_fail=0 -Wl,--defsym=__stack_chk_fail_local=0 '-Wl,-(' /tmp/p/glibc/Release/elf/dl-allobjs.os /tmp/p/glibc/Release/libc_pic.a -lgcc '-Wl,-)' -Wl,-Map,/tmp/p/glibc/Release/elf/librtld.mapT
> >
> >Without -Wl,defsym:
> >
> >dl-allobjs.os has an undefined __libc_scratch_buffer_set_array_size
> >__libc_scratch_buffer_set_array_size fetches libc_pic.a(scratch_buffer_set_array_size.os)
> >libc_pic.a(scratch_buffer_set_array_size.os) has an undefined free
> >free fetches libc_pic.a(malloc.os)
> >libc_pic.a(malloc.os) has an undefined __libc_message
> >__libc_message fetches libc_pic.a(libc_fatal.os)
> >
> >libc_fatal.os will cause a multiple definition error (__GI___libc_fatal)
> >>>>defined at dl-fxstatat64.c
> >>>>           /tmp/p/glibc/Release/elf/dl-allobjs.os:(__GI___libc_fatal)
> >>>>defined at libc_fatal.c
> >>>>           libc_fatal.os:(.text+0x240) in archive /tmp/p/glibc/Release/libc_pic.a
> >
> >glibc/elf/Makefile uses -Wl,--defsym= (rtld-stubbed-symbols) to suppress libc_pic.a(malloc.os):
> >
> >% readelf -s elf/librtld.map.o | grep ABS | grep -v LOCAL
> >   712: 0000000000000000     0 NOTYPE  GLOBAL DEFAULT  ABS __stack_chk_fail_local
> >   826: 0000000000000000     0 NOTYPE  GLOBAL DEFAULT  ABS malloc
> >   876: 0000000000000000     0 NOTYPE  GLOBAL DEFAULT  ABS __stack_chk_fail
> >   905: 0000000000000000     0 NOTYPE  GLOBAL DEFAULT  ABS calloc
> >   975: 0000000000000000     0 NOTYPE  GLOBAL DEFAULT  ABS realloc
> >  1174: 0000000000000000     0 NOTYPE  GLOBAL DEFAULT  ABS free
> >
> >My question is: does the suppression via --defsym work reliably?
> >
> ># a.o
> >call foo
> >
> ># b.a(b.o)
> >.globl foo, free
> >foo:
> >free:
> >
> >
> ># GNU ld --defsym is order dependent.
> >ld.bfd a.o b.a --defsym foo=0  # b.a(b.o) is fetched. free is present
> >ld.bfd --defsym foo=0 a.o b.a  # b.a(b.o) is not fetched. free is absent
> >
> ># gold --defsym is order independent. For the more complex glibc elf/librtld.map.o case, it happens to match GNU ld.
> >gold a.o b.a --defsym foo=0    # b.a(b.o) is not fetched. free is absent
> >gold --defsym foo=0 a.o b.a    # b.a(b.o) is not fetched. free is absent
> >
> ># lld --defsym is order independent. --defsym is processed the last. For elf/librtld.map.o it will report a multiple definition error.
> ># https://sourceware.org/pipermail/libc-alpha/2020-March/111899.html is required to bypass a configure check
> >ld.lld a.o b.a --defsym foo=0  # b.a(b.o) is not fetched. free is absent
> >ld.lld --defsym=0 a.o b.a      # b.a(b.o) is not fetched. free is absent
>
> Sorry, clarify the behavior of lld.
>
> # lld --defsym is order independent. --defsym is processed the last. For elf/librtld.map.o it will report a multiple definition error.
> ld.lld a.o b.a --defsym foo=0  # b.a(b.o) is fetched. free is present
> ld.lld --defsym=0 a.o b.a      # b.a(b.o) is fetched. free is present

Glibc build requires a linker compatible with ld.  Can you provide an lld
option to make lld compatible with ld for cases like this?

-- 
H.J.

Re: Suppress the fetch of an archive member via --defsym (glibc/elf/librtld.map.o)

[Fangrui Song]

On 2020-03-16, H.J. Lu wrote:
>On Sun, Mar 15, 2020 at 10:02 PM Fangrui Song via Libc-alpha
><libc-alpha@sourceware.org> wrote:
>>
>> On 2020-03-15, Fangrui Song wrote:
>> >cd /tmp/p
>> >git clone git://sourceware.org/git/glibc.git; cd glibc
>> >mkdir Release; ../configure --prefix=/tmp/opt
>> >make -j
>> >
>> >When linking elf/librtld.map.o
>> >
>> >% gcc -nostdlib -nostartfiles -r -o /tmp/p/glibc/Release/elf/librtld.map.o -Wl,--defsym=calloc=0 -Wl,--defsym=free=0 -Wl,--defsym=malloc=0 -Wl,--defsym=realloc=0 -Wl,--defsym=__stack_chk_fail=0 -Wl,--defsym=__stack_chk_fail_local=0 '-Wl,-(' /tmp/p/glibc/Release/elf/dl-allobjs.os /tmp/p/glibc/Release/libc_pic.a -lgcc '-Wl,-)' -Wl,-Map,/tmp/p/glibc/Release/elf/librtld.mapT
>> >
>> >Without -Wl,defsym:
>> >
>> >dl-allobjs.os has an undefined __libc_scratch_buffer_set_array_size
>> >__libc_scratch_buffer_set_array_size fetches libc_pic.a(scratch_buffer_set_array_size.os)
>> >libc_pic.a(scratch_buffer_set_array_size.os) has an undefined free
>> >free fetches libc_pic.a(malloc.os)
>> >libc_pic.a(malloc.os) has an undefined __libc_message
>> >__libc_message fetches libc_pic.a(libc_fatal.os)
>> >
>> >libc_fatal.os will cause a multiple definition error (__GI___libc_fatal)
>> >>>>defined at dl-fxstatat64.c
>> >>>>           /tmp/p/glibc/Release/elf/dl-allobjs.os:(__GI___libc_fatal)
>> >>>>defined at libc_fatal.c
>> >>>>           libc_fatal.os:(.text+0x240) in archive /tmp/p/glibc/Release/libc_pic.a
>> >
>> >glibc/elf/Makefile uses -Wl,--defsym= (rtld-stubbed-symbols) to suppress libc_pic.a(malloc.os):
>> >
>> >% readelf -s elf/librtld.map.o | grep ABS | grep -v LOCAL
>> >   712: 0000000000000000     0 NOTYPE  GLOBAL DEFAULT  ABS __stack_chk_fail_local
>> >   826: 0000000000000000     0 NOTYPE  GLOBAL DEFAULT  ABS malloc
>> >   876: 0000000000000000     0 NOTYPE  GLOBAL DEFAULT  ABS __stack_chk_fail
>> >   905: 0000000000000000     0 NOTYPE  GLOBAL DEFAULT  ABS calloc
>> >   975: 0000000000000000     0 NOTYPE  GLOBAL DEFAULT  ABS realloc
>> >  1174: 0000000000000000     0 NOTYPE  GLOBAL DEFAULT  ABS free
>> >
>> >My question is: does the suppression via --defsym work reliably?
>> >
>> ># a.o
>> >call foo
>> >
>> ># b.a(b.o)
>> >.globl foo, free
>> >foo:
>> >free:
>> >
>> >
>> ># GNU ld --defsym is order dependent.
>> >ld.bfd a.o b.a --defsym foo=0  # b.a(b.o) is fetched. free is present
>> >ld.bfd --defsym foo=0 a.o b.a  # b.a(b.o) is not fetched. free is absent
>> >
>> ># gold --defsym is order independent. For the more complex glibc elf/librtld.map.o case, it happens to match GNU ld.
>> >gold a.o b.a --defsym foo=0    # b.a(b.o) is not fetched. free is absent
>> >gold --defsym foo=0 a.o b.a    # b.a(b.o) is not fetched. free is absent
>> >
>> ># lld --defsym is order independent. --defsym is processed the last. For elf/librtld.map.o it will report a multiple definition error.
>> ># https://sourceware.org/pipermail/libc-alpha/2020-March/111899.html is required to bypass a configure check
>> >ld.lld a.o b.a --defsym foo=0  # b.a(b.o) is not fetched. free is absent
>> >ld.lld --defsym=0 a.o b.a      # b.a(b.o) is not fetched. free is absent
>>
>> Sorry, clarify the behavior of lld.
>>
>> # lld --defsym is order independent. --defsym is processed the last. For elf/librtld.map.o it will report a multiple definition error.
>> ld.lld a.o b.a --defsym foo=0  # b.a(b.o) is fetched. free is present
>> ld.lld --defsym=0 a.o b.a      # b.a(b.o) is fetched. free is present
>
>Glibc build requires a linker compatible with ld.  Can you provide an lld
>option to make lld compatible with ld for cases like this?

As a contributor of lld, I would be cooperative and be happy to adapt lld if the proposed semantic is reasonable.

I am concerned that the --defsym's order dependence with archive files is not so obvious, given -u's behavior:

# -u inserts an undefined which fetches b.a(b.o)
ld.bfd -u foo b.a       # b.a(b.o) is fetched. free is present
# This can't be order dependent because b.a (not in a group) should have been dropped when we saw -u
ld.bfd b.a -u foo       # b.a(b.o) is fetched. free is present


Some observations:


# GNU ld --defsym interacts with an archive
ld.bfd a.o b.a --defsym foo=0  # b.a(b.o) is fetched. free is present
ld.bfd --defsym foo=0 a.o b.a  # b.a(b.o) is not fetched. free is absent

# a.x contains one line `foo = 0;`
# -T a.x is similar to --defsym
ld.bfd a.o b.a -T a.x -o a  # b.a(b.o) is fetched. free is present
ld.bfd -T a.x a.o b.a -o a  # b.a(b.o) is not fetched. free is absent

# -u is usually order independent
# The second can't be order dependent because b.a should have been dropped when we see -u
ld.bfd -u foo b.a       # b.a(b.o) is fetched. free is present
ld.bfd b.a -u foo       # b.a(b.o) is fetched. free is present


# gold --defsym is order independent. For the more complex glibc elf/librtld.map.o case, it happens to make it work
gold a.o b.a --defsym foo=0    # b.a(b.o) is not fetched. free is absent
gold --defsym foo=0 a.o b.a    # b.a(b.o) is not fetched. free is absent

# gold --export-dynamic-symbol (not in GNU ld) implies -u
gold --export-dynamic-symbol foo b.a    # b.a(b.o) is fetched. free is present
gold b.a --export-dynamic-symbol foo    # b.a(b.o) is fetched. free is present


# lld --defsym is order independent. --defsym is processed the last. For elf/librtld.map.o it will report a multiple definition error.
ld.lld a.o b.a --defsym foo=0  # b.a(b.o) is fetched. free is present
ld.lld --defsym=0 a.o b.a      # b.a(b.o) is fetched. free is present


If we aim for robustness and make the librtld.map.o trick supported (I will add a note that gold happens to work),
I will hope both the following can suppress b.a(b.o):

   ld.bfd a.o b.a --defsym foo=0
   ld.bfd --defsym foo=0 a.o b.a

(a) Given --defsym's similarity to a symbol assignment specified by a -T, we will hope -T does not behave too differently.
(b) Note that in a linker script, at least input files should be order dependent w.r.t. input files on the command line.

(a)+(b) => symbol assignments specified by -T need to be declared early but input files specified -T are ordered w.r.t. input files on the command line.


For linker portability, projects using this trick (currently glibc is the only one) should place --defsym first to work with
existing releases of GNU ld.

The added librtld.map.o code is related to https://sourceware.org/bugzilla/show_bug.cgi?id=25486

Re: Suppress the fetch of an archive member via --defsym (glibc/elf/librtld.map.o)

[H.J. Lu]

On Mon, Mar 16, 2020 at 8:47 AM Fangrui Song <maskray@google.com> wrote:
>
> On 2020-03-16, H.J. Lu wrote:
> >On Sun, Mar 15, 2020 at 10:02 PM Fangrui Song via Libc-alpha
> ><libc-alpha@sourceware.org> wrote:
> >>
> >> On 2020-03-15, Fangrui Song wrote:
> >> >cd /tmp/p
> >> >git clone git://sourceware.org/git/glibc.git; cd glibc
> >> >mkdir Release; ../configure --prefix=/tmp/opt
> >> >make -j
> >> >
> >> >When linking elf/librtld.map.o
> >> >
> >> >% gcc -nostdlib -nostartfiles -r -o /tmp/p/glibc/Release/elf/librtld.map.o -Wl,--defsym=calloc=0 -Wl,--defsym=free=0 -Wl,--defsym=malloc=0 -Wl,--defsym=realloc=0 -Wl,--defsym=__stack_chk_fail=0 -Wl,--defsym=__stack_chk_fail_local=0 '-Wl,-(' /tmp/p/glibc/Release/elf/dl-allobjs.os /tmp/p/glibc/Release/libc_pic.a -lgcc '-Wl,-)' -Wl,-Map,/tmp/p/glibc/Release/elf/librtld.mapT
> >> >
> >> >Without -Wl,defsym:
> >> >
> >> >dl-allobjs.os has an undefined __libc_scratch_buffer_set_array_size
> >> >__libc_scratch_buffer_set_array_size fetches libc_pic.a(scratch_buffer_set_array_size.os)
> >> >libc_pic.a(scratch_buffer_set_array_size.os) has an undefined free
> >> >free fetches libc_pic.a(malloc.os)
> >> >libc_pic.a(malloc.os) has an undefined __libc_message
> >> >__libc_message fetches libc_pic.a(libc_fatal.os)
> >> >
> >> >libc_fatal.os will cause a multiple definition error (__GI___libc_fatal)
> >> >>>>defined at dl-fxstatat64.c
> >> >>>>           /tmp/p/glibc/Release/elf/dl-allobjs.os:(__GI___libc_fatal)
> >> >>>>defined at libc_fatal.c
> >> >>>>           libc_fatal.os:(.text+0x240) in archive /tmp/p/glibc/Release/libc_pic.a
> >> >
> >> >glibc/elf/Makefile uses -Wl,--defsym= (rtld-stubbed-symbols) to suppress libc_pic.a(malloc.os):
> >> >
> >> >% readelf -s elf/librtld.map.o | grep ABS | grep -v LOCAL
> >> >   712: 0000000000000000     0 NOTYPE  GLOBAL DEFAULT  ABS __stack_chk_fail_local
> >> >   826: 0000000000000000     0 NOTYPE  GLOBAL DEFAULT  ABS malloc
> >> >   876: 0000000000000000     0 NOTYPE  GLOBAL DEFAULT  ABS __stack_chk_fail
> >> >   905: 0000000000000000     0 NOTYPE  GLOBAL DEFAULT  ABS calloc
> >> >   975: 0000000000000000     0 NOTYPE  GLOBAL DEFAULT  ABS realloc
> >> >  1174: 0000000000000000     0 NOTYPE  GLOBAL DEFAULT  ABS free
> >> >
> >> >My question is: does the suppression via --defsym work reliably?
> >> >
> >> ># a.o
> >> >call foo
> >> >
> >> ># b.a(b.o)
> >> >.globl foo, free
> >> >foo:
> >> >free:
> >> >
> >> >
> >> ># GNU ld --defsym is order dependent.
> >> >ld.bfd a.o b.a --defsym foo=0  # b.a(b.o) is fetched. free is present
> >> >ld.bfd --defsym foo=0 a.o b.a  # b.a(b.o) is not fetched. free is absent
> >> >
> >> ># gold --defsym is order independent. For the more complex glibc elf/librtld.map.o case, it happens to match GNU ld.
> >> >gold a.o b.a --defsym foo=0    # b.a(b.o) is not fetched. free is absent
> >> >gold --defsym foo=0 a.o b.a    # b.a(b.o) is not fetched. free is absent

Gold is irrelevant here since it isn't supported to build glibc:

https://sourceware.org/bugzilla/show_bug.cgi?id=24148

There are also other gold bugs which may impact glibc build.   Please remove
gold from this discussion.

-- 
H.J.

Re: Suppress the fetch of an archive member via --defsym (glibc/elf/librtld.map.o)

[Fangrui Song]

>>>On 2020-03-16, H.J. Lu wrote:
>>>Glibc build requires a linker compatible with ld.  Can you provide an lld
>>>option to make lld compatible with ld for cases like this?
>>
>>As a contributor of lld, I would be cooperative and be happy to adapt lld if the proposed semantic is reasonable.
>>
>>I am concerned that the --defsym's order dependence with archive files is not so obvious, given -u's behavior:
>>
>># -u inserts an undefined which fetches b.a(b.o)
>>ld.bfd -u foo b.a       # b.a(b.o) is fetched. free is present
>># This can't be order dependent because b.a (not in a group) should have been dropped when we saw -u
>>ld.bfd b.a -u foo       # b.a(b.o) is fetched. free is present
>>
>>
>>Some observations:
>>
>>
>># GNU ld --defsym interacts with an archive
>>ld.bfd a.o b.a --defsym foo=0  # b.a(b.o) is fetched. free is present
>>ld.bfd --defsym foo=0 a.o b.a  # b.a(b.o) is not fetched. free is absent
>>
>># a.x contains one line `foo = 0;`
>># -T a.x is similar to --defsym
>>ld.bfd a.o b.a -T a.x -o a  # b.a(b.o) is fetched. free is present
>>ld.bfd -T a.x a.o b.a -o a  # b.a(b.o) is not fetched. free is absent
>>
>># -u is usually order independent
>># The second can't be order dependent because b.a should have been dropped when we see -u
>>ld.bfd -u foo b.a       # b.a(b.o) is fetched. free is present
>>ld.bfd b.a -u foo       # b.a(b.o) is fetched. free is present
>>
>>
>># gold --defsym is order independent. For the more complex glibc elf/librtld.map.o case, it happens to make it work
>>gold a.o b.a --defsym foo=0    # b.a(b.o) is not fetched. free is absent
>>gold --defsym foo=0 a.o b.a    # b.a(b.o) is not fetched. free is absent
>>
>># gold --export-dynamic-symbol (not in GNU ld) implies -u
>>gold --export-dynamic-symbol foo b.a    # b.a(b.o) is fetched. free is present
>>gold b.a --export-dynamic-symbol foo    # b.a(b.o) is fetched. free is present
>>
>>
>># lld --defsym is order independent. --defsym is processed the last. For elf/librtld.map.o it will report a multiple definition error.
>>ld.lld a.o b.a --defsym foo=0  # b.a(b.o) is fetched. free is present
>>ld.lld --defsym=0 a.o b.a      # b.a(b.o) is fetched. free is present
>>
>>
>>If we aim for robustness and make the librtld.map.o trick supported (I will add a note that gold happens to work),
>>I will hope both the following can suppress b.a(b.o):
>>
>>  ld.bfd a.o b.a --defsym foo=0
>>  ld.bfd --defsym foo=0 a.o b.a
>>
>>(a) Given --defsym's similarity to a symbol assignment specified by a -T, we will hope -T does not behave too differently.
>>(b) Note that in a linker script, at least input files should be order dependent w.r.t. input files on the command line.
>>
>>(a)+(b) => symbol assignments specified by -T need to be declared early but input files specified -T are ordered w.r.t. input files on the command line.
>>
>>
>>For linker portability, projects using this trick (currently glibc is the only one) should place --defsym first to work with
>>existing releases of GNU ld.
>>
>>The added librtld.map.o code is related to https://sourceware.org/bugzilla/show_bug.cgi?id=25486
>
>Gold is irrelevant here since it isn't supported to build glibc:
>
>https://sourceware.org/bugzilla/show_bug.cgi?id=24148
>
>There are also other gold bugs which may impact glibc build.   Please remove
>gold from this discussion.

Thanks for the link. I am aways eager to learn more about linkers..

My motivation is indeed for my selfish dream to make glibc compilable with clang and linkable with lld.
As a contributor of lld and various LLVM tools, I think I am best positioned to make the situation better:)
At least for lld, it seems we need very few portability patches to work.
(At least the default configuration. There are numerous other configurations I don't know how to test now. I know really little about glibc.)

To make it very clear, I won't add workarounds for quality of implementation issues of clang+lld.
I mostly consider lld HEAD (lld<8 is not very reliable.)

To make my intention more plausible, this is in the spirit of https://gcc.gnu.org/wiki/cauldron2019 (GCC/LLVM Collaboration BoF).



Given more thoughts, I would hope we don't rely on the --defsym trick for malloc.os symbols
(already in use before commit 3a0ecccb599a6b1ad4b149dc569c0080e92d057b).

lld processes input files and -T/-u/--defsym in the following order:

1. parseFile(files[i])  // shared, relocatable, archive, linker scripts. Most archive members fetch is done in this step
2. handle -u            // This can trigger more fetch of archive members
3. declare symbols specified by -T and --defsym // too late to suppress fetch of archive members

(I have a feeling that gold's overall strategy is similar, though, when handling --start-group, it
sorta gets into an undesired "mixed" status (my simple a.o b.a example and librtld.map.o exhibit
different behaviors))

I could let lld match GNU ld by adding a separate --defsym step, but the logic would not be
consistent with -T processing.

1. declare symbols specified by --defsym
2. parseFile(files[i])
3. handle -u
4. declare symbols specified by -T

Note that --defsym can accept arbitrary expressions. Their st_shndx/st_value isn't finalized.
Postponing their effectness as late as possible can theoretically make implementations (ld/ldlang.c
ld/ldexp.c) simpler.

Without the --defsym trick, the following scheme may work:

(1) remove malloc.os from libc_pic.a
(2) ld -r -( dl-allobjs.os libc_pic.a -) -Map librtld.map
(3) add malloc.os back to libc_pic.a
(4) process librtld.map and get the libc dependencies
...

(1) and (3) could be avoided if GNU ld supported --start-lib --end-lib (gold,lld):
https://sourceware.org/bugzilla/show_bug.cgi?id=24600


As to why we should make ld a.o b.a --defsym foo=0 and ld --defsym foo=0 a.o b.a behave the same,
order dependency is not robust. We should avoid subtle failures if possible.

Re: Suppress the fetch of an archive member via --defsym (glibc/elf/librtld.map.o)

[Michael Matz]

Hallo,

On Mon, 16 Mar 2020, Fangrui Song via Binutils wrote:

> On 2020-03-16, H.J. Lu wrote:
> >On Sun, Mar 15, 2020 at 10:02 PM Fangrui Song via Libc-alpha
> ><libc-alpha@sourceware.org> wrote:
> >>
> >> On 2020-03-15, Fangrui Song wrote:
> >> >cd /tmp/p
> >> >git clone git://sourceware.org/git/glibc.git; cd glibc
> >> >mkdir Release; ../configure --prefix=/tmp/opt
> >> >make -j
> >> >
> >> >When linking elf/librtld.map.o
> >> >
> >> >% gcc -nostdlib -nostartfiles -r -o /tmp/p/glibc/Release/elf/librtld.map.o
> >> >-Wl,--defsym=calloc=0 -Wl,--defsym=free=0 -Wl,--defsym=malloc=0
> >> >-Wl,--defsym=realloc=0 -Wl,--defsym=__stack_chk_fail=0
> >> >-Wl,--defsym=__stack_chk_fail_local=0 '-Wl,-('
> >> >/tmp/p/glibc/Release/elf/dl-allobjs.os /tmp/p/glibc/Release/libc_pic.a
> >> >-lgcc '-Wl,-)' -Wl,-Map,/tmp/p/glibc/Release/elf/librtld.mapT
> >> >
> >> >Without -Wl,defsym:
> >> >
> >> >dl-allobjs.os has an undefined __libc_scratch_buffer_set_array_size
> >> >__libc_scratch_buffer_set_array_size fetches
> >> >libc_pic.a(scratch_buffer_set_array_size.os)
> >> >libc_pic.a(scratch_buffer_set_array_size.os) has an undefined free
> >> >free fetches libc_pic.a(malloc.os)
> >> >libc_pic.a(malloc.os) has an undefined __libc_message
> >> >__libc_message fetches libc_pic.a(libc_fatal.os)
> >> >
> >> >libc_fatal.os will cause a multiple definition error (__GI___libc_fatal)
> >> >>>>defined at dl-fxstatat64.c
> >> >>>>           /tmp/p/glibc/Release/elf/dl-allobjs.os:(__GI___libc_fatal)
> >> >>>>defined at libc_fatal.c
> >> >>>>           libc_fatal.os:(.text+0x240) in archive
> >> >>>>           /tmp/p/glibc/Release/libc_pic.a
> >> >
> >> >glibc/elf/Makefile uses -Wl,--defsym= (rtld-stubbed-symbols) to suppress
> >> >libc_pic.a(malloc.os):
> >> >
> >> >% readelf -s elf/librtld.map.o | grep ABS | grep -v LOCAL
> >> >   712: 0000000000000000     0 NOTYPE  GLOBAL DEFAULT  ABS
> >> >   __stack_chk_fail_local
> >> >   826: 0000000000000000     0 NOTYPE  GLOBAL DEFAULT  ABS malloc
> >> >   876: 0000000000000000     0 NOTYPE  GLOBAL DEFAULT  ABS
> >> >   __stack_chk_fail
> >> >   905: 0000000000000000     0 NOTYPE  GLOBAL DEFAULT  ABS calloc
> >> >   975: 0000000000000000     0 NOTYPE  GLOBAL DEFAULT  ABS realloc
> >> >  1174: 0000000000000000     0 NOTYPE  GLOBAL DEFAULT  ABS free
> >> >
> >> >My question is: does the suppression via --defsym work reliably?
> >> >
> >> ># a.o
> >> >call foo
> >> >
> >> ># b.a(b.o)
> >> >.globl foo, free
> >> >foo:
> >> >free:
> >> >
> >> >
> >> ># GNU ld --defsym is order dependent.
> >> >ld.bfd a.o b.a --defsym foo=0  # b.a(b.o) is fetched. free is present
> >> >ld.bfd --defsym foo=0 a.o b.a  # b.a(b.o) is not fetched. free is absent
> >> >
> >> ># gold --defsym is order independent. For the more complex glibc
> >> >elf/librtld.map.o case, it happens to match GNU ld.
> >> >gold a.o b.a --defsym foo=0    # b.a(b.o) is not fetched. free is absent
> >> >gold --defsym foo=0 a.o b.a    # b.a(b.o) is not fetched. free is absent
> >> >
> >> ># lld --defsym is order independent. --defsym is processed the last. For
> >> ># elf/librtld.map.o it will report a multiple definition error.
> >> ># https://sourceware.org/pipermail/libc-alpha/2020-March/111899.html is
> >> ># required to bypass a configure check
> >> >ld.lld a.o b.a --defsym foo=0  # b.a(b.o) is not fetched. free is absent
> >> >ld.lld --defsym=0 a.o b.a      # b.a(b.o) is not fetched. free is absent
> >>
> >> Sorry, clarify the behavior of lld.
> >>
> >> # lld --defsym is order independent. --defsym is processed the last. For
> >> elf/librtld.map.o it will report a multiple definition error.
> >> ld.lld a.o b.a --defsym foo=0  # b.a(b.o) is fetched. free is present
> >> ld.lld --defsym=0 a.o b.a      # b.a(b.o) is fetched. free is present
> >
> >Glibc build requires a linker compatible with ld.  Can you provide an lld
> >option to make lld compatible with ld for cases like this?
> 
> As a contributor of lld, I would be cooperative and be happy to adapt lld if
> the proposed semantic is reasonable.
> 
> I am concerned that the --defsym's order dependence with archive files is not
> so obvious, given -u's behavior:
> 
> # -u inserts an undefined which fetches b.a(b.o)
> ld.bfd -u foo b.a       # b.a(b.o) is fetched. free is present
> # This can't be order dependent because b.a (not in a group) should have been
> dropped when we saw -u
> ld.bfd b.a -u foo       # b.a(b.o) is fetched. free is present
> 
> Some observations:
> 
> 
> # GNU ld --defsym interacts with an archive
> ld.bfd a.o b.a --defsym foo=0  # b.a(b.o) is fetched. free is present
> ld.bfd --defsym foo=0 a.o b.a  # b.a(b.o) is not fetched. free is absent

I consider this the correct linker behaviour.  In that sense I would 
consider the inconsistency with -u and -T to be the problems of those, not 
a problem of --defsym (but not necessarily problems we can fix anymore, as 
people might rely on that).  (i.e. I think the second -u command above 
should result in an 'undefined foo' output/error, not in b.a(b.o) being 
fetched).

I consider the above to be correct because this is how traditional link 
editors behave with respect to archives: ordering of file arguments does 
matter (obviously between .o and .a, but also between multiple .a and even 
between .o (think static initializers)).  And if you interpret '--defsym 
bla' as "object file defining symbol bla" and '-u foo' as "object file 
containing reference to foo" the behaviour for --defsym naturally follows 
(and makes the behaviour of -u be the inconsistence).

For this reasoning it's immaterial that --defsym accepts expressions: the 
evaluation of them can be delayed until cmdline arguments are processed.  
But the point of definition or reference should be their place in the 
cmdline.

How that interacts with -T: well, in an ideal world I don't see why those 
shouldn't also be processed in order and at their place within the command 
line (i.e. file arguments before it are available and processed, file 
arguments after it aren't yet), again with the caveat that RHS expressions 
might be evaluated late, but name references or definitions happen 
immediately).  But as said, we might not be able to change ld such that 
this is the case for compat reasons.

> If we aim for robustness and make the librtld.map.o trick supported (I will
> add a note that gold happens to work),
> I will hope both the following can suppress b.a(b.o):
> 
>   ld.bfd a.o b.a --defsym foo=0
>   ld.bfd --defsym foo=0 a.o b.a

And I would hope that the above two would _not_ be made to behave the 
same.


Ciao,
Michael.

Re: Suppress the fetch of an archive member via --defsym (glibc/elf/librtld.map.o)

[Fangrui Song]

On 2020-03-16, Michael Matz wrote:
>Hallo,
>
>On Mon, 16 Mar 2020, Fangrui Song via Binutils wrote:
>
>> On 2020-03-16, H.J. Lu wrote:
>> >On Sun, Mar 15, 2020 at 10:02 PM Fangrui Song via Libc-alpha
>> ><libc-alpha@sourceware.org> wrote:
>> >>
>> >> On 2020-03-15, Fangrui Song wrote:
>> >> >cd /tmp/p
>> >> >git clone git://sourceware.org/git/glibc.git; cd glibc
>> >> >mkdir Release; ../configure --prefix=/tmp/opt
>> >> >make -j
>> >> >
>> >> >When linking elf/librtld.map.o
>> >> >
>> >> >% gcc -nostdlib -nostartfiles -r -o /tmp/p/glibc/Release/elf/librtld.map.o
>> >> >-Wl,--defsym=calloc=0 -Wl,--defsym=free=0 -Wl,--defsym=malloc=0
>> >> >-Wl,--defsym=realloc=0 -Wl,--defsym=__stack_chk_fail=0
>> >> >-Wl,--defsym=__stack_chk_fail_local=0 '-Wl,-('
>> >> >/tmp/p/glibc/Release/elf/dl-allobjs.os /tmp/p/glibc/Release/libc_pic.a
>> >> >-lgcc '-Wl,-)' -Wl,-Map,/tmp/p/glibc/Release/elf/librtld.mapT
>> >> >
>> >> >Without -Wl,defsym:
>> >> >
>> >> >dl-allobjs.os has an undefined __libc_scratch_buffer_set_array_size
>> >> >__libc_scratch_buffer_set_array_size fetches
>> >> >libc_pic.a(scratch_buffer_set_array_size.os)
>> >> >libc_pic.a(scratch_buffer_set_array_size.os) has an undefined free
>> >> >free fetches libc_pic.a(malloc.os)
>> >> >libc_pic.a(malloc.os) has an undefined __libc_message
>> >> >__libc_message fetches libc_pic.a(libc_fatal.os)
>> >> >
>> >> >libc_fatal.os will cause a multiple definition error (__GI___libc_fatal)
>> >> >>>>defined at dl-fxstatat64.c
>> >> >>>>           /tmp/p/glibc/Release/elf/dl-allobjs.os:(__GI___libc_fatal)
>> >> >>>>defined at libc_fatal.c
>> >> >>>>           libc_fatal.os:(.text+0x240) in archive
>> >> >>>>           /tmp/p/glibc/Release/libc_pic.a
>> >> >
>> >> >glibc/elf/Makefile uses -Wl,--defsym= (rtld-stubbed-symbols) to suppress
>> >> >libc_pic.a(malloc.os):
>> >> >
>> >> >% readelf -s elf/librtld.map.o | grep ABS | grep -v LOCAL
>> >> >   712: 0000000000000000     0 NOTYPE  GLOBAL DEFAULT  ABS
>> >> >   __stack_chk_fail_local
>> >> >   826: 0000000000000000     0 NOTYPE  GLOBAL DEFAULT  ABS malloc
>> >> >   876: 0000000000000000     0 NOTYPE  GLOBAL DEFAULT  ABS
>> >> >   __stack_chk_fail
>> >> >   905: 0000000000000000     0 NOTYPE  GLOBAL DEFAULT  ABS calloc
>> >> >   975: 0000000000000000     0 NOTYPE  GLOBAL DEFAULT  ABS realloc
>> >> >  1174: 0000000000000000     0 NOTYPE  GLOBAL DEFAULT  ABS free
>> >> >
>> >> >My question is: does the suppression via --defsym work reliably?
>> >> >
>> >> ># a.o
>> >> >call foo
>> >> >
>> >> ># b.a(b.o)
>> >> >.globl foo, free
>> >> >foo:
>> >> >free:
>> >> >
>> >> >
>> >> ># GNU ld --defsym is order dependent.
>> >> >ld.bfd a.o b.a --defsym foo=0  # b.a(b.o) is fetched. free is present
>> >> >ld.bfd --defsym foo=0 a.o b.a  # b.a(b.o) is not fetched. free is absent
>> >> >
>> >> ># gold --defsym is order independent. For the more complex glibc
>> >> >elf/librtld.map.o case, it happens to match GNU ld.
>> >> >gold a.o b.a --defsym foo=0    # b.a(b.o) is not fetched. free is absent
>> >> >gold --defsym foo=0 a.o b.a    # b.a(b.o) is not fetched. free is absent
>> >> >
>> >> ># lld --defsym is order independent. --defsym is processed the last. For
>> >> ># elf/librtld.map.o it will report a multiple definition error.
>> >> ># https://sourceware.org/pipermail/libc-alpha/2020-March/111899.html is
>> >> ># required to bypass a configure check
>> >> >ld.lld a.o b.a --defsym foo=0  # b.a(b.o) is not fetched. free is absent
>> >> >ld.lld --defsym=0 a.o b.a      # b.a(b.o) is not fetched. free is absent
>> >>
>> >> Sorry, clarify the behavior of lld.
>> >>
>> >> # lld --defsym is order independent. --defsym is processed the last. For
>> >> elf/librtld.map.o it will report a multiple definition error.
>> >> ld.lld a.o b.a --defsym foo=0  # b.a(b.o) is fetched. free is present
>> >> ld.lld --defsym=0 a.o b.a      # b.a(b.o) is fetched. free is present
>> >
>> >Glibc build requires a linker compatible with ld.  Can you provide an lld
>> >option to make lld compatible with ld for cases like this?
>>
>> As a contributor of lld, I would be cooperative and be happy to adapt lld if
>> the proposed semantic is reasonable.
>>
>> I am concerned that the --defsym's order dependence with archive files is not
>> so obvious, given -u's behavior:
>>
>> # -u inserts an undefined which fetches b.a(b.o)
>> ld.bfd -u foo b.a       # b.a(b.o) is fetched. free is present
>> # This can't be order dependent because b.a (not in a group) should have been
>> dropped when we saw -u
>> ld.bfd b.a -u foo       # b.a(b.o) is fetched. free is present
>>
>> Some observations:
>>
>>
>> # GNU ld --defsym interacts with an archive
>> ld.bfd a.o b.a --defsym foo=0  # b.a(b.o) is fetched. free is present
>> ld.bfd --defsym foo=0 a.o b.a  # b.a(b.o) is not fetched. free is absent
>
>I consider this the correct linker behaviour.  In that sense I would
>consider the inconsistency with -u and -T to be the problems of those, not
>a problem of --defsym (but not necessarily problems we can fix anymore, as
>people might rely on that).  (i.e. I think the second -u command above
>should result in an 'undefined foo' output/error, not in b.a(b.o) being
>fetched).
>
>I consider the above to be correct because this is how traditional link
>editors behave with respect to archives: ordering of file arguments does
>matter (obviously between .o and .a, but also between multiple .a and even
>between .o (think static initializers)).  And if you interpret '--defsym
>bla' as "object file defining symbol bla" and '-u foo' as "object file
>containing reference to foo" the behaviour for --defsym naturally follows
>(and makes the behaviour of -u be the inconsistence).

Symbol assignments in -T can override symbols in object files.
PROVIDE(...) is still effectful if -T comes before the object file.

The two facts imply that symbol assignments in -T can be considered
sorta order independent with regard to symbols in other files.

The model is that ad-hoc symbol resolution (symbol assignments in -T,
--defsym, -u, --export-dynamic-symbol) happens after archive file resolution.

>For this reasoning it's immaterial that --defsym accepts expressions: the
>evaluation of them can be delayed until cmdline arguments are processed.
>But the point of definition or reference should be their place in the
>cmdline.
>
>How that interacts with -T: well, in an ideal world I don't see why those
>shouldn't also be processed in order and at their place within the command
>line (i.e. file arguments before it are available and processed, file
>arguments after it aren't yet), again with the caveat that RHS expressions
>might be evaluated late, but name references or definitions happen
>immediately).  But as said, we might not be able to change ld such that
>this is the case for compat reasons.

It is actually possible for GNU ld's symbol resolution rules to behave
more like gold and lld. The amount of work can be large, but it can
improve consistency and simplify the internals.

>> If we aim for robustness and make the librtld.map.o trick supported (I will
>> add a note that gold happens to work),
>> I will hope both the following can suppress b.a(b.o):
>>
>>   ld.bfd a.o b.a --defsym foo=0
>>   ld.bfd --defsym foo=0 a.o b.a
>
>And I would hope that the above two would _not_ be made to behave the
>same.
>
>
>Ciao,
>Michael.

Re: Suppress the fetch of an archive member via --defsym (glibc/elf/librtld.map.o)

[Florian Weimer]

* Michael Matz:

> On Mon, 16 Mar 2020, Fangrui Song via Binutils wrote:
>> I am concerned that the --defsym's order dependence with archive files is not
>> so obvious, given -u's behavior:
>> 
>> # -u inserts an undefined which fetches b.a(b.o)
>> ld.bfd -u foo b.a       # b.a(b.o) is fetched. free is present
>> # This can't be order dependent because b.a (not in a group) should have been
>> dropped when we saw -u
>> ld.bfd b.a -u foo       # b.a(b.o) is fetched. free is present
>> 
>> Some observations:
>> 
>> 
>> # GNU ld --defsym interacts with an archive
>> ld.bfd a.o b.a --defsym foo=0  # b.a(b.o) is fetched. free is present
>> ld.bfd --defsym foo=0 a.o b.a  # b.a(b.o) is not fetched. free is absent
>
> I consider this the correct linker behaviour.  In that sense I would 
> consider the inconsistency with -u and -T to be the problems of those, not 
> a problem of --defsym (but not necessarily problems we can fix anymore, as 
> people might rely on that).  (i.e. I think the second -u command above 
> should result in an 'undefined foo' output/error, not in b.a(b.o) being 
> fetched).

I agree, the ld.bfd behavior seems the most reasonable one to me.

Re: Suppress the fetch of an archive member via --defsym (glibc/elf/librtld.map.o)

[Fangrui Song]

On 2020-04-11, Florian Weimer wrote:
>* Michael Matz:
>
>> On Mon, 16 Mar 2020, Fangrui Song via Binutils wrote:
>>> I am concerned that the --defsym's order dependence with archive files is not
>>> so obvious, given -u's behavior:
>>>
>>> # -u inserts an undefined which fetches b.a(b.o)
>>> ld.bfd -u foo b.a       # b.a(b.o) is fetched. free is present
>>> # This can't be order dependent because b.a (not in a group) should have been
>>> dropped when we saw -u
>>> ld.bfd b.a -u foo       # b.a(b.o) is fetched. free is present
>>>
>>> Some observations:
>>>
>>>
>>> # GNU ld --defsym interacts with an archive
>>> ld.bfd a.o b.a --defsym foo=0  # b.a(b.o) is fetched. free is present
>>> ld.bfd --defsym foo=0 a.o b.a  # b.a(b.o) is not fetched. free is absent
>>
>> I consider this the correct linker behaviour.  In that sense I would
>> consider the inconsistency with -u and -T to be the problems of those, not
>> a problem of --defsym (but not necessarily problems we can fix anymore, as
>> people might rely on that).  (i.e. I think the second -u command above
>> should result in an 'undefined foo' output/error, not in b.a(b.o) being
>> fetched).
>
>I agree, the ld.bfd behavior seems the most reasonable one to me.

ld accepts two types of command line arguments: input files / options.

Examples of order dependency between two input files:

* an earlier archive member can override a subsequent archive member
* a shared object can suppress the fetch of a subsequent archive member
* a fetched archive member (turns to an object file) overrides a shared object

Examples of order dependency between an input file and an option:

* --as-needed --no-as-needed
* --whole-archive --no-whole-archive
* --start-lib --end-lib
* -Bdynamic -Bstatic -static (I am saddened by https://sourceware.org/pipermail/binutils/2020-March/000110.html)
* --start-group --end-group

I acknowledge all the above. However, a large set of options have no
order dependency issues.

* --allow-shlib-undefined
* --dynamic-list
* --version-script
* --apply-dynamic-relocs
* --omagic
* ...
* -u
* --export-dynamic-symbol
* --exclude-libs

I am glad the options are designed this way, otherwise in people's build
systems they could notice many more hard-to-diagnose problems.

As my very first message said, if GNU ld had --start-lib for a long time
(feature request: https://sourceware.org/bugzilla/show_bug.cgi?id=24600), this shadowing
malloc.o definition issue can be fixed very elegantly.

Now, we don't have --start-lib for GNU ld, but we can probably use GNU
ar thin archives as an alternative. The Linux kernel makes use of a
similar trick.


------- Random out of topic comments

In FreeBSD ports, 32k pieces of software just work, 130+ packages are
marked as LLD_UNSAFE, but many should be safe (need developers' testing)
as of lld 9. It is very likely none of the packages makes use of the
--defsym feature.

Most configurations of x86/x86-64/aarch64/ppc64le/ppc64le ports of the
Linux kernel link fine with LLD.

Making glibc compilable/linkable with clang/LLD is not at all my work
requirement.  It is simply I want to earn myself some contributions + I
don't want glibc to be tied to very specific toolchain. I started with
LLD because it is the relatively easy task. Clang compilability is more
troublesome. If I feel sufficient enmity, I will surely stop.

I tried stripping down LLD yesterday, just wanted to know how much code
is sufficient as the core https://github.com/MaskRay/picolld WoW, 18000+
LOC is capable to keep x86/ARM/AArch64/PPC ports and most functionality.
The GNU ld core probably really needs a refinement.

I have been thinking how to detect discrepancy between lld's and
traditional linkers' resolution rules. (The FreeBSD ports stats tell us
the "order dependency" issues are very few.) https://reviews.llvm.org/D77512

I am saddened that for some bug reports/enhancement proposals, the
initial reaction of some people in the community is usually "this is not
a bug." "this is an LLD bug" "GCC does this, so clang should do this as well."

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94391 is an awesome recent
showcase. It was then followed by an unfounded "NO LLD is not
implemented the ABI as PIE COPYRELOC is required by ABI these days".
The status was updated back and forth between "invalid", "wontfix" and
"worksforme" until a maintainer realized GNU ld had indeed one bug
(R_X86_64_[REX_]GOTPCRELX cannot be relaxed for SHN_ABS) and one
enhancement (PC relative relocations to a non-preemptible symbol should
be rejected). No one is probably willing to admit that LLD is good, though.