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? 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. <SNIP> _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
