From: Mark Wielaard <email@example.com>
To: Nix <firstname.lastname@example.org>
Cc: "Guillermo E. Martinez" <email@example.com>,
Nick Clifton <firstname.lastname@example.org>,
Subject: Re: [PATCH v3] strip: keep .ctf section in stripped file
Date: Fri, 10 Mar 2023 00:08:25 +0100 [thread overview]
Message-ID: <20230309230825.GC726@gnu.wildebeest.org> (raw)
On Wed, Mar 08, 2023 at 05:45:02PM +0000, Nix wrote:
> > On Sat, 2023-03-04 at 08:00 -0600, Guillermo E. Martinez wrote:
> >> On Fri, Mar 03, 2023 at 12:24:19PM +0000, Nick Clifton wrote:
> >> > > > > I am mainly wondering why binutils strip already seems to keep ".ctf"
> >> > > > > sections (even without -g).
> >> >
> >> > > Right. But I am wondering how that mechanism works with binutils strip.
> >> > > Apparently we do something different in eu-strip which makes it
> >> > > necessary to add a --keep-ctf option based on the section name. It
> >> > > would be good if we figured out how/what we can do to keep the
> >> > > different strip utilities in sync.
> >> >
> >> > I think that the function that does this is "is_strip_section_1" in
> >> That's right, this function decided whether the section will be striped
> >> out by default, if it has set `SEC_DEBUGGING' in BFD section flags then
> >> section is removed by the default. For `.ctf' this flag is not set
> >> because in `_bfd_elf_make_section_from_shdr' when BFD sections are
> >> building it uses the section's name: ".debug", ".gnu.debuglto_.debug_",
> >> ".gnu.linkonce.wi.", ".zdebug", "lines", ".stab", etc, to set
> >> `SEC_DEBUGGING' flag.
> >> > binutils/objcopy.c. If an input section has the BSF_DEBUGGING flag
> >> > set (an internal flag to he BFD library, but basically it should be
> >> > set for all debug sections, including .ctf sections I think), then
> >> > the basic decision is to keep the section unless -g is used.
> > OK, that is interesting. So given the .ctf section is NOT marked as
> > SEC_DEBUGGING binutils strip basically never strips it.
> Can I chime in?
> This behaviour is in line with the intended purpose of CTF, which is to
> give C programs introspection into into their type systems at all times,
> via libctf, so we can use it for ABI checking, shared library interface
> construction at runtime (for dlopen()) and things like that. This is why
> keeping CTF small is basically our sole format priority: if it's big,
> people will be tempted to strip it out, and the format becomes useless.
> (This is also why it's not loadable -- libctf reads it itself so that
> it doesn't cost time paging it in if it's not used.)
> (This is also why libctf doesn't follow gnu_debuglink pointers: it can
> only read CTF from the ELF object itself.)
Yes, this all makes sense.
> > While eu-strip does strip it by default (since it is a non-loadable
> > PROGBITS section), but keeps it with -g (which only strips the
> > explicitly named .debug sections).
> It should probably keep it regardless, unless you do some sort of
> "really brutal strip" that strips out literally everything not needed
> for the program to start at all. It might well be necessary at runtime
> (in future, anyway).
Well, strip without any argument is "really brutal strip". Adding -g
makes it a "soft" strip that only strips explicitly debug sections and
symbols e.g. symtab is normally stripped, as are, at least with
eu-strip, any PROGBIT sections that aren't needed at runtime, aka
aren't marked as allocated and aren't (indirectly) referenced from any
such section, but those are kept with -g.
> > So binutils strip and eu-strip aren't totally identical with the
> > default flags, but with --keep-section=.ctf and --remove-section=.ctf
> > they seem to do the same thing.
> Yeah, this is a bug -- I simply forgot that eu-strip existed :/ sorry!
I am not entirely sure where the bug is. I would call it a bug in
binutils strip if it keeps such sections when -g isn't given.
> > So I am not sure we really need a --keep-ctf flag for eu-strip (unless
> > we also get it for binutils strip). My preference would be to just
> > recommend a user use --keep-section=.ctf or --remove-section=.ctf to
> > indicate what they want.
> My strong preference would be to make eu-strip do what binutils strip
> does. If CTF is not in the binary, the whole format is useless. If
> you've got room for the DWARF, the CTF is a strict subset of it anyway
> (it's generated from it, after all).
But why does binutils strip do that? To be honest it doesn't really
make sense to me. I don't see the logic.
If you really do want to keep the .ctf section even with eu-strip
(without -g) then you really should mark the section in some way that
shows it is needed (at runtime).
Assuming you don't want to mark the section, my suggestion would be to
use an explicit SHT_GNU_CTF section type. That will also help other
tools to know that this isn't a generic PROGBITS section but has to be
prev parent reply other threads:[~2023-03-09 23:08 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-31 2:26 [PATCH] " Guillermo E. Martinez
2022-05-31 7:06 ` Mark Wielaard
2022-05-31 10:26 ` Jose E. Marchesi
2022-05-31 12:50 ` Jose E. Marchesi
2022-06-01 4:34 ` Guillermo E. Martinez
2022-06-01 15:55 ` [PATCHv2] " Guillermo E. Martinez
2022-12-20 21:35 ` Mark Wielaard
2023-02-22 16:42 ` Mark Wielaard
2023-02-22 16:59 ` Jose E. Marchesi
2023-02-22 17:12 ` Guillermo E. Martinez
2023-02-22 23:04 ` Mark Wielaard
2023-02-23 18:34 ` Guillermo E. Martinez
2023-02-23 18:42 ` [PATCH v3] " Guillermo E. Martinez
2023-02-24 11:51 ` Mark Wielaard
2023-02-24 16:48 ` Guillermo E. Martinez
2023-02-28 12:24 ` Mark Wielaard
2023-02-28 12:45 ` Nick Clifton
2023-02-28 12:59 ` Nick Clifton
2023-02-28 14:27 ` Mark Wielaard
2023-03-03 2:40 ` Guillermo E. Martinez
2023-03-03 12:15 ` Mark Wielaard
2023-03-03 12:24 ` Nick Clifton
2023-03-04 14:00 ` Guillermo E. Martinez
2023-03-07 14:50 ` Mark Wielaard
2023-03-07 20:47 ` Guillermo E. Martinez
2023-03-08 17:45 ` Nix
2023-03-09 23:08 ` Mark Wielaard [this message]
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:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* 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).