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

[Neal Gompa]

On Sun, Feb 21, 2021 at 10:19 PM Mark Wielaard <mark at klomp.org> wrote:
>
> 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.
>

I'm pretty sure I recently saw something that wasn't in those sizes
for Go, but I'll have to look again. The build-id support for these
languages is kind of inconsistent. :(



-- 
真実はいつも一つ！/ Always, there's only one truth!