Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [Low] rv: build failure from #ifdef inside LIBBPF_OPTS macro --
commit a53c9f566aefb8c15a1d5a3745ce6829be8b1a7a Author: Gabriele Monaco <[email protected]> tools/rv: Define CONFIG_X86_64 statically for BPF monitors This commit statically defines the CONFIG_X86_64 value via libbpf open options to bypass system Kconfig dependencies. This ensures reliable loading for the rv tool by defining the architecture at compile time. > diff --git a/tools/verification/rv/src/bpf_monitor.c > b/tools/verification/rv/src/bpf_monitor.c > index 9a3f00febfeb2..d43ee75d3904f 100644 > --- a/tools/verification/rv/src/bpf_monitor.c > +++ b/tools/verification/rv/src/bpf_monitor.c > @@ -719,7 +719,16 @@ static struct bpf_object *open_bpf_monitor(const char > *path, struct bpf_monitor_ > struct bpf_object *obj = NULL; > int res; > > - obj = bpf_object__open_file(path, NULL); > + LIBBPF_OPTS(bpf_object_open_opts, opts, > + /* Define statically as arch is known, Kconfig may not be > available */ > +#ifdef __x86_64__ > + .kconfig = "CONFIG_X86_64=y\n", > +#else > + .kconfig = "CONFIG_X86_64=n\n", > +#endif > + ); [Severity: Low] Does this #ifdef block inside the LIBBPF_OPTS macro invocation cause a build failure? Embedding preprocessor directives inside macro arguments invokes undefined behavior according to the C99 standard. Clang explicitly rejects this pattern (-Wembedded-directive), which leads to a build failure when compiling tools/rv with Clang. > + > + obj = bpf_object__open_file(path, &opts); > if (!obj) { > err_msg("bpf: error opening object: %s\n", strerror(errno)); > return NULL; -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=11
