On Sat, Sep 19, 2020 at 12:58 AM Tony Ambardar <tony.ambardar@xxxxxxxxx> wrote: > > On Wed, 9 Sep 2020 at 07:27, Arnaldo Carvalho de Melo > <arnaldo.melo@xxxxxxxxx> wrote: > > > > Em Wed, Sep 09, 2020 at 11:02:24AM +0200, Ilya Leoshkevich escreveu: > > > 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: > > > [...] > > > > > > 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? > > > > The BTF loader has support for endianness, its just the encoder that > > doesn't :-\ > > > > I.e. pahole can grok a big endian BTF payload on a little endian machine > > and vice-versa, just can't cross-build BTF payloads ATM. > > > > > > 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. > > > > I agree that having this in libbpf is better, it should be done as part > > of producing the result of the deduplication phase. > > > Thanks for confirming this wasn't a case of operator error. My platforms for > learning/experimenting with BPF have been small embedded ones, including > cross-compiling to different archs, word-size and endianness, which have > "helped" me run into multiple problems till now. This one is the first I > couldn't work around however... > > [...] > > > > 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). > > > > Right, we could do it right after btf_dedup() and before > > btf_elf__write(), doing the same process as in btf_loader.c, i.e. > > checking if the ELF target arch is different in endianness and doing the > > reverse of the loader. > > > > > > Hope this plan works for you guys. > > > > > > That sounds really good to me, thanks! > > > Andrii and Arnaldo, I really appreciate your working on a proper endianness fix. > If you have a WIP or staging branch and could use some help please let me know. > I have a bunch of code changes locally. I'll clean that up, partition libbpf and pahole patches, and post them for review this week. To address endianness support, those are the prerequisites. Once those changes land, I'll be able to solve endianness issues you are having. So just a bit longer till all that is done, sorry for the wait! > Best regards, > Tony
