Comment # 19 on bug 1190434 from David Mair

(In reply to David Mair from comment #18)
> (In reply to David Mair from comment #17)
> > I reproduced the following with Tumbleweed's current crash version 7.3.1 and
> > kernel 6.0.8-1:
> > 
> > > Dwarf error: wrong version in compilation unit header (is 5, should be 2, 3, or 4)
> > 
> > I'm working on a crash 8.0.2 upgrade and as I expected, that error is
> > resolved with crash 8.0.2 and kernel 6.0.8-1 vmcore. However, I do have a
> > subsequent problem where crash can't read the linux banner from core memory
> > leading to a claimed mismatched vmcore and vmlinux even though they have
> > filenames with the same version number.
> > 
> 
> The good news is that new problem of mine is known to upstream crash and has
> an accepted patch. I'm trying it today.

Well, I'm afraid not...

I have built a version of crash that appears to support dwarf 5, crash 8.0.2.
However, it fails verifying the kernel and coredump are the same kernel (6.0.x)
version. The upstream fix for the reported error message ("linux_banner is an
invalid address) is both of:

1) Already present in the source of crash I'm building; and
2) Was a change to support all representations of a symbol being present in the
initialized data section of the kernel binary (the patch added 'd' location
type support to existing 'D' location type only). BUT, when I dump the symbols
from the kernel binary it is in the 'D' initialized data section anyway so the
patch wasn't needed for the Tumbleweed kernel (the difference occurs based on
the compiler used).

It should be noted that when creating a coredump on Tumbleweed (kernel 6.0.8
and 6.0.10), makedumpfile reports that "this kernel isn't supported by
makedumpfile" and if my end-result in crash is that a valid symbol in the
kernel binary named linux_banner has a Kernel Address in the coredump, accessed
via use of KVADDR() in crash, that is considered an invalid address and fails,
preventing the verification that the linux version in the binary and coredump
are the same then I offer the opinion that makedumpfile appears to be not
up-to-date for kernel 6. As observed when using a crash version in a home
project that is up-to-date for kernel 6.

Unless someone corrects my explanation of my opinion of the current error I
observe in crash 8.0.2 then I believe at least makedumpfile needs to be fixed
as well as crash to wholly resolve the reported problem. Input welcomed...