[BPF] `bpf_insn` collides with `libbpf` definition. about capstone HOT 13 CLOSED

Please close the issue if the macro work around works for you.

from capstone.

The installed version of libbpf is (I think) v1.3...the GitHub repo for libbpf still has the struct bpf_insn; but at line 334

https://github.com/libbpf/libbpf/blob/6d3595d215b014d3eddb88038d686e1c20781534/src/libbpf.h#L334

from capstone.

@Rot127 sorry to tag you direct, just wondering if you had any thoughts on this?

from capstone.

There seems to be something off with the includes. Can you try to cherry-prick this commit: Rot127@7d746b5

from capstone.

Also possibly related: #2307

from capstone.

Just saw you use make. Please use cmake. The Makefile method is considered deprecated. Also, please share a minimal example for me to test.

from capstone.

@grahamwoodward
Regarding #2307 (comment), yes, please try Rot127@7d746b5. But it likely doesn't work.

Your problem comes likely from including headers in an order which creates the conflict.

If you have one file where the CS header and the libbpf header are included in the same file (or indirectly through other headers), you would need to change this.

Please write the result in this issue, not the PR.

Regarding #2307 (comment)

This is not an option for us, unfortunately. You can do it of course locally, but we can not change the name that easily.

from capstone.

hmm so how do we fix it? The perf tool I'm working on might be made public with a dependency on Capstone and BPF so this will need fixing somehow

from capstone.

Also

Regarding #2307 (comment)

This is not an option for us, unfortunately. You can do it of course locally, but we can not change the name that easily.

why can't this be done? Because of people using Capstone would need to update their code to accommodate the enum name change?

from capstone.

why can't this be done? Because of people using Capstone would need to update their code to accommodate the enum name change?

Yes, we would need to change the names for all the archs in the API. So we are consistent with naming. This in turn would force everyone to fix their code with the new names. And Capstone tries to be as stable as possible between versions.

hmm so how do we fix it?

As far as I can see, you will need to do something like this. So you can add the cs_ prefix with the macro when you need it.

from capstone.

why can't this be done? Because of people using Capstone would need to update their code to accommodate the enum name change?

Yes, we would need to change the names for all the archs in the API. So we are consistent with naming. This in turn would force everyone to fix their code with the new names. And Capstone tries to be as stable as possible between versions.

It's only the "bpf arch" that needs the change, i.e in include/capstone/bpf.h

hmm so how do we fix it?

As far as I can see, you will need to do something like this. So you can add the cs_ prefix with the macro when you need it.

I'm not convinced this works...but going to play with it to see whether I can use this trick

from capstone.

I'm not convinced this works...but going to play with it to see whether I can use this trick

hhmm this might be working actually...

+   8 #include <capstone/capstone.h>
+   9 #define bpf_insn cs_bpf_insn
+  10   #include <linux/bpf.h>
+  11   #include <bpf/libbpf.h>
+  12 #undef cs_bpf_insn
   13

from capstone.

Closing as no fix planned. Workaround available as per #2316 (comment)

from capstone.