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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Feb 3, 2021 at 1:48 PM Sedat Dilek <sedat.dilek@xxxxxxxxx> wrote:
>
> On Wed, Feb 3, 2021 at 11:23 AM Mark Wielaard <mark@xxxxxxxxx> 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@xxxxxxxxx>
> >    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:
>
> > 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 -



[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux