[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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: