Re: [RFT] pahole 1.20 RC was Re: [PATCH] btf_encoder: Add extra checks for symbol names

[Sedat Dilek <sedat.dilek@gmail.com>]

On Wed, Feb 3, 2021 at 11:23 AM Mark Wielaard <mark@klomp.org> wrote:
>
> 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@klomp.org>
>    Date:   Sun Jan 31 01:27:31 2021 +0100
>
>        dwarf_loader: Handle DWARF5 DW_TAG_call_site like DW_TAG_GNU_call_site
>

I had some conversation with Mark directly as I dropped by accident the CC list.

With latest pahole from Git and CONFIG_DEBUG_INFO_BTF=y I was not able
to build with DWARF-v4 and DWARF-v5.

Hope it is OK for you Mark when I quote you:

> Here I use LLVM/Clang v12.0.0-rc1 with Clang's Integrated Assembler
> (make LLVM_IAS=1).

Note I haven't personally tested llvm with DWARF5. I know some other
tools cannot (yet) handle the DWARF5 produced by llvm (for example
valgrind, rpm debugedit and dwz don't handle all the forms llvm emits
when it produces DWARF5, which aren't emitted by GCC unless requesting
split-dwarf). In theory dwarves/pahole should be able to handle it
because elfutils libdw (at least versions > 0.172) does handle it. But
I don't know if anybody ever tested that. But I believe llvm will by
default emit DWARF4, not 5.

More quotes from Mark:

I would try to avoid using clang producing DWARF5. It clearly has some
incompatibilities with dwarves/pahole. It should work if you don't set
DEBUG_INFO_DWARF5. Try GCC 11 (which defaults to -gdwarf-5) or an
earlier version (probably at least GCC 8 or higher) using -gdwarf-5
explicitly.

What makes me nerves are reports from Red Hat's CKI reporting:

'failed to validate module [something] BTF: -22 '

This is was from ClangBuiltLinux mailing-list.

Looks like CONFIG_DEBUG_INFO_BTF=y makes troubles with LLVM/Clang.
Can we have a fix for Linux v5.11-rc6+ to avoid a selection of it when
CC_IS_CLANG=y?

- Sedat -


- Sedat -