Hi,
On Wed, 2021-02-03 at 10:03 +0100, Sedat Dilek wrote:
> > It all looks to be working fine on my side. There is a compilation
> > error in our libbpf CI when building the latest pahole from sources
> > due to DW_FORM_implicit_const being undefined. I'm updating our VMs to
> > use Ubuntu Focal 20.04, up from Bionic 18.04, and that should
> > hopefully solve the issue due to newer versions of libdw. If you worry
> > about breaking others, though, we might want to add #ifndef guards and
> > re-define DW_FORM_implicit_const as 0x21 explicitly in pahole source
> > code.
I think that might be a good idea for older setups. But that also means
that the underlying elfutils libdw doesn't support DWARF5, so pahole
itself also wouldn't work (the define would only fix the compile time
issue, not the runtime issue of not being able to parse
DW_FORM_implicit_const). That might not be a problem because such
systems also wouldn't have GCC11 defaulting to DWARF5.
> > But otherwise, all good from what I can see in my environment.
> > Looking
> > forward to 1.20 release! I'll let you know if, after updating to
> > Ubuntu Focal, any new pahole issues crop up.
> >
>
> Last weekend I did some testing with
> <pahole.git#DW_AT_data_bit_offset> and DWARF-v5 support for the
> Linux-kernel.
>
> The good: I was able to compile :-).
> The bad: My build-log grew up to 1.2GiB and I could not boot in QEMU.
> The ugly: I killed the archive which had all relevant material.
I think the build-log grew so much because of warnings about unknown
tags. At least when using GCC11 you'll get a couple of standardized
DWARF5 tags instead of the GNU extensions to DWARF4. That should be
solved by:
commit d783117162c0212d4f75f6cea185f493d2f244e1
Author: Mark Wielaard <mark@xxxxxxxxx>
Date: Sun Jan 31 01:27:31 2021 +0100
dwarf_loader: Handle DWARF5 DW_TAG_call_site like DW_TAG_GNU_call_site
Cheers,
Mark
