RFC: x86: Fall back to lazy binding for unrelocated IFUNC symbol [BZ #23240]
Florian Weimer
fweimer@redhat.com
Wed Jun 6 15:53:00 GMT 2018
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
More information about the Libc-alpha
mailing list