Re: [Rpm-ecosystem] build rpm debuginfo package when cross compiling

[Mark Wielaard]

Hi,

Adding the debugedit list to the CC because that project maintains the
find-debuginfo script now: https://sourceware.org/debugedit/

On Sun, Nov 14, 2021 at 08:09:08PM +0800, abstrakta wrote:
> I'm building some rpm packages from cross compiled binaries.
> My build system is x86_64.I want to build rpm package installed in arm64.
> I use --target option to set the target cpu architecture arm64.
> 
> rpmbuild -bb abc.spec --target=arm64-linux
> 
> In building debuginfo package,There are some warnings.
> 
> extracting debuginfo xx from xx
> xz: /vat/tmp/xx No such files or Directories.
> objcopy: No such files /vat/tmp/xx or Directories.

Those come from add_minidebug () and seems to be caused by mktemp not
working as expected?

> The console log shows this warning is from
> /usr/lib/rpm/find-debuginfo.sh.It's a shell script. It seems to use
> "nm -D" directly to get debuginfo,which use /usr/bin/nm.The command
> nm is architecture-specific.So the debuginfo of arm64 is not
> processed correctly by nm of x86_64.When I softlink /usr/bin/nm to
> aarch64-linux-nm,the above warnings disappeared.Debuginfo package
> works well.

That is interesting. I hadn't realized, but yes, when doing a
cross-build add_minidebug will probably not work because some of the
binutils tools may not understand/work for cross-binaries (without
prefix). Maybe we should rewrite the script as yet another tool based
on libelf that does work for any arch.

> With further search,the /usr/lib/build-id/xxx.debug file is stripped
> using /usr/bin/eu-strip, it does strip out the debuginfo of
> arm64.There are other binary tool like
> eu-nm,eu-ld,eu-addr2line. These eu-* command is from package
> elfutils.Can x86_64's eu-* command support processing arm64 binaries
> directly?Does eu-* command support mips64 or other more arch?

The eu- (elfutils) tools work against any architecure for which there
is a backend. elfutils doesn't have an objcopy tool though (maybe it
should). There is no mips64 support in elfutils though (Debian has a
mips64 elfutils backend, but it was never upstreamed).

> I define rpm macros __nm, __strip.The shell scripts in /usr/lib/rpm/
> seems not to use these macros.It doesn't work.Beacause these shell
> scripts use nm and eu-strip directly, which is wrong in processing
> cross compiled binaries.
>
> Can rpmbuild support cross-packging the corresponding debuginfo
> pakcage when cross compiling?
>
> Are there some better ways to set the correct cross binutils with
> prefix aarch64-linux- for nm,strip,ld,...?

I am not sure what the best way is to communicate that rpmbuild is
doing a crossbuild to the debugedit scripts.

Cheers,

Mark

___
Rpm-ecosystem mailing list
Rpm-ecosystem@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-ecosystem

Re: [Rpm-ecosystem] debugedit project setup

[Mark Wielaard]

Hi Panu,

I added debuge...@sourceware.org to the CC.

On Tue, Mar 23, 2021 at 03:52:53PM +0200, Panu Matilainen wrote:
> On 3/23/21 2:29 PM, Panu Matilainen wrote:
> > On 3/22/21 7:42 PM, Mark Wielaard wrote:
> > > There is a test debugedit-0.1 release to see whether this works. But I
> > > would like to make sure first that things are setup so that flatpak and
> > > rpm can use this as is before people start packaging it. Once we know
> > > it can be used as replacement for the built-in rpm/flatpak debugedit we
> > > do a proper debugedit 1.0 release.
> > 
> > Awesome. I'll make it a priority to see that we transition, if at all
> > possible, to the external debugedit in rpm 4.17 already. Stay tuned...
> 
> FWIW, here's a quick-n-dirty package of debugedit 0.1:
> 
> https://laiskiainen.org/rpm/debugedit/

Nice, thanks.  Would it make sense to add the debugedit.spec to the
debugedit sources themselves so people can easily create an rpm?

Does it actually make sense to install everything under bindir?
Originally in rpm the tools were installed under /usr/lib/rpm/ because
they were only invoked indirectly through rpm. If we see them as tools
that no user/admin/developer will ever invoke directly maybe they
should be installed under /usr/libexec/ instead?

Cheers,

Mark
___
Rpm-ecosystem mailing list
Rpm-ecosystem@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-ecosystem

[Rpm-ecosystem] debugedit project setup

[Mark Wielaard]

Hi,

As discussed I setup a separate debugedit project:
https://sourceware.org/debugedit/

It contains the debugedit and sepdebugcrcfix programs and the find-
debuginfo.sh script and the debugedit.at testsuite. I used git-filter-
repo to keep the git history of the files from the rpm repo. Then I
resynced the libiberty and binutils files and added a minimal
automake/autoconf/autotest build system. Replace popt with getopt
argument parsing. And use libiberty md5 or sha1 instead of rpmDigest
algorithms for build-id updates.

