S_FORCE_RELOC intended behavior?

S_FORCE_RELOC intended behavior?

[Rich Felker]

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?

Rich

Re: S_FORCE_RELOC intended behavior?

[Alan Modra]

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

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.

-- 
Alan Modra
Australia Development Lab, IBM

Re: S_FORCE_RELOC intended behavior?

[Rich Felker]

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

Re: S_FORCE_RELOC intended behavior?

[Alan Modra]

On Fri, Aug 21, 2015 at 11:40:24PM -0400, Rich Felker wrote:
> This behavior changed with the above-linked commit.

Yes, back to 2.12 behaviour.  A change prior to the one you fingered
emitted relocs, and proved to be troublesome.

-- 
Alan Modra
Australia Development Lab, IBM