On Thu, Apr 11, 2019 at 8:38 AM Yonghong Song <y...@fb.com> wrote: > > > cc Andrii > > On 4/11/19 12:51 AM, Daniel Borkmann wrote: > > On 04/10/2019 05:39 PM, Jakub Kicinski wrote: > >> On Wed, 10 Apr 2019 13:56:42 +0900, Prashant Bhole wrote: > >>> Let's add a way to know whether a program has btf context. > >>> Patch adds 'btf_id' in the output of program listing. > >>> When btf_id is present, it means program has btf context. > >>> > >>> Sample output: > >>> user@test# bpftool prog list > >>> 25: xdp name xdp_prog1 tag 539ec6ce11b52f98 gpl > >>> loaded_at 2019-04-10T11:44:20+0900 uid 0 > >>> xlated 488B not jited memlock 4096B map_ids 23 > >>> btf_id 1 > >>> > >>> Signed-off-by: Prashant Bhole <bhole_prashant...@lab.ntt.co.jp> > >> > >> Acked-by: Jakub Kicinski <jakub.kicin...@netronome.com> > > > > Applied, thanks! > > > > What would be the plan for the maps listing? > [...] > > I think what we could also potentially have is some way to dump > > the BTF type info based on such above id. Perhaps it would make > > sense to similarly share the verifier's printer with bpftool? > > Agreed. It does make sense to print the detailed info for a btf id > through bpftool. > > Andrii had a btf dumper to dump types as well as BTF elf file .btf.ext > contents in his private branch. Maybe Andrii can comment further > on this subject.
Yes, absolutely, we should have this as part of bpftool. I'm going to start porting this logic from my private prototype very soon. I think we should be able to have both low-level (though still human-readable) BTF dump as close to underlying BTF data as possible, as well as an ability to dump struct/union/datasec definitions in compilable C format. E.g., for struct/union it will be struct/union definition, as well as all the necessary dependent types, for datasec/vars it will be a list of global variables declaration w/ all the necessary types. Thoughts?