On Sun, Feb 21, 2021 at 10:19 PM Mark Wielaard <m...@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 <m...@klomp.org> wrote: > > > rpm-ecosystem@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! _______________________________________________ Rpm-ecosystem mailing list Rpm-ecosystem@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-ecosystem