public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Florian Weimer <fweimer@redhat.com>
To: Luca Boccassi <bluca@debian.org>
Cc: Nick Clifton <nickc@redhat.com>,  binutils@sourceware.org
Subject: Re: [PATCH] ld: add --package-metadata
Date: Wed, 25 May 2022 10:45:39 +0200	[thread overview]
Message-ID: <87sfoy80gc.fsf@oldenburg.str.redhat.com> (raw)
In-Reply-To: <693aa125072ed68a25d1e57aeb87bea9174f96fb.camel@debian.org> (Luca Boccassi's message of "Tue, 24 May 2022 19:38:23 +0100")

* Luca Boccassi:

> So with that experience in the bag, the most obvious next step is to
> have a first-class option, that allows a self-contained flag to be
> passed instead. After all the idea is similar to the build-id, and
> there we have a first-class option too, and it works well.

Maybe it's better to just pre-allocate space for the program header note
(and corresponding data) and patch the actual contents in later, maybe
as part of the debuginfo post-processing.

This would also side-step any shell encoding issues of the JSON object.

A really nice approach would require changes to the way we generate
coredumps: teach the dumper to copy non-allocated sections from a file
region.  Then we wouldn't have to pre-allocate section contents at all.
I think the core dumper would have to look at section headers for this,
not program headers.  We could add a program header that describes the
file region to be copied, but it would get out of sync with the file
contents if ELF editing tools don't know that it has to be updated if
non-allocated sections are changed.

Thanks,
Florian


  reply	other threads:[~2022-05-25  8:45 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-15 19:18 luca.boccassi
2022-05-16 16:40 ` Fangrui Song
2022-05-17  6:03   ` Florian Weimer
2022-05-17 14:44     ` Luca Boccassi
2022-05-25  6:56       ` Fangrui Song
2022-05-25  7:53         ` Florian Weimer
2022-05-23 11:26 ` Luca Boccassi
2022-05-24  9:34   ` Jose E. Marchesi
2022-05-24 11:26     ` Luca Boccassi
2022-05-24 16:23 ` Nick Clifton
2022-05-24 18:38   ` Luca Boccassi
2022-05-25  8:45     ` Florian Weimer [this message]
2022-05-25 13:53       ` Luca Boccassi
2022-05-30 14:08         ` Florian Weimer
2022-05-24 16:28 ` Nick Clifton
2022-05-24 21:15 ` [PATCH v2] " luca.boccassi
2022-05-25  4:30   ` Alan Modra
2022-05-25  6:02     ` Alan Modra
2022-05-25 13:42       ` Luca Boccassi
2022-05-25 13:41 ` [PATCH v3] " luca.boccassi
2022-05-26  3:55   ` Alan Modra
2022-05-26 10:46     ` Luca Boccassi

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=87sfoy80gc.fsf@oldenburg.str.redhat.com \
    --to=fweimer@redhat.com \
    --cc=binutils@sourceware.org \
    --cc=bluca@debian.org \
    --cc=nickc@redhat.com \
    /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).