public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Ian Lance Taylor <iant@google.com>
To: Catherine Moore <clm@codesourcery.com>
Cc: binutils@sourceware.org
Subject: Re: [RFA] Linker script extension SECTION_FLAGS
Date: Thu, 19 May 2011 00:07:00 -0000	[thread overview]
Message-ID: <mcrwrhnr1se.fsf@coign.corp.google.com> (raw)
In-Reply-To: <4DD41EB0.6040300@codesourcery.com> (Catherine Moore's message of	"Wed, 18 May 2011 15:32:00 -0400")

Catherine Moore <clm@codesourcery.com> writes:

> This patch extends the linker script language to include SECTION_FLAGS
> on an output section statement.  The purpose of the flags is to ensure
> that all input sections assigned to the output section either have the
> flags set or cleared.
>
> This version of the patch sets the infrastructure but does not define
> a backend implementation.  I will provide that along with additional
> testcases when I contribute the Powerpc VLE port.
>
> This patch was originally discussed in the thread beginning here:
> http://sourceware.org/ml/binutils/2011-04/msg00428.html
>
> Does this look okay to install?

I didn't look at the patch, but I think the documentation needs to use
some real section flags, and ideally the set of valid flags should be
defined somewhere.  It's not obvious what the valid values are.

I'm also not sure about the way it appears in a linker script.  You have
SECTION_FLAGS, which describes a constraint on the input sections
attached to an output section, next to things like AT, ALIGN, and
SUBALIGN, which describe characteristics of the output section.  That is
OK, but I think that somebody looking at a linker script is likely to
think that SECTION_FLAGS is setting flags for the output section, much
as ALIGN sets the alignment of the output section.  But that's not what
happens at all.  So perhaps the name should be something like
INPUT_SECTION_FLAGS or perhaps the constraint should be expressed
somehow inside the output section definition, in the list of input
sections, rather than outside.

Ian

  parent reply	other threads:[~2011-05-19  0:07 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-18 19:32 Catherine Moore
2011-05-18 19:33 ` Catherine Moore
2011-05-19  0:07 ` Ian Lance Taylor [this message]
2011-05-24 22:57   ` Catherine Moore
2011-05-25 12:28     ` Tristan Gingold
2011-06-06 22:02     ` PING " Catherine Moore
2011-06-07 13:11       ` Nick Clifton
2011-06-22 21:32         ` Catherine Moore
2011-06-28 11:37           ` Nick Clifton
2011-06-28 11:56             ` Tristan Gingold
2011-06-28 12:22               ` Nick Clifton
2011-06-28 13:30               ` Ian Lance Taylor
2011-06-30 21:11             ` Catherine Moore
2011-07-11 13:55               ` Nick Clifton
2012-02-09  5:27               ` Alan Modra
2011-05-19  7:44 ` Tristan Gingold

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=mcrwrhnr1se.fsf@coign.corp.google.com \
    --to=iant@google.com \
    --cc=binutils@sourceware.org \
    --cc=clm@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).