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

On Wed, Feb 3, 2021 at 1:48 PM Sedat Dilek [off-list ref] wrote:

On Wed, Feb 3, 2021 at 11:23 AM Mark Wielaard [off-list ref] wrote:

quoted

Hi,

On Wed, 2021-02-03 at 10:03 +0100, Sedat Dilek wrote:

quoted

quoted

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.

quoted

quoted

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 [off-list ref]
   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.

There is hardly anything actionable without all the extra info I've
asked you before. What's the issue? What's the kernel config? Tool
versions?

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

quoted

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.

And no link to the issue, of course. If you are hoping for someone to
try to help and fix issues, please provide extra info. If this is what
I think it is, that was the problem with kernel rejecting empty BTF
and it was fixed already in v5.11-fbk6. But who knows, I can only
guess.

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?

Let's first understand problems and try to fix them, please.

- Sedat -


- Sedat -