This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: Problems with the 2003-01-23 patch (was Re: [PATCH] Fix s390 as)
- From: Jakub Jelinek <jakub at redhat dot com>
- To: binutils at sources dot redhat dot com
- Date: Wed, 12 Feb 2003 14:22:19 +0100
- Subject: Re: Problems with the 2003-01-23 patch (was Re: [PATCH] Fix s390 as)
- References: <20030122234151.GY949@bubble.sa.bigpond.net.au> <Pine.BSF.4.44.0301221953500.94131-100000@dair.pair.com> <20030123014717.GZ949@bubble.sa.bigpond.net.au> <20030123125159.GC949@bubble.sa.bigpond.net.au> <20030212122310.A1717@sunsite.ms.mff.cuni.cz> <20030212124124.GM23622@bubble.sa.bigpond.net.au>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Wed, Feb 12, 2003 at 11:11:24PM +1030, Alan Modra wrote:
> On Wed, Feb 12, 2003 at 12:23:10PM +0100, Jakub Jelinek wrote:
> > On Thu, Jan 23, 2003 at 11:21:59PM +1030, Alan Modra wrote:
> > > This should fix the bug shown by Jakub's s390 testcase in a way that
> > > preserves old behaviour regarding subtraction expressions.
> >
> > Unfortunately, it seems to break things on various platforms
> > (those which define their own TC_FORCE_RELOCATION).
>
> I'm understanding better why sane people are afraid to touch the gas
> reloc code.
>
> > Say on Alpha
> > .text
> > 1: lda $15,-128($15)
> > .text 1
> > 2: ldgp $29,2b-1b($27)
> > causes
> > Fatal error: internal error? cannot generate `BFD_RELOC_ALPHA_GPDISP' relocation
> > (this is distilled from much bigger assembly which actually did not change
> > subsections in between the two labels, just a fragment break happened to
> > be in between the two instructions (only on Alpha, not on i686->Alpha cross)
> > and thus expr did not optimize that into constant 4.
>
> Yeah, that's nasty. Turning on gas listings exposes these problems too.
>
> > Dunno if it is better to handle subtraction of two local labels in the same
> > section in the generic TC_FORCE_RELOCATION_SUB_SAME implementation (and in
> > the unlikely case some machine wants to override that behaviour, it could
> > define its own TC_FORCE_RELOCATION_SUB_SAME), or call some new function
> > in each arch_force_relocation before checking relocation type.
>
> I'm not going to try to come up with a patch, as it's getting late here,
> but my thoughts are to go back to using
>
> #ifndef TC_FORCE_RELOCATION_SUB_SAME
> #define TC_FORCE_RELOCATION_SUB_SAME(FIX, SEG) \
> (! SEG_NORMAL (SEG))
> #endif
>
> as a default in write.c, and something special in tc-s390.h.
Wouldn't something like:
(! SEG_NORMAL (SEG)
|| (EXTERN_FORCE_RELOC
&& (S_IS_EXTERNAL ((FIX)->fx_addsy)
|| S_IS_EXTERNAL ((FIX)->fx_subsy))
&& TC_FORCE_RELOCATION (FIX)))
be a better default (or just
(! SEG_NORMAL (SEG)
|| (EXTERN_FORCE_RELOC
&& (S_IS_EXTERNAL ((FIX)->fx_addsy)
|| S_IS_EXTERNAL ((FIX)->fx_subsy))))
).
Jakub