This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: GNU gcc ld script problem
- From: Nathan Field <ndf at ghs dot com>
- To: Daniel Jacobowitz <drow at mvista dot com>
- Cc: binutils at sources dot redhat dot com
- Date: Wed, 25 Feb 2004 11:29:25 -0800 (PST)
- Subject: Re: GNU gcc ld script problem
This has been dormant for a while, but will newer binutils put the .stub
sections into their own section in the final binary? We don't really care
whether it's called a .plt section, though as Daniel notes the .stub
sections serve a similar purpose to the PLT so it seems reasonable to use
that name.
The GNU linker does this for all other archs (at least that I know of),
why should it not do it for MIPS?
nathan
On Thu, 5 Feb 2004, Daniel Jacobowitz wrote:
> On Thu, Feb 05, 2004 at 01:04:27PM -0500, Ian Lance Taylor wrote:
> > Nathan Field <ndf@ghs.com> writes:
> >
> > > But the contents of the .stub section *are* the PLT for each
> > > object. I should have been clearer about that. Perhaps the real bug is
> > > that the compiler is associating .plt sections in objects to .stub
> > > sections? As far as I can tell the only thing which is put into the .stub
> > > section is the PLT, but I've only looked at fairly simple test cases.
> >
> > In what sense is your .stub section the PLT? When using ELF the PLT
> > requires special dynamic relocations. Those are normally created
> > automatically by the linker when it builds the PLT. Do those exist
> > for your .stub section?
>
> No, MIPS does not use _JUMP_SLOT relocations. The .stub entries serve
> a similar purpose to the PLT, but they work directly out of the .got.
> Like the .plt, they are linker-generated.
>
> The net effect is basically the same.
>
>
--
Nathan Field (ndf@ghs.com) All gone.
But the trouble with analogies is that analogies are like goldfish:
sometimes they have nothing to do with the topic at hand.
-- Crispin (from a posting to the Bugtraq mailing list)