From: Daniel Jacobowitz <dan@debian.org>
To: Nathan Field <ndf@ghs.com>
Cc: linux-mips@linux-mips.org, binutils@sources.redhat.com
Subject: Re: GNU gcc ld script problem
Date: Wed, 4 Feb 2004 23:13:17 -0500 [thread overview]
Message-ID: <20040205041317.GA4767@nevyn.them.org> (raw)
In-Reply-To: <Pine.LNX.4.44.0402041636370.7920-100000@zcar.ghs.com>
On Wed, Feb 04, 2004 at 05:24:13PM -0800, Nathan Field wrote:
> This seems like a problem specific to the linker, but it's also so
> specific to linux and MIPS that I decided to send it here first. If I was
> wrong to do that let me know and I'll send it to bug-binutils@gnu.org
> instead.
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?
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.
>
> .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)
>
>
>
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
prev parent reply other threads:[~2004-02-05 4:14 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-02-05 1:24 GNU gcc ld script problem Nathan Field
2004-02-05 4:13 ` Daniel Jacobowitz [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20040205041317.GA4767@nevyn.them.org \
--to=dan@debian.org \
--cc=binutils@sources.redhat.com \
--cc=linux-mips@linux-mips.org \
--cc=ndf@ghs.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox