libbpf-cargo: Handle duplicated types in BTF more gracefully #1074
Conversation
Our SkeletonBuilder currently only support building a skeleton from a single .bpf.c file. However, users may very well compile multiple .bpf.c files into .bpf.o and link them into a single object. In such a scenario, it is easily possible that we end up with multiple types of the same name in the corresponding BTF. Currently, this results in compilation errors. With this change we handle this case more gracefully, by enumerating these types, similar to what libbpf does in its dumping logic. Signed-off-by: Daniel Müller <deso@posteo.net>
dbc1f06 to
b4716c2
Compare
libbpf-cargo/src/test.rs
Outdated
| let _foobar0 = types::foobar::default(); | ||
| let _foobar1 = types::foobar_1::default(); |
There was a problem hiding this comment.
actually, wouldn't foobar_2 make more sense (it's a second instance of the same name, we just don't explicitly mark the first one with _1)?
There was a problem hiding this comment.
I am living happily in my counting-starts-at-zero bubble :-)
But happy to change it.
Btw., strictly speaking I think the renaming algorithm is insufficient: we can't just assume that <type>_<cnt> is an available name, but should actually check that there is no collision with an existing type of that name.
There was a problem hiding this comment.
heh, I see :) I'd switch to two, but ultimately it doesn't matter all that much. If user gets to that point, there is no deterministic order, so whether it's foobar_1 or foobar_2, I wouldn't use any of those in the code directly because their ordering can change on the next compilation
and yeah, you are right about possibility of causing another unintended collision (which, on libbpf side, is mostly mitigated by using triple underscore, which makes it highly unlikely)
0adf48c to
ba14598
Compare
Now that our AnonTypes type performs more tasks than just assigning names to anonymous types, let's rename it to TypeMap to reflect it intent more clearly. Signed-off-by: Daniel Müller <deso@posteo.net>
ba14598 to
37f7b28
Compare
|
@etsal this should fix your compilation error. |
Our
SkeletonBuildercurrently only support building a skeleton from a single.bpf.cfile. However, users may very well compile multiple.bpf.cfiles into.bpf.oand link them into a single object. In such a scenario, it is easily possible that we end up with multiple types of the same name in the corresponding BTF. Currently, this results in compilation errors.With this change we handle this case more gracefully, by enumerating these types, similar to what libbpf does in its dumping logic.