Re: RH glibc and __ctype_b
On Mon, Dec 02, 2002 at 12:21:50PM -0800, Roland McGrath wrote:
> I'm not sure exactly what you are asking.
>
> What makes old static binaries crash when they try to load a new libc.so is
> an old bug in the dynamic loading code when handling a reference within an
> object to a hidden symbol in the same object. That was fixed by this change:
>
> 2002-09-18 Roland McGrath <roland@redhat.com>
>
> * elf/do-rel.h (elf_dynamic_do_rel): Mask off 0x8000 bit (hidden flag)
> from the value taken from the DT_VERSYM table.
> * elf/dl-runtime.c (fixup, profile_fixup): Likewise.
> * sysdeps/mips/dl-machine.h (__dl_runtime_resolve): Likewise.
> (RESOLVE_GOTSYM): Likewise.
>
> Obviously, existing static binaries will continue to have that bug. It
> makes them crash when they come across such a symbol. In stock 2.3.1,
> __ctype_b et al are such symbols because they are not exported at link time.
> The compat_symbol uses are what prevent the link-time export (in nm output,
> you can see __ctype_b@GLIBC_2.0 vs __ctype_b@@GLIBC_2.0 and the like;
> in objdump --dynamic-syms output you can see "GLIBC_2.0" vs "(GLIBC_2.0)").
>
> In the RHL version of glibc, those symbols are exported again by omitting
> the compat_symbol uses. The both avoids tickling the aforementioned bug,
> and also lets existing .a's and .o's compiled with the old ctype.h be
> usable. If you want to do that, just comment out the compat_symbol's.
I suppose what really confuses me is that the compat_symbol entries for
__ctype_* are commented out in RHL glibc, but not for __ctype32_*.
Why the asymmetry?
With the __ctype32_* ones present, I don't see how to both:
- Avoid the crash in old static linkers
- Handle application R_*_COPY relocs correctly for __ctype32_*.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
Reply to: