Re: ctfconvert: rc = 1 Unsupported version [_dwarf_info_load(229)]

On Fri, Nov 26, 2021 at 06:12:49PM +0200, Andriy Gapon wrote:
> On 26/11/2021 18:06, Mark Johnston wrote:
> > On Thu, Nov 25, 2021 at 10:48:36PM +0200, Andriy Gapon wrote:
> >>
> >> I've just finished builds of yesterday's CURRENT / main for arm and arm64.
> >> In both builds I got lots of messages from ctfconvert:
> >>     ctfconvert: rc = 1 Unsupported version [_dwarf_info_load(229)]
> >>
> >> I got an impression that there was a message for each object file, that's how
> >> many of them were there.
> >>
> >> I don't recall seeing those messages before.
> >>
> >> Should I be concerned?
> >> Maybe I am doing something wrong or have an unusual configuration?
> >> Any way to fix the issue?
> >>
> >> Thanks!
> >>
> >> P.S.
> >> The builds were done on stable/13, so maybe there is an issue with host tools
> >> not being able to grok something new.
> > 
> > I haven't seen this before, for what it's worth.  I presume this is from
> > a kernel build?  Does the configuration enable generation of debug info
> > with, e.g., "makeoptions DEBUG=-g"?
> 
> This is actually from buildworld.
> buildkernel is silent.

Thanks, I can reproduce it now.

Our libdwarf is complaining that the first compilation unit header in
.debug_info contains an unsupported DWARF version number (libdwarf only
supports 2, 3 and 4).  In files compiled by clang it ends up being zero.
For instance, compiling bin/cat and dumping the .debug_info section:

gcc10:
 c1250000 04000000 00000801 00000000
           ^ DWARF version
clang:
  01000000 00000000 4e230000 00000000

llvm-dwarfdump and binutils readelf are somehow still able to find a
valid-looking unit header, but I haven't yet been able to figure out how
they do that from reading the DWARF 4/5 specs or the LLVM sources.