There is a test debugedit-0.1 release to see whether this works. But I
would like to make sure first that things are setup so that flatpak and
rpm can use this as is before people start packaging it. Once we know
it can be used as replacement for the built-in rpm/flatpak debugedit we
do a proper debugedit 1.0 release.

Please join the debugedit mailinglist for discussions:
https://sourceware.org/mailman/listinfo/debugedit

File bugs or feature requests:
https://sourceware.org/bugzilla/enter_bug.cgi?product=debugedit

Checkout the git repo:
git clone git://sourceware.org/git/debugedit.git

I have played a bit with pagure, but haven't set it up properly, sorry.
So for now we'll do patches by email.

Cheers,

Mark
___
Rpm-ecosystem mailing list
Rpm-ecosystem@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-ecosystem

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

[Mark Wielaard]

Hi,

On Mon, Feb 22, 2021 at 08:53:43AM +0100, Alexander Larsson wrote:

> However, a better alternative would be for flatpak to consume the
> upstream version as a git submodule (that gets dist:ed with the
> tarball). That is what flatpak does with some other external
> dependencies. Sometimes it even has a both a --use-system switch and
> a git submodule fallback.
>
> Does that seem realistic?

I don't have any experience with using git submodules, but I assume
that is a vote for debugedit being its own small project. It also
sounds like an ideal setup to do continious integration testing by
simply update the submodule and run the flat-builder testsuite to make
sure the debugedit submodule didn't break anything.

> If you have issues setting up flatpak-builder tests, reach out to me.

I will once I setup the buildbot, it probably is something to do with
the gpg setup. error: Unknown option --token-type=0

Thanks,

Mark
___
Rpm-ecosystem mailing list
Rpm-ecosystem@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-ecosystem

