From: "H.J. Lu" <hjl.tools@gmail.com>
To: Fangrui Song <maskray@google.com>
Cc: Binutils <binutils@sourceware.org>,
GNU C Library <libc-alpha@sourceware.org>
Subject: Re: Suppress the fetch of an archive member via --defsym (glibc/elf/librtld.map.o)
Date: Mon, 16 Mar 2020 04:27:44 -0700 [thread overview]
Message-ID: <CAMe9rOqJOLSMoRZ4Fg5UHQqPCkhU=nsY+0_TXyo+XvLLGZKYew@mail.gmail.com> (raw)
In-Reply-To: <20200316050202.pql3syb2imduinf7@google.com>
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.
next prev parent reply other threads:[~2020-03-16 11:28 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-16 4:58 Fangrui Song
2020-03-16 5:02 ` Fangrui Song
2020-03-16 11:27 ` H.J. Lu [this message]
2020-03-16 15:47 ` Fangrui Song
2020-03-16 16:01 ` H.J. Lu
2020-03-16 18:31 ` Fangrui Song
2020-03-16 19:05 ` Michael Matz
2020-03-21 16:39 ` Fangrui Song
2020-04-11 17:04 ` Florian Weimer
2020-04-11 18:16 ` Fangrui Song
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAMe9rOqJOLSMoRZ4Fg5UHQqPCkhU=nsY+0_TXyo+XvLLGZKYew@mail.gmail.com' \
--to=hjl.tools@gmail.com \
--cc=binutils@sourceware.org \
--cc=libc-alpha@sourceware.org \
--cc=maskray@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).