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]
Other format: [Raw text]

Re: PATCH: PR 528: .set is broken for weak symbols


On Tue, Nov 09, 2004 at 12:48:57AM -0600, Aaron W. LaFramboise wrote:
> H. J. Lu wrote:
> 
> > On Mon, Nov 08, 2004 at 03:59:40PM -0800, H. J. Lu wrote:
> > 
> >>This patch
> >>
> >>http://sources.redhat.com/ml/binutils/2004-11/msg00098.html
> >>
> >>breaks .set, which should only copy the value, not other flags. See
> >>
> >>http://sources.redhat.com/bugzilla/show_bug.cgi?id=528
> 
> Sorry for the breakage.  I don't understand exactly whats going wrong
> here, though.  See below.
> 
> .set doesn't just copy value, though; its used to equate symbols.  For
> example, __attribute__((weak, alias ("..."))) uses .set for most (all?)
> platforms.
> 
> I don't understand why it is correct for your testcase foo.o to not
> generate a relocation; if weak symbol bar is overriden in another
> object, the operand to "jmp" will not be overriden, despite having been
> equated to the weak symbol being overriden.
> 
> This would mean that local symbols equated to the weak symbol would
> resolve to a different function than non-local symbols equated to the
> same weak symbol, which seems very wrong to me.  In addition, it means
> that a weak function might actually be used, despite being overridden by
> a strong function.  This is also suprising, as one would expect that a
> weak function overriden by a strong one would never be used.
> 

.set should just copy value and type. Be default, the new symbol is
always local. BTW,

	.weak foo

implies

	.global foo

> > 1. Should .set change the behavior on weak symbols on any platforms?
> > Does gcc expect that?
> 
> I think GCC does expect that .set will do more than just copy the value
> in the case of weak symbols.

I don't think so. Otherwise, there is no need to use ".set". It can use
the original symbol instead.

> 
> > 2. The ChangeLog entry has
> > 
> > 2004-11-08  Aaron W. LaFramboise <aaron98wiridge9@aaronwl.com>
> >  
> >         * symbols.c (any_external_name): Define.
> >         (resolve_symbol_value): Do not convert weak symbols.
> > 				^^^^^^^
> > Is this a typo? From the code, it seems that weak symbols are
> > converted.
> 
> Yes, you're right; this is a typo.
> 
> > 	* symbols.c (resolve_symbol_value): Convert weak symbols only
> > 	for Windows PECOFF.
> 
> This conversion is necessary for the same reason conversion is necessary
> with undefined symbols: since the equated-to symbol is weak, the equated
> symbol's value will be incorrect if the equated-to weak symbol is
> overriden.  In other words, symbol A is equated to weak symbol B, and a
> relocation against A is not converted to be against B, if B is
> overriden, the relocation couldn't possibly come out right after fixup.
> 
> Why is this not the case with ELF?
> 
> > 	(symbol_equated_reloc_p): Don't equate weaks when relocating
> > 	only for Windows PECOFF.
> 
> This is necessary for similar reasons as the above, but opposite.  Since
> a weak symbol may later be overridden, and thus no longer equated, it is
> not safe to assume that it is equated.  In other words, weak symbol C is
> equated to symbol D.  If the reloc code assumes that C is equated to D,
> then that relocation is against D.  If C is later overridden, the
> relocation will be incorrect, as the fixup will be against D, which
> won't be the same as C.
> 
> Why is this not the case with ELF?

The key is ".set" is not used to equate symbols. It is used to set a
symbol with the same value and type. If the symbol doesn't exist
before, the new symbol will be local.


H.J.


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