[Rpm-maint] [PATCH 3/4] Add sepdebugcrcfix to fixup old style gnu_debuglink CRC checksum.
mjw at redhat.com
Tue Jun 7 09:50:05 UTC 2016
On Tue, 2016-06-07 at 10:33 +0200, Thierry Vignaud wrote:
> On 6 June 2016 at 23:00, Mark Wielaard <mjw at redhat.com> wrote:
> > Some old tools might still use the .gnu_debuglink section to find
> > separate debuginfo files instead of build-id style lookups. When
> > dwz has compresses the .debug files the original CRC in the main
> > ELF file will no longer match. Make sure to run sepdebugcrcfix
> > after dwz to recalculate the CRC.
> > The original fix was created by Jan Kratochvil based on code
> > from GNU binutils BFD. https://bugzilla.redhat.com/show_bug.cgi?id=971119
> > I added a testcase to make sure the CRCs were all correctly
> > updated after dwz has run to compress a debuginfo package.
> WARNING: Note that the original Fedora patch has issues!
> Panu (the then upstream rpm.org maintainer) said it should _not_ be
> upstreamed when we bring the issue up:
> Once we applied this patch to rpm-4.12 in Mageia, rpm silently dropped
> the suid/sgid bits from files if they were re not explicitely listed with %attr
> This was breaking packages...
> See https://bugs.mageia.org/show_bug.cgi?id=14691
Could you provide a small example? From the bug report it isn't clear if
it really is a bug with that particular fix or that it is caused by bad
usage of attributes. If we have a small example we can create a test
case for it.
> Panu answered:
> ====================== BEGIN
> As for the "are you sure we (still) need this patch" question, the
> answer has always been "almost certainly not".
> The short summary is that the issue it fixes only is present if you
> use dwz to compress the debuginfo (like Fedora does), and even then
> case it only affects a handful of toolchain developers in the entire
> See https://bugzilla.redhat.com/show_bug.cgi?id=971119 for further
> explanation of the issue, comment #9 answers the who is affected part.
> Personally my opinion is "just kick out the stupid patch already" :)
> but judge for yourselves.
> ====================== END
I am missing some context here. But it reads like if you don't use dwz
support then it doesn't fix any real issue. So, then you can drop that
patch also. Which is true.
But you do seem to use compressed debuginfo packages. In which case it
does fix a real issue. The issue is that if you create .debug files
with .gnu_debuglink support then you need to make sure that the CRC is
calculated correctly. I included a testcase to show what that issue is
(the testcase will fail without the patch applied).
Also note that one of the goals of improving and cleaning up debuginfo
packages is so more people can easily use them, in which case it will
impact more than just a few hackers that manage to get them properly
You can certainly argue that all tools should use build-id based
identification and lookup and so we should just completely drop .debug
files and .gnu_debuglink entirely. But that seems a rather big change. I
don't know of any distro who did this or anybody who audited all the
tools and processes to make sure .debug files and .gnu_debuglink
(including correct CRCs) are unnecessary in all situations.
More information about the Rpm-maint