On Thu, Feb 4, 2021 at 12:22 AM Andrii Nakryiko <andrii.nakryiko@xxxxxxxxx> wrote: > > 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. > "Do one thing and do it well." ( Unix philosophy ) https://en.wikipedia.org/wiki/Unix_philosophy#Do_One_Thing_and_Do_It_Well Yesterday, I did two things in parallel. ( I had some other stuff to dig into which is fixed for me. ) As for fun I will do a new test with <pahole.git#tmp.1.20>. I will attach kernel-config and BTF/pahole warnings. For the ClangBuiltLinux mailing-list link: I have asked on the list to have the links so that people from outlands can read them. "Just for fun" (IMHO that is the title of Linus Torvalds' biographie :-)?) - Sedat - > > > > 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 -
