This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: [PATCH/RFA] sh-elf: Unnecessary relocations
- From: Hans-Peter Nilsson <hp at bitrange dot com>
- To: Daniel Jacobowitz <drow at mvista dot com>
- Cc: kaz Kojima <kkojima at rr dot iij4u dot or dot jp>, <binutils at sources dot redhat dot com>
- Date: Thu, 26 Sep 2002 19:54:31 -0400 (EDT)
- Subject: Re: [PATCH/RFA] sh-elf: Unnecessary relocations
On Thu, 26 Sep 2002, Daniel Jacobowitz wrote:
> On Fri, Sep 27, 2002 at 07:29:53AM +0900, kaz Kojima wrote:
> > Daniel Jacobowitz <drow@mvista.com> wrote:
> > > On Fri, Sep 27, 2002 at 06:26:52AM +0900, kaz Kojima wrote:
> > >> Hi,
> > >>
> > >> Current gas for sh-elf generates some unnecessary PC relative
> > >> relocations when the symbol is global. For example, I've got
> > >> two relocations:
> > >>
> > >> RELOCATION RECORDS FOR [.text]:
> > >> OFFSET TYPE VALUE
> > >> 00000000 R_SH_DIR8WPL foo
> > >> 00000006 R_SH_IND12W foo
> > >>
> > >> for the following small source
> > >>
> > >> .text
> > >> mova foo,r0
> > >> rts
> > >> nop
> > >> .global foo
> > >> foo:
> > >> bra foo
> > >> nop
> > >>
> > >> and slightly old gas doesn't make such relocations for the same
> > >> source. With the following patch, gas shows the same behavior
> > >> as the old one. Regression tested on sh-unknown-linux-gnu.
> > >
> > > Isn't that incorrect ELF, though? Can't the definition of foo end up
> > > coming from another shared object?
> >
> > Yes, it's a correct ELF. My point is that these relocations are
> > unnecessary in this case.
>
> After your patch gas would not generate any relocations for that
> object, right? Why can't these be overridden in another shared object?
I think the point is that those relocations are for
*immediately* nearby addresses; they can't reach more than
something like 1 << 8 or 1 << 12 bytes. It'd be a gcc bug to
generate them for global symbols that can be overridden. I
think the patch should be corrected to check for R_SH_DIR8WPL
and R_SH_IND12W (or really, the BFD names) since there
supposedly exists other PC-relative relocations that should be
generated for global symbols in the same object. That includes
the 32-bit pcrel reloc (whatever the SH ELF name; I think the
BFD name is BFD_RELOC_32_PCREL). Right?
brgds, H-P