public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Jozef Lawrynowicz <jozef.l@mittosystems.com>
To: "H.J. Lu" <hjl.tools@gmail.com>
Cc: Michael Matz <matz@suse.de>, Binutils <binutils@sourceware.org>
Subject: Re: [PATCH] Support SHF_GNU_RETAIN ELF section flag
Date: Thu, 24 Sep 2020 17:56:51 +0100	[thread overview]
Message-ID: <20200924165651.47smzoqsc3hx2yas@jozef-acer-manjaro> (raw)
In-Reply-To: <CAMe9rOqA=XEwOQYb8dnEGH8900c-Kw0gm9PyN+MEnd5OHgKnGg@mail.gmail.com>

On Thu, Sep 24, 2020 at 06:59:07AM -0700, H.J. Lu via Binutils wrote:
> On Thu, Sep 24, 2020 at 6:49 AM Jozef Lawrynowicz
> <jozef.l@mittosystems.com> wrote:
> >
> > On Thu, Sep 24, 2020 at 06:18:05AM -0700, H.J. Lu via Binutils wrote:
> > > On Wed, Sep 23, 2020 at 1:17 PM H.J. Lu <hjl.tools@gmail.com> wrote:
> > > >
> > > > On Wed, Sep 23, 2020 at 1:04 PM Jozef Lawrynowicz
> > > > <jozef.l@mittosystems.com> wrote:
> > > > >
> > > > > On Wed, Sep 23, 2020 at 12:03:28PM -0700, H.J. Lu via Binutils wrote:
> > > > > > On Wed, Sep 23, 2020 at 11:47 AM Jozef Lawrynowicz
> > > > > > <jozef.l@mittosystems.com> wrote:
> > > > > > >
> > > > > > > On Wed, Sep 23, 2020 at 10:13:37AM -0700, H.J. Lu via Binutils wrote:
> > > > > > > > On Wed, Sep 23, 2020 at 9:52 AM Jozef Lawrynowicz
> > > > > > > > <jozef.l@mittosystems.com> wrote:
> > > > > > > > >
> > > > > > > > > On Wed, Sep 23, 2020 at 01:51:56PM +0000, Michael Matz wrote:
> > > > > > > > > > Hello,
> > > > > > > > > >
> > > > > > > > > > On Wed, 23 Sep 2020, H.J. Lu via Binutils wrote:
> > > > > > > > > >
> > > > > > > > > > > > I think that:
> > > > > > > > > > > >
> > > > > > > > > > > > >  .section .text,"ax"
> > > > > > > > > > > > >    ...
> > > > > > > > > > > > >  foo:
> > > > > > > > > > > > >    ...
> > > > > > > > > > > > >  .retain
> > > > > > > > > > > > >  retained_fn:
> > > > > > > > > > > > >    ...
> > > > > > > > > > > >
> > > > > > > > > > > > is some nice syntactic sugar compared to:
> > > > > > > > > > > >
> > > > > > > > > > > > >  .section .text,"ax"
> > > > > > > > > > > > >    ...
> > > > > > > > > > > > >  foo:
> > > > > > > > > > > > >    ...
> > > > > > > > > > > > >  .section .text,"axR"
> > > > > > > > > > > > >  retained_fn:
> > > > > > > > > > > > >    ...
> > > > > > > > > > > >
> > > > > > > > > > > > It's also partly for convenience; we have other directives which are
> > > > > > > > > > > > synonyms or short-hand for each other.
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > You don't need to keep the whole section when only one symbol should
> > > > > > > > > > > be kept.  Please drop the .retain directive.  GCC, as and ld should do the
> > > > > > > > > > > right thing with
> > > > > > > > > > >
> > > > > > > > > > > .section .text,"ax"
> > > > > > > > > > >    ...
> > > > > > > > > > > foo:
> > > > > > > > > > >   ...
> > > > > > > > > > >  .section .text,"axR"
> > > > > > > > > > >
> > > > > > > > > > >  retained_fn:
> > > > > > > > > > >
> > > > > > > > > > > where foo can be dropped and retained_fn will be kept.
> > > > > > > > > >
> > > > > > > > > > This is not what we discussed at the ABI list, the flag is per section, so
> > > > > > > > > > either the whole section is retained or not.  What you describe is
> > > > > > > > > > something else that would work on a per symbol basis, which would have to
> > > > > > > > > > be specified in a different way and might or might not be a good idea.
> > > > > > > > > > But let's not conflate these two.
> > > > > > > > >
> > > > > > > > > Also, the linker cannot currently dissect a section and remove a
> > > > > > > > > particular unused symbol anyway. Since garbage collection only operates
> > > > > > > > > on the section level, marking the section itself as "retained" seems
> > > > > > > > > most appropriate.
> > > > > > > >
> > > > > > > > It can be done.  If you put your branch on
> > > > > > > >
> > > > > > > > https://gitlab.com/x86-binutils/binutils-gdb
> > > > > > > >
> > > > > > > > I can help you implement it.
> > > > > > >
> > > > > > > It's not something I have time to look into at the moment, for now the
> > > > > > > aim is just to prevent garbage collection of sections.
> > > > > >
> > > > > > Linker and assembler already support it.   You just need to add SHF_GNU_RETAIN
> > > > > > to the framework.  Check how SHF_GNU_MBIND works.
> > > > >
> > > > > Sorry, I don't understand.
> > > > >
> > > > > Are you saying that LD already supports the garbage collection of
> > > > > individual unused symbol definitions from input sections? Whilst
> > > > > retaining other symbol definitions which are required by the program?
> > > > > I cannot find any reference to this.
> > > > >
> > > > > How does that relate to SHF_GNU_MBIND? I looked at all the references
> > > > > to "mbind" in Binutils and nothing seemed related garbage collection of
> > > > > sections, since SHF_GNU_MBIND is just used to indicate a particular
> > > > > section should be placed in a special memory area.
> > > >
> > > > For
> > > >
> > > > section .text,"ax"
> > > >    ...
> > > > foo:
> > > >   ...
> > > >  .section .text,"axR"
> > > > retained_fn:
> > > >
> > > > you need to create a new .text section with SHF_GNU_RETAIN for
> > > > retained_fn.   See get_section in obj-elf.c.  If you want to avoid
> > >
> > > See users/hjl/elf/master branch at:
> > >
> > > https://gitlab.com/x86-binutils/binutils-gdb/-/commits/users/hjl/elf/master
> > >
> > > I removed the .retain directive.
> >
> > Thanks, the formalization of section flag merging in the assembler is
> > nice.
> >
> > My only comment is that I used the "STT_*" syntax in the .type directive
> > instead of % because some targets didn't like the % syntax and emmited
> > an error. I don't remember which, maybe it was mmix-elf, in which case
> > we don't care :)
> 
> Some targets don't support @object.  %object works for all targets.

