Re: Problem with endianess of pahole BTF output for vmlinux

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

 



On Tue, 2020-09-08 at 13:18 -0700, Andrii Nakryiko wrote:
> On Mon, Sep 7, 2020 at 9:02 AM Ilya Leoshkevich <iii@xxxxxxxxxxxxx>
> wrote:
> > On Sat, 2020-09-05 at 21:16 -0700, Tony Ambardar wrote:
> > > Hello,
> > > 
> > > I'm using GCC 8.4.0, binutils 2.34 and pahole 1.17, compiling on
> > > an
> > > Ubuntu/x86_64 host and targeting both little- and big-endian mips
> > > running on malta/qemu. When cross-compiling Linux 5.4.x LTS and
> > > testing bpftool/BTF functionality on the target, I encounter
> > > errors
> > > on
> > > big-endian targets:
> > > 
> > > > root@OpenWrt:/# bpftool btf dump file /sys/kernel/btf/vmlinux
> > > > libbpf: failed to get EHDR from /sys/kernel/btf/vmlinux
> > > > Error: failed to load BTF from /sys/kernel/btf/vmlinux: No
> > > > error
> > > > information
> > > 
> > > After investigating, the problem appears to be that "pahole -J"
> > > running on the x86_64 little-endian host will always generate raw
> > > BTF
> > > of native endianness (based on BTF magic), which causes the error
> > > above on big-endian targets.
> > > 
> > > Is this expected? Is DEBUG_INFO_BTF supported in general when
> > > cross-compiling? How does one generate BTF encoded for the target
> > > endianness with pahole?
> 
> Yes, it's expected, unfortunately. Right now cross-compiling to a
> different endianness isn't supported. You can cross-compile only if
> target endianness matches host endianness.
> 
> > > Thanks for any feedback or suggestions,
> > > Tony
> > 
> > We have the same problem on s390, and I'm not aware of any solution
> > at
> > the moment. It would be great if we could figure out how to resolve
> > this.
> 
> I'm working on extending BTF APIs in libbpf at the moment. Switching
> endianness would be rather easy once all that is done. With these new
> APIs it will be possible to switch pahole to use libbpf APIs to
> produce BTF output and support arbitrary endianness as well. Right
> now, I'd rather avoid implementing this in pahole, libbpf is a much
> better place for this (and will require ongoing updates if/when we
> introduce new types and fields to BTF).
> 
> Hope this plan works for you guys.

That sounds really good to me, thanks!




[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