From: Tony Ambardar <tony.ambardar@gmail.com>
To: Mark Wielaard <mark@klomp.org>,
Arnaldo Carvalho de Melo <acme@kernel.org>,
Ying Huang <ying.huang@oss.cipunited.com>
Cc: Mark Wielaard <mjw@redhat.com>,
Hengqi Chen <hengqi.chen@gmail.com>,
bpf@vger.kernel.org, dwarves@vger.kernel.org,
Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Andrii Nakryiko <andrii@kernel.org>
Subject: Re: elfutils DWARF problem was: Re: Problem with BTF generation on mips64el
Date: Mon, 10 Jun 2024 23:36:54 -0700 [thread overview]
Message-ID: <Zmfwhn6inA2m1ftm@kodidev-ubuntu> (raw)
In-Reply-To: <Zl6OTJXw0LH6uWIN@kodidev-ubuntu>
On Mon, Jun 03, 2024 at 08:47:24PM -0700, Tony Ambardar wrote:
> Hi Mark,
>
> On Mon, Jun 03, 2024 at 09:18:33PM +0200, Mark Wielaard wrote:
> > On Mon, Jun 03, 2024 at 02:40:45PM -0300, Arnaldo Carvalho de Melo wrote:
> > > Couldn't find a way to ask eu-readelf for more verbose output, where we
> > > could perhaps get some clue as to why it produces nothing while binutils
> > > readelf manages to grok it, Mark, do you know some other way to ask
> > > eu-readelf to produce more debug output?
> > >
> > > I'm unsure if the netdevsim.ko file was left in a semi encoded BTF state
> > > that then made eu-readelf to not be able to process it while pahole,
> > > that uses eltuils' libraries, was able to process the first two CUs for
> > > a kernel module and all the CUs for the vmlinux file :-\
> > >
> > > Mark, the whole thread is available at:
> > >
> > > https://lore.kernel.org/all/Zl3Zp5r9m6X_i_J4@x1/T/#u
> >
> > I haven't looked at the vmlinux file. But for the .ko file the issue
> > is that the elfutils MIPS backend isn't complete. Specifically MIPS
> > relocations aren't recognized (and so cannot be applied). There are
> > some pending patches which try to fix that:
> >
> > https://patchwork.sourceware.org/project/elfutils/list/?series=31601
>
> Earlier in the thread, Hengqi Chen pointed out the latest elfutils backend
> work for MIPS, and I locally rebuilt elfutils and then pahole from their
> respective next/main branches. For elfutils, main (935ee131cf7c) includes
>
> e259f126 Support Mips architecture
> f2acb069 stack: Fix stack unwind failure on mips
> db33cb0c backends: Add register_info, return_value_location, core_note mips
>
> which partially applies the patchwork series but leaves out the support for
> readelf, strip, and elflint.
>
> I believe this means the vmlinux and .ko files I shared are OK, or is there
> more backend work needed for MIPS?
>
> The bits missing in eu-readelf would explain the blank output both Arnaldo
> and I see from "$ eu-readelf -winfo vmlinux". I tried rebuilding with the
> patchwork readelf patch locally but ran into merge conflicts.
>
> CCing Ying Huang for any more insight.
>
> Thanks,
> Tony
Hello all,
A short update, starting with answering my own question.
No, apparently the above commits *do not* complete the backend work. Ying
Huang submitted additional related patches since March 5: [1][2]
strip: Adapt src/strip -o -f on mips
readelf: Adapt src/readelf -h/-S/-r/-w/-l/-d/-a on mips
elflint: adapt src/elflint --gnu src/nm on mips
test: Add mips in run-allregs.sh and run-readelf-mixed-corenote.sh
Despite the titles, these patches do include core backend changes for MIPS.
I resolved the various merge conflicts [3], rebuilt elfutils, and retested
kernel builds to now find:
- pahole is able to read DWARF[45] info and create .BTF for modules
- resolve_btfids can successfully patch .BTF_ids in modules
- kernel successfully loads modules with BTF and kfuncs (tested 6.6 LTS)
Huzzah!
Ying:
Thank you for developing these MIPS patches. In your view, are the MIPS
changes now complete, or do you plan further updates that might improve or
impact parsing DWARF debug/reloc info in apps like pahole?
Mark:
Given that BTF usage on Linux/MIPS is basically broken without these
patches, could I request some of your review time for them to be merged? If
it's helpful, my branch [3] includes all patches with conflicts fixed, and
I also successfully ran the elfutils self-tests (including MIPS from Ying).
Please feel free to add for these patches:
Tested-by: Tony Ambardar <Tony.Ambardar@gmail.com>
Arnaldo:
Your stepping through DWARF/reloc diagnostics earlier was helpful. Thanks!
I reran your tests with the updated elfutils and latest pahole (pre-1.27),
and then found:
- everything that worked before, still works
- your observations from "btfdiff vmlinux" and 'struct dma_chan' persist
- we now see expected output from "eu-readelf -winfo netdevsim.ko"
Regarding pahole, DWARF parsing and BTF generation now works:
(with no more die__process: error messages seen)
kodidev:~/linux$ pahole -F dwarf netdevsim.ko |wc -l
14504
but strangely pahole still doesn't read its own generated BTF:
kodidev:~/linux$ pahole -F btf netdevsim.ko
libbpf: Invalid BTF string section
pahole: file 'netdevsim.ko' has no btf type information.
Poking inside a little further:
kodidev:~/linux$ ltrace -S pahole -F btf netdevsim.ko
[...]
argp_parse(0x563d47da42a0, 4, 0x7ffd5e552698, 0 <unfinished ...>
SYS_318(0x7fc385bf84d8, 8, 1, 0x7fc385ce9908) = 8
SYS_brk(0) = 0x563d47e37000
SYS_brk(0x563d47e58000) = 0x563d47e58000
<... argp_parse resumed> ) = 0
dwarves__init(0x20000, 0, -4096, 213) = 0
dwarves__resolve_cacheline_size(0x563d47da40c0, 0, 24, 213) = 64
cus__new(5, 0, 64, 213) = 0x563d47e372a0
memset(0x563d47da44c0, ' ', 127) = 0x563d47da44c0
strlen("/sys/kernel/btf/") = 16
strncmp("netdevsim.ko", "/sys/kernel/btf/", 16) = 63
cus__load_files(0x563d47e372a0, 0x563d47da40c0, 0x7ffd5e5526b0,
0x563d47da40c0 <unfinished ...>
SYS_openat(0xffffff9c, 0x7ffd5e554603, 0x80000, 0) = 3
SYS_newfstatat(3, 0x7fc385baf44f, 0x7ffd5e552210, 4096) = 0
SYS_read(3, "\177ELF\002\001\001", 4096) = 4096
SYS_close(3) = 0
SYS_openat(0xffffff9c, 0x7ffd5e554603, 0x80000, 0) = 3
SYS_fcntl(3, 1, 0, 0x7fc3859de2f0) = 1
SYS_newfstatat(3, 0x7fc385baf44f, 0x7ffd5e5521f0, 4096) = 0
SYS_pread(3, 0x7ffd5e5521f0, 64, 0) = 64
SYS_pread(3, 0x563d47e3e470, 3520, 0x4f60c8) = 3520
SYS_pread(3, 0x563d47e3f240, 525, 0x4f5eb8) = 525
SYS_pread(3, 0x563d47e3f460, 0x45dd, 0x2b1fb6) = 0x45dd
SYS_write(2, "libbpf: Invalid BTF string secti"..., 35libbpf: Invalid BTF
string section
) = 35
SYS_close(3) = 0
<... cus__load_files resumed> ) = 0xffffffff
access("netdevsim.ko", 4 <unfinished ...>
SYS_access("netdevsim.ko", 04) = 0
<... access resumed> ) = 0
fprintf(0x7fc385bf26a0, "pahole: file '%s' has no %s type"...,
"netdevsim.ko", "btf" <unfinished ...>
SYS_write(2, "pahole: file 'netdevsim.ko' has "..., 57pahole: file
'netdevsim.ko' has no btf type information.
) = 57
<... fprintf resumed> ) = 57
SYS_exit_group(1 <no return ...>
+++ exited (status 1) +++
Could you help investigate this further? Maybe a libbpf issue? For the
record, I also tried building pahole with embedded libbpf 1.4.3 without
any change. (side note: please make pahole --version also cover libbpf)
Many thanks everyone for your help,
Tony
[1]: https://patchwork.sourceware.org/project/elfutils/list/?series=31601
[2]: https://patchwork.sourceware.org/project/elfutils/list/?series=34310
[3]:
https://github.com/guidosarducci/elfutils/commits/main-fix-mips-support-reloc/
next prev parent reply other threads:[~2024-06-11 6:36 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-31 1:30 Problem with BTF generation on mips64el Tony Ambardar
2024-05-31 2:17 ` Hengqi Chen
2024-05-31 8:13 ` Jiri Olsa
2024-05-31 11:36 ` Tony Ambardar
2024-05-31 14:21 ` Jiri Olsa
2024-06-03 9:02 ` Tony Ambardar
2024-06-03 9:18 ` Jiri Olsa
2024-06-03 12:16 ` [PATCH bpf v1 0/2] bpf: Fix linker optimization removing kfuncs Tony Ambardar
2024-06-03 12:16 ` [PATCH bpf v1 1/2] Compiler Attributes: Add __retain macro Tony Ambardar
2024-06-03 13:57 ` Miguel Ojeda
2024-06-04 2:37 ` Tony Ambardar
2024-06-03 12:16 ` [PATCH bpf v1 2/2] bpf: Harden __bpf_kfunc tag against linker kfunc removal Tony Ambardar
2024-06-04 5:23 ` [PATCH bpf v2 0/2] bpf: Fix linker optimization removing kfuncs Tony Ambardar
2024-06-04 5:23 ` [PATCH bpf v2 1/2] compiler_types.h: Define __retain for __attribute__((__retain__)) Tony Ambardar
2024-06-05 5:55 ` Yonghong Song
2024-06-10 22:56 ` Tony Ambardar
2024-06-14 18:47 ` Yonghong Song
2024-06-15 6:57 ` Tony Ambardar
2024-06-17 3:26 ` Yonghong Song
2024-06-04 5:23 ` [PATCH bpf v2 2/2] bpf: Harden __bpf_kfunc tag against linker kfunc removal Tony Ambardar
2024-06-04 7:56 ` Jiri Olsa
2024-06-25 10:46 ` Geert Uytterhoeven
2024-06-26 9:52 ` Jiri Olsa
2024-06-26 11:40 ` Geert Uytterhoeven
2024-06-14 17:20 ` [PATCH bpf v2 0/2] bpf: Fix linker optimization removing kfuncs patchwork-bot+netdevbpf
2024-05-31 10:49 ` Problem with BTF generation on mips64el Tony Ambardar
2024-05-31 16:06 ` Arnaldo Carvalho de Melo
2024-05-31 21:46 ` Tony Ambardar
2024-06-03 11:20 ` Tony Ambardar
2024-06-03 14:56 ` Arnaldo Carvalho de Melo
2024-06-03 17:40 ` elfutils DWARF problem was: " Arnaldo Carvalho de Melo
2024-06-03 19:18 ` Mark Wielaard
2024-06-04 3:47 ` Tony Ambardar
2024-06-04 8:27 ` Ying Huang
2024-06-11 6:36 ` Tony Ambardar [this message]
2024-06-11 7:51 ` Tony Ambardar
2024-06-11 13:07 ` Mark Wielaard
2024-06-12 0:18 ` Tony Ambardar
2024-06-12 3:31 ` Ying Huang
2024-06-12 2:39 ` Ying Huang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Zmfwhn6inA2m1ftm@kodidev-ubuntu \
--to=tony.ambardar@gmail.com \
--cc=acme@kernel.org \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=dwarves@vger.kernel.org \
--cc=hengqi.chen@gmail.com \
--cc=mark@klomp.org \
--cc=mjw@redhat.com \
--cc=ying.huang@oss.cipunited.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.