Ah yes, it is in fact the non-existent mmix-elf that can't assemble
%object but it works for all real targets.

However, some targets don't support the .bss pseudo op which is used in
your new tests, so those are failing in some cases.

Thanks,
Jozef

> 
> > When I re-test I'll see if the errors pop up again.
> >
> > I still need to add the GNU OSABI handling, but with that and your
> > patches we are probably ready to apply after a final official sign-off.
> >
> > How would that work logistically, I apply my patch and you apply yours
> > after? Or do we align off-master and apply as one patch?
> >
> 
> Please get an account on gitlab.com and send me your account name.
> Then you can put your branch in
> 
> https://gitlab.com/x86-binutils/binutils-gdb
> 
> and we can work together to finish it.
> 
> 
> --
> H.J.

  reply	other threads:[~2020-09-24 16:56 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-22 20:29 Jozef Lawrynowicz
2020-09-22 23:24 ` Hans-Peter Nilsson
2020-09-22 23:58 ` H.J. Lu
2020-09-23  1:09 ` Fangrui Song
2020-09-23  9:58   ` Jozef Lawrynowicz
2020-09-23 13:39     ` H.J. Lu
2020-09-23 13:51       ` Michael Matz
2020-09-23 16:52         ` Jozef Lawrynowicz
2020-09-23 17:13           ` H.J. Lu
2020-09-23 18:47             ` Jozef Lawrynowicz
2020-09-23 19:03               ` H.J. Lu
2020-09-23 20:04                 ` Jozef Lawrynowicz
2020-09-23 20:17                   ` H.J. Lu
2020-09-23 23:29                     ` Fangrui Song
2020-09-24 11:39                       ` Jozef Lawrynowicz
2020-09-24 19:06                         ` Fangrui Song
2020-09-24 13:27                       ` Michael Matz
2020-09-24 13:18                     ` H.J. Lu
2020-09-24 13:49                       ` Jozef Lawrynowicz
2020-09-24 13:59                         ` H.J. Lu
2020-09-24 16:56                           ` Jozef Lawrynowicz [this message]
2020-09-24 17:04                             ` H.J. Lu
2020-09-24 17:18                               ` Jozef Lawrynowicz
2020-09-24 17:37                                 ` H.J. Lu
2020-09-23 12:13 ` Jozef Lawrynowicz
2020-09-23 13:59   ` Alan Modra
2020-09-23 16:54     ` Jozef Lawrynowicz
2020-09-28 11:35 ` Pedro Alves
2020-09-28 12:28   ` Jozef Lawrynowicz
2020-09-28 14:46     ` Pedro Alves
2020-09-29 13:18       ` Michael Matz
2020-09-29 13:22         ` Jozef Lawrynowicz
2020-09-29 13:48         ` Pedro Alves
2020-09-29 13:55           ` Michael Matz
2020-09-29 14:04             ` Pedro Alves
2020-09-29 14:10               ` Michael Matz
2020-09-29 14:11                 ` Pedro Alves

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=20200924165651.47smzoqsc3hx2yas@jozef-acer-manjaro \
    --to=jozef.l@mittosystems.com \
    --cc=binutils@sourceware.org \
    --cc=hjl.tools@gmail.com \
    --cc=matz@suse.de \
    /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).