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