From: Mark Wielaard <firstname.lastname@example.org>
To: "Guillermo E. Martinez" <email@example.com>
Cc: firstname.lastname@example.org, email@example.com
Subject: Re: [PATCH v3] strip: keep .ctf section in stripped file
Date: Tue, 28 Feb 2023 13:24:23 +0100 [thread overview]
Message-ID: <firstname.lastname@example.org> (raw)
CCed Nick to see if he knows why binutils strip does what it does.
On Fri, 2023-02-24 at 10:48 -0600, Guillermo E. Martinez wrote:
> On Fri, Feb 24, 2023 at 12:51:25PM +0100, Mark Wielaard wrote:
> > On Thu, Feb 23, 2023 at 12:42:37PM -0600, Guillermo E. Martinez via Elfutils-devel wrote:
> > > This is the third version of the patch to avoid remove the CTF section in
> > > stripped files. Changes from v2:
> > >
> > > - Rebased from master.
> > >
> > > Please let me know your thoughts.
> > >
> > > CTF debug format was designed to be present in stripped files, so
> > > this section should not be removed, so a new --remove-ctf option
> > > is added to indicate explicitly that .ctf section will be stripped
> > > out from binary file.
> > Since the way to recognize a CTF section is by name ".ctf" does it
> > really need a new option? eu-strip already has:
> > --keep-section=SECTION Keep the named section. SECTION is an extended
> > wildcard pattern. May be given more than once.
> > -R, --remove-section=SECTION Remove the named section. SECTION is an
> > extended wildcard pattern. May be given more than
> > once. Only non-allocated sections can be
> > removed.
> > Do you really need a new option? Or could you use an explicit
> > --keep-section=.ctf and/or --remove-section=.ctf ?
> Oh, I see, thanks for your comment!. My intention with this patch is to
> replicate the same proceeding by _default_ implemented in `binutils strip'
> tool, it is: not remove CTF section, except it is indicated explicitly.
O, this surprises me. I wasn't aware binutils strip keeps unallocated
sections by default. But apparently it does. It doesn't seem specific
to ".ctf". Do you know why? This seems counter to how strip is supposed
to behave, at least how I understand it.
eu-strip removes any non-allocated section (unless -g is given) which
isn't referenced through a sh_link or sh_info (with SHF_INFO_LINK set)
from a section that isn't removed. I assumed binutils strip would
behave the same. See also
(So one idea might be to reference the .ctf section through sh_link
from e.g. the .text or .data section to signal it should be kept?)
> Of course, if you think it is not really a good idea, I can propose a
> patch to change the invocation of `eu-strip' in `find-debuginfo.sh' to
> preserve CTF section as you showed above, when it generates debug
Note that find-debuginfo already has:
Use --keep-section SECTION or --remove-section SECTION to explicitly
keep a (non-allocated) section in the main executable or explicitly
remove it into the .debug file. SECTION is an extended wildcard
pattern. Both options can be given more than once.
next prev parent reply other threads:[~2023-02-28 12:24 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 [this message]
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
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).