Re: pahole generates invalid BTF for code compiled with recent clang

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

 



On Wed, Jun 24, 2020 at 12:12 PM Arnaldo Carvalho de Melo
<arnaldo.melo@xxxxxxxxx> wrote:
>
> Em Wed, Jun 24, 2020 at 12:06:24PM -0700, Andrii Nakryiko escreveu:
> > On Wed, Jun 24, 2020 at 11:57 AM Arnaldo Carvalho de Melo
> > <arnaldo.melo@xxxxxxxxx> wrote:
> > >
> > > Em Wed, Jun 24, 2020 at 11:40:21AM -0700, Andrii Nakryiko escreveu:
> > > > On Wed, Jun 24, 2020 at 10:57 AM Arnaldo Carvalho de Melo
> > > > <arnaldo.melo@xxxxxxxxx> wrote:
> > > > >
> > > > > Em Wed, Jun 24, 2020 at 10:41:10AM -0700, Andrii Nakryiko escreveu:
> > > > > > On Wed, Jun 24, 2020 at 4:07 AM Lorenz Bauer <lmb@xxxxxxxxxxxxxx> wrote:
> > > > > > >
> > > > > > > Hi,
> > > > > > >
> > > > > > > If pahole -J is used on an ELF that has BTF info from clang, it
> > > > > > > produces an invalid
> > > > > > > output. This is because pahole rewrites the .BTF section (which
> > > > > > > includes a new string
> > > > > > > table) but it doesn't touch .BTF.ext at all.
> > > > > >
> > > > > > Why do you run `pahole -J` on BPF .o file? Clang already generates
> > > > > > .BTF (and .BTF.ext, of course) for you.
> > > > > >
> > > > > > pahole -J is supposed to be used for vmlinux, not for clang-compiled
> > > > > > -target BPF object files.
> > > > >
> > > > > yeah, I was thinking this was for a vmlinux generated by clang, which,
> > > > > from the commands below (the suffix _prog.o) should have told me this is
> > > > > a target BPF object file.
> > > > >
> > > > > But then, if one insists for some reason in generating BTF from the
> > > > > DWARF in a BPF target object file, stripping .BTF.ext, if present, is
> > > > > the right thing to do at this point.
> > > >
> > > > I disagree. Those who insist probably have some wrong conceptual
> > > > understanding and it's better to fix that (understanding), rather than
> > > > lose focus and bend tool to do what it's not supposed to do and
> > > > ultimately cause more confusion.
> > >
> > > So we can instead notice the presence of .BTF.ext when the user calls
> > > 'pahole -J' on a target BPF object file and bail out, only allowing it
> > > to convert from DWARF to BTF and thus encode the .BTF elf section when
> > > .BTF.ext isn't present, as we can't easily figure out if the present of
> > > just .BTF section was done by clang or pahole on a BTF target object
> > > file built without -g.
> >
> > Can't we check ELF's target machine and reject if it's a BPF one?
>
> I think there is value in allowing pahole to convert DWARF to BTF even
> for a BPF target object file, say in some case people may think clang is
> not generating correct BTF so one may want to see what pahole generates
> and compare.

sure, and will the warning for wrong architecture would give a hint
that it's not the right thing to do, probably. Or we could have more
specific message for BPF target. I don't care all that much.


>
> > Someday we might also support "cross-compilation" to be able to dedup
> > arm ELF from x86 machine. It's sort of ok today for little-endian
> > ARMs, so maybe not outright reject if architecture is not the same as
> > the local one?
>
> I think outright reject if arch is not t he same it not necessary.
>
> We may warn the user that using -g in clang is the preferred method for
> generating BTF, wdyt?
>

sounds reasonable

> - Arnaldo
>
> > >
> > > - Arnaldo
> > >
> > > > pahole's BTF conversion is really driven towards kernel use-case
> > > > (e.g., with global variables, etc). I wouldn't distract ourselves with
> > > > supporting de-duplicating BPF object files. Single .o's BTF is already
> > > > deduplicated as produced by Clang. Once we add static linking of
> > > > multiple BPF .o's (which I hope to start working on very soon), that
> > > > de-duplication will be handled automatically by libbpf (and hopefully
> > > > integrated into lld as well), among many other things that need to
> > > > happen to make static linking work.
> > > >
> > > > >
> > > > > - Arnaldo
> > > > >
> > > > > > >
> > > > > > > To demonstrate, on a recent check out of bpf-next:
> > > > > > >     $ cp connect4_prog.o connect4_pahole.o
> > > > > > >     $ pahole -J connect4_pahole.o
> > > > > > >     $ llvm-objcopy-10 --dump-section .BTF=pahole-btf.bin
> > > > > > > --dump-section .BTF.ext=pahole-btf-ext.bin connect4_pahole.o
> > > > > > >     $ llvm-objcopy-10 --dump-section .BTF=btf.bin --dump-section
> > > > > > > .BTF.ext=btf-ext.bin connect4_prog.o
> > > > > > >     $ sha1sum *.bin
> > > > > > >     1b5c7407dd9fd13f969931d32f6b864849e66a68  btf.bin
> > > > > > >     4c43efcc86d3cd908ddc77c15fc4a35af38d842b  btf-ext.bin
> > > > > > >     2a60767a3a037de66a8d963110601769fa0f198e  pahole-btf.bin
> > > > > > >     4c43efcc86d3cd908ddc77c15fc4a35af38d842b  pahole-btf-ext.bin
> > > > > > >
> > > > > > > This problem crops up when compiling old kernels like 4.19 which have
> > > > > > > an extra pahole
> > > > > > > build step with clang-10.
> > > > > >
> > > > > > I was under impression that clang generates .BTF and .BTF.ext only for
> > > > > > -target BPF. In this case, kernel is compiled for "real" target arch,
> > > > > > so there shouldn't be .BTF.ext in the first place? If that's not the
> > > > > > case, then I guess it's a bug in Clang.
> > > > > >
> > > > > > >
> > > > > > > I think a possible fix is to strip .BTF.ext if .BTF is rewritten.
> > > > > > >
> > > > > > > Best
> > > > > > > Lorenz
> > > > > > >
> > > > > > > --
> > > > > > > Lorenz Bauer  |  Systems Engineer
> > > > > > > 6th Floor, County Hall/The Riverside Building, SE1 7PB, UK
> > > > > > >
> > > > > > > www.cloudflare.com
> > > > >
> > > > > --
> > > > >
> > > > > - Arnaldo
> > >
> > > --
> > >
> > > - Arnaldo
>
> --
>
> - Arnaldo



[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux