On Fri, Jun 19, 2020 at 6:13 AM Jiri Olsa <jolsa@xxxxxxxxxx> wrote: > > On Thu, Jun 18, 2020 at 05:56:38PM -0700, Andrii Nakryiko wrote: > > On Tue, Jun 16, 2020 at 3:05 AM Jiri Olsa <jolsa@xxxxxxxxxx> wrote: > > > > > > Adding support to generate .BTF_ids section that would > > > hold various BTF IDs list for verifier. > > > > > > Adding macros help to define lists of BTF IDs placed in > > > .BTF_ids section. They are initially filled with zeros > > > (during compilation) and resolved later during the > > > linking phase by btfid tool. > > > > > > Following defines list of one BTF ID that is accessible > > > within kernel code as bpf_skb_output_btf_ids array. > > > > > > extern int bpf_skb_output_btf_ids[]; > > > > > > BTF_ID_LIST(bpf_skb_output_btf_ids) > > > BTF_ID(struct, sk_buff) > > > > > > Suggested-by: Andrii Nakryiko <andrii.nakryiko@xxxxxxxxx> > > > Signed-off-by: Jiri Olsa <jolsa@xxxxxxxxxx> > > > --- > > > include/asm-generic/vmlinux.lds.h | 4 ++ > > > kernel/bpf/Makefile | 2 +- > > > kernel/bpf/btf_ids.c | 3 ++ > > > kernel/bpf/btf_ids.h | 70 +++++++++++++++++++++++++++++++ > > > 4 files changed, 78 insertions(+), 1 deletion(-) > > > create mode 100644 kernel/bpf/btf_ids.c > > > create mode 100644 kernel/bpf/btf_ids.h > > > > > > > [...] > > > > > +/* > > > + * Following macros help to define lists of BTF IDs placed > > > + * in .BTF_ids section. They are initially filled with zeros > > > + * (during compilation) and resolved later during the > > > + * linking phase by btfid tool. > > > + * > > > + * Any change in list layout must be reflected in btfid > > > + * tool logic. > > > + */ > > > + > > > +#define SECTION ".BTF_ids" > > > > nit: SECTION is super generic and non-greppable. BTF_IDS_SECTION? > > ok > > > > > > + > > > +#define ____BTF_ID(symbol) \ > > > +asm( \ > > > +".pushsection " SECTION ",\"a\"; \n" \ > > > > section should be also read-only? Either immediately here, of btfid > > tool should mark it? Unless I missed that it's already doing it :) > > hm, it's there next to the .BTF section within RO_DATA macro, > so I thought that was enough.. I'll double check ah, linker script magic, got it > > > > > > +".local " #symbol " ; \n" \ > > > +".type " #symbol ", @object; \n" \ > > > +".size " #symbol ", 4; \n" \ > > > +#symbol ": \n" \ > > > +".zero 4 \n" \ > > > +".popsection; \n"); > > > + > > > +#define __BTF_ID(...) \ > > > + ____BTF_ID(__VA_ARGS__) > > > > why varargs, if it's always a single argument? Or it's one of those > > macro black magic things were it works only in this particular case, > > but not others? > > yea, I kind of struggled in here, because any other would not > expand the name concat together with the unique ID bit, > __VA_ARGS__ did it nicely ;-) I'll revisit this it's probably not varargs, but rather nested macro call. Macros are weird and tricky... > > thanks, > jirka >
