On 1/25/22 12:32 PM, Vincent Li wrote:
On Tue, Jan 25, 2022 at 9:52 AM Vincent Li <vincent.mc.li@xxxxxxxxx> wrote:
this is macro I suspected in my implementation that could cause issue with BTF
#define ENABLE_VTEP 1
#define VTEP_ENDPOINT (__u32[]){0xec48a90a, 0xee48a90a, 0x1f48a90a,
0x2048a90a, }
#define VTEP_MAC (__u64[]){0x562e984c3682, 0x582e984c3682,
0x5eaaed93fdf2, 0x5faaed93fdf2, }
#define VTEP_NUMS 4
On Tue, Jan 25, 2022 at 9:38 AM Vincent Li <vincent.mc.li@xxxxxxxxx> wrote:
Hi
While developing Cilium VTEP integration feature
https://github.com/cilium/cilium/pull/17370, I found a strange issue
that seems related to BTF and probably caused by my specific
implementation, the issue is described in
https://github.com/cilium/cilium/issues/18616, I don't know much about
BTF and not sure if my implementation is seriously flawed or just some
implementation bug or maybe not compatible with BTF. Strangely, the
issue appears related to number of VTEPs I use, no problem with 1 or 2
VTEP, 3, 4 VTEPs will have problem with BTF, any guidance from BTF
experts are appreciated :-).
Thanks
Vincent
Sorry for previous top post
it looks the compiler compiles the cilium bpf_lxc.c to bpf_lxc.o
differently and added " [21] .rodata.cst32 PROGBITS
0000000000000000 00011e68" when following macro exceeded 2 members
#define VTEP_ENDPOINT (__u32[]){0xec48a90a, 0xee48a90a, 0x1f48a90a,
0x2048a90a, }
no ".rodata.cst32" compiled in bpf_lxc.o when above VTEP_ENDPOINT
member <=2. any reason why compiler would do that?
Regarding to why compiler generates .rodata.cst32, the reason is
you have some 32-byte constants which needs to be saved somewhere.
For example,
$ cat t.c
struct t {
long c[2];
int d[4];
};
struct t g;
int test()
{
struct t tmp = {.c = {1, 2}, .d = {3, 4}};
g = tmp;
return 0;
}
$ clang -target bpf -O2 -c t.c
$ llvm-readelf -S t.o
...
[ 4] .rodata.cst32 PROGBITS 0000000000000000 0000a8 000020
20 AM 0 0 8
...
In the above code, if you change the struct size, say from 32 bytes to
40 bytes, the rodata.cst32 will go away.
