On 9/22/22 16:11, Adrian Moreno wrote:
On 9/22/22 13:15, Eelco Chaudron wrote:On 22 Sep 2022, at 12:03, Adrian Moreno wrote: <SNIP>I'm not a fan of this. Any updates to these structs needs to be mirrored across the codebase. I think it might be better to do something else.I agree with this, but for keeping things simple and not replicating this in all scripts (see the previous patch you mentioned). I thought it would be easier to have it in a single file.For example, maybe we can use a pyelf extension to probe for the actual struct info if compiled with '-g' - something like that. Or, perhaps we can use a stringify-ing macro and cli command that will print a lite header that we can include. Otherwise, this is two areas struct info needs to be maintained, and it will get out of sync. Heck, even auto-generating it after the build with GDB is something that I would prefer to hardcoding (something like ptype <struct ...>, which does require compiling with '-g').All this sounds nice, but is not something that is easily added. Think about structure references, inclusion, and recursion. I know Adrian is researching this for another project, so we might get this in the near future :)What I'm looking into is collecting type information from dwarf sections (either from the binary compiled with "-g" or - more likely - debuginfo files) and injecting type-offset information into the ebpf program dynamically.Apart from the reasons already mentioned, I aim to provide CO-RE ebpf programs so the header-generation is not a solution for me. Also, note my project is written in rust. Considering all this, I'm not sure if any of the code I'm working on would be useful here, although maybe the idea and pitfalls I find in the way might be.For this case, having a dwarf-to-header converter shouldn't be very difficult. If the target user is the end-user (who probably installed a package from a distribution) requiring a debug package is not that bad. If it's a developer, requiring "-g" _might_ also be OK.I was assuming you would do some magic with converting this to BTF information, so the clang could just use it with the __attribute__((preserve_access_index)). This way we do not need to put in the full structure, etc. Did you think of doing this?I did, and I'll probably try. However, last time I checked pahole cannot generate BTF from dwz-compressed debuginfo files and we don't ship with BTF sections in ovs. So even if I collected BTF information at build time, I don't know how would I be able to get the target BTF information to perform relocation.It looks like pahole can generate BTF info, this might be worth trying if it can do this for the OVS executable. If I get some time I’ll try to look at it. If you do in the meantime, please let me know.Maybe you don't need to run it on the entire OVS executable, just on a small one that uses the same structs as your bpf code.
I tried moving 'struct dpif' to the .h file and using this dummy program:
#include "ofproto-dpif-upcall.h"
int main() {
struct udpif _u = {0};
return 0;
}
I was able to generate a header file that _almost_ [1] makes Eelco's bcc program
compile using:
# Build with -g: clang main.c -Iovs/ofproto -Iovs/lib -I ovs/include -L ovs/lib/.libs/ -g -gdwarf # Generate BTF: pahole -J --btf_gen_all a.out # Dump BTF in C format: bpftool btf dump file a.out format c > ovs_structs.h[1] I "only" had a single duplicated symbol error: uint64_t. Did not look further into this.
Maybe this can be a way to auto-generate the header... Thanks -- Adrián Moreno _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
