public inbox for
 help / color / mirror / Atom feed
From: "mark at klomp dot org" <>
Subject: [Bug debugedit/31504] debugedit writes out ELF file even when nothing has been updated
Date: Fri, 22 Mar 2024 12:29:00 +0000	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

Mark Wielaard <mark at klomp dot org> changed:

           What    |Removed                     |Added
         Resolution|---                         |FIXED
             Status|ASSIGNED                    |RESOLVED

--- Comment #6 from Mark Wielaard <mark at klomp dot org> ---
(In reply to Allan McRae from comment #5)
> > I can add a check to see if there actually were any changes and if there aren't simply not call elf_update at all. But I suspect that is really a corner case that doesn't occur that often. At least why would you call debugedit explicitly asking to rewrite things and then expect it to not actually do that?
> Our packaging system checks for ELF files and tries generating associated
> debug packages with source files and debug symbols.  It turns out there are
> a lot of packages that provide a .NET 8.0 self-contained/ single-file
> application, which is and ELF file and did not enjoy being processed by
> debugedit.

I understand that. And I think these aren't really "ELF" files because they add
something to the file that isn't described by the ELF structures. What I don't
fully understand is why you are expecting debugedit to NOT change the debug
path strings when you are asking it to. Is this because there file don't
actually contain any .debug sections?

> The v2 patch fixes the issue we observed.

Thanks for double checking. Pushed:

commit 6dd28bb30320e5236b3b5f79b6b2b41d2b2317bd
Author: Mark Wielaard <>
Date:   Mon Mar 18 23:37:47 2024 +0100

    debugedit: Only write the ELF file when updating strings or build-id

    Only open the ELF file read/write and write out the data if we
    actually did any elf structure update or updating the build-id.

            * tools/debugedit.c (fdopen_dso): Call elf_begin with
            ELF_C_READ when not changing dest_dir or build_id,
            otherwise use ELF_C_RDWR.
            (main): Call open with O_RDONLY when not changing dest_dir
            or build_id, otherwise use O_RDWR. Call elf_update with
            ELF_C_WRITE when rewriting any string, updating any ELF
            structure or build_id.

    Signed-off-by: Mark Wielaard <>

You are receiving this mail because:
You are on the CC list for the bug.

  parent reply	other threads:[~2024-03-22 12:29 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-17 14:46 [Bug debugedit/31504] New: " mark at klomp dot org
2024-03-18  8:20 ` [Bug debugedit/31504] " sam at gentoo dot org
2024-03-18 22:40 ` mark at klomp dot org
2024-03-21  0:05 ` allan at archlinux dot org
2024-03-21 11:46 ` mark at klomp dot org
2024-03-21 12:07 ` mark at klomp dot org
2024-03-21 21:23 ` allan at archlinux dot org
2024-03-22 12:29 ` mark at klomp dot org [this message]
2024-03-22 22:13 ` allan at archlinux dot org
2024-03-22 23:47 ` mark at klomp dot org
2024-04-29 19:59 ` jamin.collins at gmail dot com
2024-05-15 11:34 ` mark at klomp dot org

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:

* 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).