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