public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Cary Coutant <ccoutant@google.com>
To: "Doug Kwan (關振德)" <dougkwan@google.com>
Cc: Ian Lance Taylor <iant@google.com>, binutils <binutils@sourceware.org>
Subject: Re: [GOLD][PATCH] Set SHF_LINK_ORDER flags of ARM EXIDX sections.
Date: Tue, 19 Oct 2010 16:33:00 -0000	[thread overview]
Message-ID: <AANLkTinBo0Bp7at3qxBcKMMbj=XWp09LLj790GVsPzn+@mail.gmail.com> (raw)
In-Reply-To: <AANLkTi=0EzZDZaDrGHaV25VvSGXEN2f6sj8H6jaUAzd8@mail.gmail.com>

> Gold does not handle SHF_LINK_ORDER flag in general, we drop the flag
> when searching for an output section.

The code you quoted is only dropping it for the purposes of looking
for an already-existing matching output section, which is the right
thing to do. As far as I can tell, if the first input section has
SHF_LINK_ORDER set, then the output section should also have it set.

All that said, the LINK_ORDER flag has no meaning at all for anything
but ET_REL files. It's a signal to the linker that the input sections
must be sorted in the same relative order as the corresponding
sections indicated by the sh_link field. Any tool that's getting
confused if LINK_ORDER isn't set in an ET_EXEC or ET_DYN file is doing
something wrong -- probably just overzealously insisting on seeing a
flag simply because it was there in their first sample output. If the
tool is trying to verify that that section is actually sorted
correctly, looking for the flag isn't a guarantee of that -- gold
doesn't actually implement the ordering implied by the flag (but it
also doesn't do any reordering that would require it to do so). It
would be better for the tool to check the actual ordering of the
section for consistency with the ordering of the corresponding
section.

Is the problem you've encountered with -r links?

-cary

  reply	other threads:[~2010-10-19 16:33 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-10-19  8:17 Doug Kwan (關振德)
2010-10-19 14:08 ` Ian Lance Taylor
2010-10-19 16:12   ` Doug Kwan (關振德)
2010-10-19 16:33     ` Cary Coutant [this message]
2010-10-19 16:52       ` Doug Kwan (關振德)
2010-10-19 16:54     ` Ian Lance Taylor
2010-10-19 18:54       ` Doug Kwan (關振德)
2010-10-19 19:29         ` Ian Lance Taylor
     [not found]         ` <AANLkTimBgvCfeY3gTPV8UkUPH2igcmhzd=LJDVF5gRgd@mail.gmail.com>
2010-10-19 20:29           ` Ian Lance Taylor
     [not found]           ` <AANLkTi=4DTSjUz5HCbU8uARWHEd8Deh3jhFYgrxqpaU2@mail.gmail.com>
2010-10-20 10:39             ` Doug Kwan (關振德)
2010-10-20 14:54               ` Ian Lance Taylor
2010-10-20 17:41               ` Cary Coutant

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='AANLkTinBo0Bp7at3qxBcKMMbj=XWp09LLj790GVsPzn+@mail.gmail.com' \
    --to=ccoutant@google.com \
    --cc=binutils@sourceware.org \
    --cc=dougkwan@google.com \
    --cc=iant@google.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).