[Rpm-ecosystem] rpm debugedit as a separate project?

[Mark Wielaard]

Hi Neal,

On Sun, Feb 21, 2021 at 09:13:04PM -0500, Neal Gompa wrote:
> On Sun, Feb 21, 2021 at 6:59 PM Mark Wielaard <mark at klomp.org> wrote:
> > rpm-ecosystem at lists.rpm.org wrote:
> > > On Fri, Feb 19, 2021 at 09:23:58PM +0100, Mark Wielaard wrote:
> > > The main obstacle is that tools/debugedit.c currently depends on rpm:
> > >
> > > $ git grep -h rpm tools/debugedit.c
> > > #include <rpm/rpmio.h>
> > > #include <rpm/rpmpgp.h>
> > >       if (rpmDigestLength(algorithm) == build_id_size)
> > >   ctx = rpmDigestInit(algorithm, 0);
> > >     rpmDigestUpdate(ctx, build_id_seed, strlen (build_id_seed));
> > >       rpmDigestUpdate(ctx, x.d_buf, x.d_size);
> > >         rpmDigestUpdate(ctx, x.d_buf, x.d_size);
> > >             rpmDigestUpdate(ctx, d->d_buf, d->d_size);
> > >   rpmDigestFinal(ctx, &digest, &len, 0);
> >
> > Right. Forgot about needing a hashing algorithm for recreating an
> > unique build-id. This shouldn't be too hard. We can use some
> > libiberty or binutils code for that when we are upgrading the
> > hashtab code. The only trickI part is that the above let's you
> > support arbitrary sized build-ids. But in practice all build-ids
> > have the same size and there are other techniques for chsanging
> > hash sizes.
>
> This is not true in practice. Go and Rust build-id's are not the same
> size as C/C++ ones, and it'd be a problem if we assumed fixed sizes
> for that.

There are no language specific build-ids. It depends on what you tell
the linker to use. The binutils ld and gold linkers defaults to
160-bits, but also lets you choose 128-bits build-ids, or even none of
course. In theory a user could provide a fixed size hex string as
"build-id" but then it isn't really one of course. The lld linker did
experiment with 8-bit style build-ids. But backed that out when it
became clear that wasn't enough bits to generate globally unique ids
(you really need at least 128 bits for that). Depending on how you
build your Go program it might use a link process that does not
generate a build-id at all (but it will if you use the system linker
and then it will use one of the standard sizes).

Since the build-id as seen by debugedit takes up a fixed amount of
space that cannot be changed anymore (since it is embedded in the
loadable segment) it just has to deal with the length given.

The code in rpm debugedit only deals with 128, 160, 256, 384 or 512
bit build-id lengths. See the hashing algorithms it tries. So making
sure we support at least those lengths will make sure we don't regress
in support. If you find other lengths in use then I am sure we can
make the code deal with that.

Cheers,

Mark