On Wed, Dec 20, 2023 at 09:44:10AM -0700, Daniel Xu wrote: > Hi Jiri, > > On Wed, Dec 20, 2023 at 10:07:34AM +0100, Jiri Olsa wrote: > > On Tue, Dec 19, 2023 at 07:15:42PM -0800, Alexei Starovoitov wrote: > > > On Tue, Dec 19, 2023 at 9:29 AM Daniel Xu <dxu@xxxxxxxxx> wrote: > > > > > > > > Hi, > > > > > > > > I was chatting w/ Quentin [0] about how bpftool could: > > > > > > > > 1. Support a "feature dump" of all supported kfuncs on running kernel > > > > 2. Generate vmlinux.h with kfunc prototypes > > > > > > > > I had another idea this morning so I thought I'd bounce it around > > > > on the list in case others had better ones. 3 vague ideas: > > > > > > > > 1. Add a BTF type tag annotation in __bpf_kfunc macro. This would > > > > let bpftool parse BTF to do discovery. It would be fairly clean and > > > > straightforward, except that I don't think GCC supports these type > > > > tags. So only clang-built-linux would work. > > > > > > > > 2. Do the same thing as above, except rather than tagging src code, > > > > teach pahole about the .BTF_ids section in vmlinux. pahole could then > > > > construct BTF with the appropriate type tags. > > > > I thought it'd be nice to have this in BTF, but to generate the .BTF_ids > > section we need the BTF data (for BTF IDs), so that might be tricky > > Isn't .BTF_ids already present in vmlinux before getting to > resolve_btfids? It looks to me like all resolve_btfids does is patch > symbols to the read BTF ID values. > > To inject BTF type tags from pahole, I don't think it needs a patched > .BTF_ids section, right? After pahole has generated all the regular > entries, it could walk .BTF_ids and try to match up symbol names with > BTF function entries. And then inject the BTF type tag. I have a working prototype. Will send out a patch later today. [...]
