This is the mail archive of the
mailing list for the binutils project.
Re: Reloc BUG in as
- To: Alan Modra <alan at linuxcare dot com dot au>
- Subject: Re: Reloc BUG in as
- From: Ian Lance Taylor <ian at zembu dot com>
- Date: 04 Mar 2001 16:30:19 -0800
- Cc: Geoff Keating <geoffk at redhat dot com>, mikulas at artax dot karlin dot mff dot cuni dot cz, binutils at sources dot redhat dot com
- References: <Pine.LNX.firstname.lastname@example.org>
Alan Modra <email@example.com> writes:
> > > > as sometimes does not create reloc entry. It is a bug. Tested on binutils
> > > > 2.10.91.
> > >
> > > Actually, it's the reverse, isn't it? GAS should never create the
> > > reloc for 'call a-b', since it can compute it correctly while assembling.
> > That is arguably true. However, in that case gas needs to generate a
> > call to the absolute address. But it doesn't. It generates a
> > PC-relative call.
> The real problem here is that
> call <absolute expression>
> is not valid x86 assembly, where "valid 86 assembly" is as defined by
> existing Unixware and other related AT&T derived x86 assemblers.
> There was quite some discussion about this on the mailing lists (binutils
> or gcc, I forget) around the time I made this patch:
> 1999-09-13 Alan Modra <firstname.lastname@example.org>
> * config/tc-i386.c (md_assemble): Handle "jmp/call constant" as a
> pc-relative jmp/call to an absolute symbol.
> > There are two correct options: 1) generate a call to the absolute
> > address; 2) generate a PC-relative call with a relocation which the
> > linker will resolve to the absolute address.
> or 3) Revert above patch (which was to work around a gcc bug as mush as
> anyting else), and error out.
No, I think that patch is the right thing to do. It seems that it is
not firing in every situation, though, since the original message has
a test case which does not generate the expected relocation to the