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
