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.
