This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: PATCH: Fix gold problem with weak undefined symbols


On Wed, Apr 02, 2008 at 08:48:23AM -0700, Ian Lance Taylor wrote:
> It's a logical argument.  However, on the x86-64, using the (default)
> small model, if we compile code like this in non-PIC mode:
> 
> extern char foo[] __attribute__((weak));
> char* fooval() { if (foo) return foo; else return 0; }
> 
> we get a R_X86_64_32S relocation for the second reference to foo from
> fooval.  If we then link this code into an executable linked against a
> shared library which does not define foo, then as I understand it your
> argument is that we should emit a dynamic relocation for the reference
> to foo in fooval.  This dynamic relocation will have to have type
> R_X86_64_32_S.  However, the x86-64 dynamic linker does not support
> that relocation type.  It does not support that relocation type
> because it is in general unsatisfiable: the symbol may be defined by a
> shared library which may be loaded anywhere in the 64-bit address
> space, and thus may not be in range for a 32-bit signed offset.
> 
> Even if we argue that that is a bug, and that we should change glibc
> to resolve these relocations when possible, and that we should change
> the GNU linker to emit these dynamic relocations, we have to deal with
> today's reality: if we emit those dynamic relocs today, an executable
> built from the above code will not run on x86-64, because the dynamic
> linker will give an error about an unexpected reloc type.
> 
> Suggestions?

When linked against a shared library defining foo, your code snippet
presumably requires allocation of foo in .dynbss and copy
relocations.  .dynbss and copy relocs are horrible.  As Cary points
out, if we don't have a definition the linker doesn't know the size of
foo so can't make the .dynbss allocation.

So, no copy reloc support.  On most targets you really need PIC to
make dynamic undefined weak references work, or suffer dynamic text
relocations.  On targets like x86-64 there would be further
restrictions, just as there are for code in shared libraries on
x86-64.  I don't know.  Perhaps these practical difficulties mean the
whole idea is unworkable.

-- 
Alan Modra
Australia Development Lab, IBM


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]