From: bd1976 llvm <bd1976llvm@gmail.com>
To: Alan Modra <amodra@gmail.com>
Cc: Fangrui Song <i@maskray.me>, binutils@sourceware.org
Subject: Re: .section directives with the same name but different fields
Date: Thu, 06 Feb 2020 17:25:00 -0000 [thread overview]
Message-ID: <CAHYgJu+LHP86sCDGEyDcCAQxDi7NqdHOigBJpWxsM1C1OBJtcQ@mail.gmail.com> (raw)
In-Reply-To: <20200206140912.GE5669@bubble.grove.modra.org>
On Thu, Feb 6, 2020 at 2:09 PM Alan Modra <amodra@gmail.com> wrote:
> On Thu, Feb 06, 2020 at 01:19:14AM -0800, Fangrui Song wrote:
> > On 2020-02-06, Alan Modra wrote:
> > > On Wed, Feb 05, 2020@11:38:37PM -0800, Fangrui Song wrote:
> > > > ## Different sh_entsize
> > > >
> > > > .section .foo,"aM",@progbits,4
> > > > .section .foo,"aM",@progbits,8
> > > >
> > > > GNU as emits a warning `Warning: ignoring changed section entity
> size for .foo`
> > >
> > > I think this one probably should be an error rather than a warning.
> >
> > An error is fine, but it can bring up some implementation difficulties.
> > If an implementation does a one-pass scan over global variables to
> > emit .section directives and variable labels, it may not know sh_entsize
> > when it is about the emit the first .section directive.
> >
> > > > The output sh_entsize is 4. If the second .section defines an
> object, the object may get corrupted after merging
> > > > (https://bugs.llvm.org/show_bug.cgi?id=43457 )
> > > > For this case, we have several choices:
> > > >
> > > > 1. (Status quo) Emit one section. Set sh_entsize to 4 and emit a
> warning.
> > > > 2. Emit two sections, i.e. sh_entsize is a differentiator.
> > >
> > > If you do, the linker won't do merging of values for those sections.
> > >
> > > > 3. Emit one section. Set sh_entsize to 0. Should the assembler emit
> a warning?
> > >
> > > And remove SHF_MERGE too I guess. That's an option but I think it's
> > > better just to error.
> > >
> > > >
> > > > ## Different sh_flags
> > > >
> > > > .section .foo,"aw"
> > > > .section .foo,"a" # Warning: ignoring changed section attributes for
> .foo
> > > >
> > > > Shall we emit two sections?
> > >
> > > I don't think so. User assembly often gets section attributes wrong
> > > or leaves them off entirely for special sections known to the
> > > assembler. ie. the first .section .foo above is a built-in rather
> > > than user input.
> > >
> > > >
> > > > ## Different sh_type
> > > >
> > > > .section .foo,"a",@progbits
> > > > .section .foo,"a",@nobits # Warning: ignoring changed section type
> for .foo
> > > >
> > > > Shall we emit two sections?
> > >
> > > Again we should continue to handle the case where .foo is a special
> > > section of known type. So I think a warning rather than creating two
> > > sections is appropriate.
> >
> > Do you think the warnings should be upgraded to errors (for sh_flags and
> > sh_type)?
>
> No.
>
>
Hi Alan, thanks for the input here. I wonder if it wouldn't be more
consistent to error in all cases - even in the case of different group
signatures. The only exception would need to be for the special section
names (.text, .debug_str, etc...) that the assembler has special knowledge
of (as you explained). I wonder why creating multiple sections with the
same name for section directives with different group signatures was
implemented - why not just require the use of a distinct section name for
these? Or, now that GNU has the ",unique,N" assembly extension (
https://sourceware.org/ml/binutils/2020-02/msg00028.html) that could be
used if the section name is fixed - it would then be explicit in the source
code that another section with the same name will be created.
To be clear, currently I have to remember that..
.section .foo,"aG",@progbits,foo
.section .foo,"aG",@progbits,bar
..results in two sections implicitly. Whereas if I was required to use
different section names..
.section .foo.foo,"aG",@progbits,foo
.section .foo.bar,"aG",@progbits,bar
..or the unique extension..
.section .foo,"aG",@progbits,foo,comdat,unique,1
.section .foo,"aG",@progbits,bar,comdat,unique,2
.. then it is clear (IMO) that multiple sections will be generated.
next prev parent reply other threads:[~2020-02-06 17:25 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-06 7:38 Fangrui Song
2020-02-06 8:33 ` Alan Modra
2020-02-06 9:19 ` Fangrui Song
2020-02-06 14:09 ` Alan Modra
2020-02-06 17:25 ` bd1976 llvm [this message]
2020-02-10 5:21 ` Alan Modra
2020-03-03 21:20 ` Empty section flags Fangrui Song
2020-04-04 14:17 ` H.J. Lu
2020-04-04 16:38 ` Fangrui Song
2020-04-04 16:45 ` H.J. Lu
2020-04-13 21:32 ` Fangrui Song
[not found] ` <CAN30aBGpQecmszv-JsZwVTNrOTW0dGt4zUjas7Cx6b-B3XwjgQ@mail.gmail.com>
2020-04-04 0:43 ` Fangrui Song
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=CAHYgJu+LHP86sCDGEyDcCAQxDi7NqdHOigBJpWxsM1C1OBJtcQ@mail.gmail.com \
--to=bd1976llvm@gmail.com \
--cc=amodra@gmail.com \
--cc=binutils@sourceware.org \
--cc=i@maskray.me \
/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).