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 <dan at debian dot org>
- Cc: binutils at sources dot redhat dot com
- Date: Thu, 5 Feb 2004 09:36:54 -0800 (PST)
- Subject: Re: GNU gcc ld script problem
> binutils@sources.redhat.com is probably most appropriate.
>
> >
> > Anyway, I think I've found a problem in the ld scripts for MIPS.
> > Basically the built in script don't seem to fill in a .plt section. So if
> > I do this:
> >
> > mips-linux-gcc prog.c
> > mips-linux-objdump -h a.out | grep plt
> >
> > I get no output, but if I use my modified linker script I get this:
> >
> > mips-linux-gcc -T tmp.ld prog.c
> > mips-linux-objdump -h a.out | grep plt
> > 10 .plt 00000030 0040052c 0040052c 0000052c 2**2
> >
> > which I believe is the correct output. The change that I made was to move
> > .stub sections into the .plt from the .text section. So this:
>
> Well, of course if you move a section with contents you'll suddenly get
> a PLT... the .stub is not a PLT in the normal sense, so why does it
> matter whether it's placed in the .plt or .text section in the binary?
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.
> The fundamental effect of your change is that .stub sections will no
> longer be interleaved with .text based on the object they are attached
> to. Instead they will all be collated before any .text or
> .gnu.linkonce.t* sections. That could be a problem, I don't know for
> sure.
It seems to work fine for me, but again I've been playing with
fairly simple test cases.
nathan
>
> >
> > .plt : { *(.plt) }
> > .text :
> > {
> > _ftext = . ;
> > *(.text .stub .text.* .gnu.linkonce.t.*)
> > /* .gnu.warning sections are handled specially by elf32.em. */
> > *(.gnu.warning)
> > *(.mips16.fn.*) *(.mips16.call.*)
> > } =0
> >
> > became this:
> >
> > .plt : { *(.plt .stub) }
> > .text :
> > {
> > _ftext = . ;
> > *(.text .text.* .gnu.linkonce.t.*)
> > /* .gnu.warning sections are handled specially by elf32.em. */
> > *(.gnu.warning)
> > *(.mips16.fn.*) *(.mips16.call.*)
> > } =0
> >
> > If anyone needs more information on this issue just let me know. It has
> > been in the MIPS tools for a while. I have been working from a recent
> > snapshot:
> >
> > 59) ./mips-linux-ld -v
> > GNU ld version 040121 20040121
> >
> > but the same issue was around way back when (MontaVista preview kit 2.1):
> >
> > 61) /opt/hardhat/previewkit/mips/fp_be/bin/mips_fp_be-ld -v
> > GNU ld version 2.10.91 (with BFD 2.10.91.0.2)
> >
> > Does anyone here have the knowledge to confirm that my changes are correct
> > and commit privileges to the binutils tree?
> >
> > nathan
> >
> > --
> > 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)
> >
> >
> >
>
>
--
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)