This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: RFC: x86: Fall back to lazy binding for unrelocated IFUNC symbol [BZ #23240]
- From: Florian Weimer <fweimer at redhat dot com>
- To: "H.J. Lu" <hjl dot tools at gmail dot com>
- Cc: Carlos O'Donell <carlos at redhat dot com>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Wed, 6 Jun 2018 17:53:28 +0200
- Subject: Re: RFC: x86: Fall back to lazy binding for unrelocated IFUNC symbol [BZ #23240]
- References: <20180526135209.GA23818@intel.com> <fbaa5916-fc89-0ab9-72ed-883a408eaad4@redhat.com> <CAMe9rOrKtM2t3khHZonNw_xpZ22Nj2BU1A-6_7eAa6nNaQGDDA@mail.gmail.com> <a34107c3-880e-c40b-98b2-8026e9e29acf@redhat.com> <d476f562-1f99-3817-7b86-788e3540a42a@redhat.com> <CAMe9rOoKECiA-0ZHFazLzzBtvHVmCdMzYaBfqsJwh0q2Qch07w@mail.gmail.com> <c311c003-8b33-6d40-26ac-062a9f3e79e5@redhat.com> <363168df-c501-9d28-446b-34ee33a11611@redhat.com> <CAMe9rOo47VqTMhqC2=52n-Ws92VGQPHeHbyDom9VqGXa+nNCOg@mail.gmail.com> <66949fa3-5ebd-f094-3755-75d524f1b36a@redhat.com> <CAMe9rOpcyGC2GmoNUjTEXtn9bL3wwTwQNMYQ6otd3axYOcPT=w@mail.gmail.com>
On 06/06/2018 05:38 PM, H.J. Lu wrote:
I pushed hjl/pr23240/fw, which is fw/bug21242 + tests for [BZ #23176] and
[BZ #23240].
1. On x86-64:
FAIL: elf/reldep6a
The crash happens because “weak” is undefined in reldep6mod1.so.
The “weak” function is defined in reldep6mod4.so. But reldep6mod1.so is
loaded before reldep6mod4.so:
14289: calling init:
/home/fweimer/src/gnu/glibc/build/elf/reldep6mod1.so
…
14289: opening
file=/home/fweimer/src/gnu/glibc/build/elf/reldep6mod4.so [0];
direct_opencount=1
14289:
14289: binding file
/home/fweimer/src/gnu/glibc/build/elf/reldep6mod4.so [0] to
/home/fweimer/src/gnu/glibc/build/elf/reldep6mod1.so [0]: normal symbol
`baz'
I think this is simply invalid. I think that if you had a “weak ==
NULL” check in reldep6mod1.so, it would be false even after loading
reldep6mod4.so because the address is not lazily bound.
Is this derived from the X server use case, where they load additional
DSOs which provide definitions of functions which are lazily bound?
That's just not compatible with BIND_NOW, and I don't see a compelling
reason why it should be. If it's just about fixing X, then we need to
fix X, and not enhance the dynamic linker.
2. On i686:
FAIL: elf/ifuncpreload1
FAIL: elf/reldep6a
There's no delayed processing for i686 yet. I wanted to get consensus
on the overall approach first.
Thanks,
Florian