Re: S_FORCE_RELOC intended behavior?

[Rich Felker <dalias at libc dot org>]

On Sat, Aug 22, 2015 at 12:16:05PM +0930, Alan Modra wrote:
> On Fri, Aug 21, 2015 at 04:42:05PM -0400, Rich Felker wrote:
> > A while back I reported issue #18561 which I thought was sh-specific,
> > but discussion on the bug tracker with Nick Clifton, who found a way
> > to make gas behave correctly, has revealed that the issue might be
> > deeper and affecting other targets too. The following commit:
> > 
> > https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=ae6063d440ba5ec28af81e9fc899cc099561339e;hp=f0abc2a11f47c3ecdfe0b54421092d17c70fc5f2
> > 
> > changed S_FORCE_RELOC so that, for some callers, it reports
> > expressions based on weak symbol definitions as being able to be
> > handled with fixups rather than requiring relocations to be emitted.
> > As far as I can tell, this is always incorrect; a weak definition can
> > always be replaced at link time.
> > 
> > Is anyone familiar with the code affected by the above commit able to
> > confirm whether my interpretation is correct and make sense of why the
> > changes in that commit were made?
> 
> I commented in the bugzilla before seeing this email.
> 
> Basically, your claim that it is always incorrect to resolve an
> expression involving a weak symbol, is wrong.  Counter example:
>  .size foo, . - foo

I'm not seeing why this needs to be resolved at as-time, unless it's
just impossible to represent the expression in the output. If the weak
symbol isn't replaced by a strong one, you get the right value, and if
it is replaced, the symbol the .size is attached to has been replaced
anyway so the .size is irrelevant.

> OK, perhaps not the best example, but the point is that subtraction of
> two symbols is often used in expressions involving some *local*
> property of the function/object involved.

If the local result that can't be replaced by a strong definition is
needed, then a second label with the same value as the weak symbol
should be used instead of the weak symbol itself.

> Long-standing gas behaviour is to resolve expressions involving
> unadorned subtraction of defined symbols at assembly time.  I don't
> think that can be changed without breaking things.

This behavior changed with the above-linked commit. Admittedly that
was made more than a decade ago, so perhaps "that ship has already
sailed", but I believe at the time it was a regression and IMO it's
the wrong behavior.

Rich