Re: [PATCH] ld: add --package-metadata

[Florian Weimer <fweimer@redhat.com>]

* Luca Boccassi:

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

But there are far fewer distributions and ELF post-processing mechanisms
than upstream build systems.  (The RPM mechanisms are even shared by
multiple RPM-based distributions which are otherwise quite dissimilar.)

If the JSON is passed as a shell argument, you have to worry about
encoding backslashes and double quotes.  When constructing the string,
you really have to know whether it will be subject to shell parsing or
not.  The current CFLAGS and LDFLAGS we have in the distribution do not
have this issue because they do not contain any shell metacharacters, so
we do not have sufficient experience with this.

I guess you could side-step this with optional base64 encoding.

> The advantage of having a common, standard and shared interface is
> that every distro that opts-in will produce the same results,

You have to get it through the package build system, though.  That's
easier with short, fixed option strings, strings which do not contain
any funny characters.

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

Fedora will switch to a different scheme if a better one becomes
available.  Even the present feature itself is redundant relative to
Fedora's build IDs, and clearly they haven't blocked implementation of
the new thing.

Thanks,
Florian