public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Ian Lance Taylor <ian@zembu.com>
To: mark@codesourcery.com
Cc: binutils@sourceware.cygnus.com
Subject: Re: PATCH for IRIX6/linkonce sections
Date: Mon, 19 Jul 1999 12:14:00 -0000	[thread overview]
Message-ID: <19990719191404.25527.qmail@daffy.airs.com> (raw)
In-Reply-To: <19990719094839J.mitchell@codesourcery.com>

   From: Mark Mitchell <mark@codesourcery.com>
   Date: Mon, 19 Jul 1999 09:48:39 -0700

   >>>>> "Ian" == Ian Lance Taylor <ian@zembu.com> writes:

       Ian> This sort of thing is what OTHER_RELOCATING_SECTIONS is for.
       Ian> Will it work to just define that in elf32bmipn32.sh?

   I don't think so, but perhaps I'm wrong.

   You'll have to help me a little bit.  In the rest of elf.sc, all of
   the linkonce things are handled roughly like:

     .data ${RELOCATING-0} : {
       *(.data)
       *(.data*)
       ${RELOCATING+*(.gnu.linkonce.d*)
     }

   In other words, some combination happens even when producing a
   relocateable object (the first two lines); some other combination
   happens only when RELOCATING (i.e., when producing a non-relocateable
   object) in the last line.

   I think the .MIPS.events/.MIPS.content stuff needs to be handled
   analagously.  So, OTHER_RELOCATING_SECTIONS isn't good enough; it
   doesn't apply when not relocating.

The .data* stuff doesn't have anything to do with .gnu.linkonce
sections.  That is there to handle cases in COFF where the relocation
count for a section overflows, and so multiple sections must be built
when generating a relocateable object file.

You probably do not need any equivalent to *(.data*) in your MIPS ELF
specific sections.

So that leaves us with

     .data ${RELOCATING-0} : {
       *(.data)
       ${RELOCATING+*(.gnu.linkonce.d*)
     }

If you don't name a input section in a linker script at all, the
default is to combine all the input sections of that name into an
output section of the same name.

So you shouldn't need any special behaviour when doing a relocateable
link.  You should only need special behaviour (including the
.gnu.linkonce sections) when doing a final link.  Therefore, it should
work to use OTHER_RELOCATING_SECTIONS, and use definitions which are
the equivalent of

     .data ${RELOCATING-0} : {
       *(.data)
       *(.gnu.linkonce.d*)
     }

In any case, if my argument is wrong somewhere, I think it would be
better to create something analogous to OTHER_RELOCATING_SECTIONS.
For example, you could define OTHER_RELOCATEABLE_SECTIONS or
something, and then define both with various duplications.

Ian

  reply	other threads:[~1999-07-19 12:14 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1999-07-18 22:03 Mark P. Mitchell
1999-07-19  9:37 ` Ian Lance Taylor
1999-07-19  9:45   ` Mark Mitchell
1999-07-19 12:14     ` Ian Lance Taylor [this message]
1999-07-19 12:30       ` Mark Mitchell

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=19990719191404.25527.qmail@daffy.airs.com \
    --to=ian@zembu.com \
    --cc=binutils@sourceware.cygnus.com \
    --cc=mark@codesourcery.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).