On Wed, 2022-05-25 at 10:45 +0200, Florian Weimer wrote:
> * 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.

I'm not sure - that still requires to do a lot of the work here, while
also leaving each and every distro builder to implement a whole load of
integration on their own, risking divergence to appear at some point,
while allowing for many more things to go wrong at multiple stages. The
advantage of having a common, standard and shared interface is that
every distro that opts-in will produce the same results, so that
tooling doesn't need to take these differences into account. And it
either works or not, in a single step.
The advantages would be very minimal - there is already knowledge about
specific fields, this was pretty much modelled on the existing --build-
id support, and it would still require implementation support here.

Given there seems to be some concerns with the jansson integration,
I've flipped it in v3 to be default-disabled, regardless of the status
of the build env. It now is explicit opt-in. I hope that makes the
patch more palatable?

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

Requiring such sweeping changes in the kernel (it would be a default
behaviour change, whether one opts in to this or not), which means they
need to be propagated everywhere, would take years at best, even if it
was possible, acceptable and it were to actually happen. Also, the
consumer implementation would no longer be compatible with what we have
published now in production in CBL-Mariner and Fedora.

-- 
Kind regards,
Luca Boccassi