Re: [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  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 
> > > #include 
> > >   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, , , 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
___
Rpm-ecosystem mailing list
Rpm-ecosystem@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-ecosystem

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

[Mark Wielaard]

Hi,

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 
> #include 
>   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, , , 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.

Thanks,

Mark
___
Rpm-ecosystem mailing list
Rpm-ecosystem@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-ecosystem

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

[Mark Wielaard]

Hi,

Dmitry V. Levin wrote:
> On Sun, Feb 21, 2021 at 10:49:03AM -0500, Neal Gompa wrote:
> [...]
>> I'm also not comfortable with the idea of having a part of RPM itself
>> broken out and transferred to a project with subpar contribution
>> practices. Most of Sourceware still relies on the email workflow for
>> contribution of fixes and improvements. While you are the main
>> contributor the last few years (and you don't use GitHub), you are not
>> the only one, and you are the only one who uses the email workflow. If
>> Sourceware projects had something like Pagure overlaid on their Git
>> repos where they could also take pull requests properly, then I'd be
>> more comfortable with it.
>
> On the contrary, I believe all potential debugedit contributors are
> perfectly fine with email workflow used e.g. in elfutils.
>
>> If we really want to split it out, we could just split it out here in
>> the rpm-software-management GitHub org. That's where popt lives
>> too[1]. Also, popt is definitely used by more than just RPM stuff, so
>> I don't know why you noted it as if it's a problem.
>
> I don't think the choice of hosting is important at this stage of
> discussion, but you're well aware that github is out of the consideration
> for the reason you mentioned above.

I would be happy to try setting up pagure on sourceware even though I believe a 
simple email based approach encourages more discussion on patches. I am not 
against forges on principle. It might actually help with the buildbot 
integration. I don't really like github as a centralized proprietary forge 
however. It isn't even possible to create an account there without using 
non-free JavaScript.

Neal and I do seem to differ of opinion on whether debugedit is mainly part of 
the rpm-ecosystem or is mainly one of the sourceware tools for inspecting and 
manipulation of ELF/DWARF.

Cheers,

Mark
___
Rpm-ecosystem mailing list
Rpm-ecosystem@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-ecosystem

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

[Mark Wielaard]

Hi all,

rpm debugedit has grown from a quick hack that simply listed/replaced
some files/strings to an almost full blown DWARF reader/writer. It is
now also used outside rpm(build). Debian packages it separately and
Flatpak builder has an embedded copy it uses to post-process debuginfo.

It is currently not always easy to update because the people who
contribute to debugedit are often not regular rpm contributors. And the
release cycle of rpm doesn't always match up with the release cycle of
the GNU toolchain. So it sometimes needs a release at a different time
than rpm gets released.

There have been some requests to have it moved from rpm to elfutils:
https://sourceware.org/bugzilla/show_bug.cgi?id=27351
But I think it would be simpler to have it be its own project, so it
isn't tied to another projects release schedule and processes.

So my proposal is to:

- Create a debugedit project on sourceware, so it is close to binutils,
  from which it sometimes steals code, elfutils on which it relies for
  libelf/libdw, and dwz which is a similar, but completely different
  DWARF processor. Most people currently contributing to rpm debugedit
  should already have an account there.

- Import tools/debugedit.c tools/hashtab.c tools/hashtab.h and
  tests/debugedit.at from rpm. Add a minimal build using autoconf and
  autotest around this. Update the hashtab files from libiberty,
  check debugedit (and sepdebugcrc checkm see below) for updates
  which came in from binutils. Note, it also has a popt dependency.

- Setup buildbot using builder.wildebeest.org/buildbot which has
  support for debian/fedora/centos, armhf, i386, x86_64, aarch64,
  s390x, ppc64 and ppc64le.

- Provide patches for rpm to have some kind of --with-system-debugedit
  configure flag so it won't build and install its own debugedit
  but picks up an installed debugedit on the system.

- Provide patches for flatpak-builder to use debugedit like it already
  uses eu_elfcompress and eu_strip, instead of calling
  builder_get_debuginfo_file_references.

- Setup the buildbot so it runs the rpm and flatpak-builder testsuites
  against debugedit to make sure we keep compatibility.

  This should in theory be easy because both have testsuites that
  should be zero-fail. But in practice I never got the flatpak-builder
  tests all green because I don't understand what it is doing with
  gpg-agent. And I always trip over the usage of fakechroot in the rpm
  testsuite, on some setups it seems fakechroot is just totally broken?

An open question is for how long rpm and flatpak-builder want to keep
their internal implementation. And if so, how we keep them in sync. Or
if we simply decide that once debugedit is ready as separate project
the next release of rpm and flatpak-builder will simply require
debugedit as external executable.

Another question is whether the separate debugedit project should also
adopt some of the other related tools like sepdebugcrcfix, elfdeps and
maybe scripts/find-debuginfo.sh? sepdebugcrcfix and elfdeps seem easy
to adopt. find-debuginfo.sh is very tightly linked to how rpm builds
debuginfo/sources subpackages. But maybe it could be made a little bit
more generic? But if so, keeping compatibility might be tricky.

I don't think a separate debugedit project needs much maintenance once
setup. But there are a couple of items to work on. In particular
support for DWARF5 as emitted by alternative compilers and handling
Split Dwarf.

Comments and feedback more than welcome.

Cheers,

Mark
___
Rpm-ecosystem mailing list
Rpm-ecosystem@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-ecosystem

Re: [Rpm-ecosystem] Trying to understand %buildsubdir and debuginfo generation

[Mark Wielaard]

Hi,

On Fri, 2018-04-27 at 11:34 +0300, Panu Matilainen wrote:
> On 04/27/2018 06:47 AM, Jason L Tibbitts III wrote:
> > Here's a paste from the macros that Fedora uses
> > (/usr/lib/rpm/redhat/macros):
> > 
> > %install %{?_enable_debug_packages:%{?buildsubdir:%{debug_package}}}\
> > %%install\
> > %{nil}
> 
> Ew. Now there's a blast from the past, that ugly %install override is 
> from 2002 when debuginfo was a fairly new concept. If that's actually 
> needed for debuginfo then it's a bug (in rpm).

I admit to not precisely know the macro expansion rules or when, what
defines buildsubdir. (I always assumed just having a %setup macro was
enough to get it defined). But I do know why the buildsubdir macro is
necessary for autogenerating debuginfo/sources packages.

The idea is that the debuginfo comes from the (installed) binaries, it
gets stripped out and put into separate (.debug) files which get
packaged together with some auxiliary information generated by the
debuginfo scripts (like .dwz files).

This debug information might reference source code files. For some
profiling/tracing/debugging applications having access to the
(generated) source files might be helpful. But you only want to package
up the actual source files used to generate the binaries. So those that
are actually referenced in the debuginfo, not other files that might be
in the srpm but never used, nor source/include files from other (devel)
package that happen to be installed.

To know which source files to package the source named in the .debug
files needs to be matched against the actual source files (produced) by
the package. To do that you will need to know the buildsubdir. Only
files inside the buildsubdir should be packaged as debugsources. e.g.
the debuginfo might also reference /usr/include/stdio.h, but you don't
want that packaged.

Also in the future packages might be build with -gsplit-dwarf which
places (most) debug information in separate .dwo files, which will
never be installed, but will be kept in the buildsubdir from which it
will have to be fetched and packaged.

Cheers,

Mark
___
Rpm-ecosystem mailing list
Rpm-ecosystem@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-ecosystem

Re: [Rpm-ecosystem] Improving debuginfo packages

[Mark Wielaard]

Hi,

Since every project these days needs a todo list in the cloud I created
one for improving rpm debuginfo packages:
http://taiga.fedorainfracloud.org/project/mjw-better-rpm-debuginfo-package-creation/kanban

Various patches from Fedora have already been extended with testcases
and posted. The separate build-id links patch is in progress (still
needs more testcases). I am committed to add at least #5 make build-ids
unique, #6 unique .debug file names and #7 unique source file
directories. I would really like to see the others also added to rpm
upstream, but don't know if I have enough time for that.

Please let me know if you think something is missing, if I am
describing/doing something wrongly, or if you could help push some of
these changes forward.

Thanks,

Mark
___
Rpm-ecosystem mailing list
Rpm-ecosystem@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-ecosystem