This is the mail archive of the
mailing list for the binutils project.
Re: S_FORCE_RELOC intended behavior?
- From: Rich Felker <dalias at libc dot org>
- To: Alan Modra <amodra at gmail dot com>
- Cc: Binutils <binutils at sourceware dot org>
- Date: Fri, 21 Aug 2015 23:40:24 -0400
- Subject: Re: S_FORCE_RELOC intended behavior?
- Authentication-results: sourceware.org; auth=none
- References: <20150821204205 dot GA9149 at brightrain dot aerifal dot cx> <20150822024605 dot GA8300 at bubble dot grove dot modra 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.