This is the mail archive of the binutils@sources.redhat.com 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]

Re: new gas cannot grok new gcc output


> Date: Wed, 14 Feb 01 23:03:57 PST
> From: msokolov@ivan.Harhan.ORG (Michael Sokolov)

> /* This expression evaluates to false if the relocation is for a local object
>    for which we still want to do the relocation at runtime.  True if we
>    are willing to perform this relocation while building the .o file.  If
>    the reloc is against an externally visible symbol, then the assembler
>    should never do the relocation.  */
> 
> #define TC_RELOC_RTSYM_LOC_FIXUP(FIX)			\
> 	((FIX)->fx_addsy == NULL			\
> 	 || (! S_IS_EXTERNAL ((FIX)->fx_addsy)		\
> 	     && ! S_IS_WEAK ((FIX)->fx_addsy)		\
> 	     && S_IS_DEFINED ((FIX)->fx_addsy)		\
> 	     && ! S_IS_COMMON ((FIX)->fx_addsy)))
> 
> It has been this way ever since the import of binutils into sourceware (not
> being a Red Hatter I can't trace it past this point in the real Cygnus tree).
> 
> I do not understand the reason behind this definition, and it seems bogus to
> me. m68k gas has always emitted object files with all internal references
> completely resolved like all traditional assemblers, it has never emitted
> relocs for internal references, even if they refer to externally visible
> symbols. This has never been any different for ELF from COFF or a.out. So if
> this TC_RELOC_RTSYM_LOC_FIXUP definition was supposed to achieve that effect,
> it never worked. But I don't really understand why such behavior would be
> desirable. The only reason I see not to resolve an internal reference in the
> assembler without emitting a reloc is for symbols to be overridable at link
> time in objects that are going to be linked into DSOs.

Also, of course, for weak symbols, which can be overriden even inside
applications.  Also for common symbols, likewise, and for symbols in
linkonce sections.

Also, we permit linking non-PIC code into shared libraries; it's less
efficient, but it should still work.

-- 
- Geoffrey Keating <geoffk@geoffk.org>


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