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

["Aaron W. LaFramboise" <aaron98wiridge9@aaronwl.com>]

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.

> 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.

> 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?


Thanks for your time,

Aaron W. LaFramboise