On 4/11/21 9:47 PM, Sedat Dilek wrote:
On Sun, Apr 11, 2021 at 9:08 PM Yonghong Song <yhs@xxxxxx> wrote:
[ ... ]
BTW, did you check (llvm-)objdump output?
$ /opt/llvm-toolchain/bin/llvm-objdump-12 -Dr test_cpp | grep core_extern
This is what I got with g++ compiled test_cpp:
$ llvm-objdump -Dr test_cpp | grep core_extern
406a80: e8 5b 01 00 00 callq 0x406be0
<_ZL25test_core_extern__destroyP16test_core_extern>
406ab9: e8 22 01 00 00 callq 0x406be0
<_ZL25test_core_extern__destroyP16test_core_extern>
0000000000406be0 <_ZL25test_core_extern__destroyP16test_core_extern>:
406be3: 74 1a je 0x406bff
<_ZL25test_core_extern__destroyP16test_core_extern+0x1f>
406bef: 74 05 je 0x406bf6
<_ZL25test_core_extern__destroyP16test_core_extern+0x16>
What is the output when compiling with clang++ in your bpf-next environment?
$ llvm-objdump -Dr test_cpp | grep core_extern
$
So looks like all test_core_extern_*() functions are inlined.
This can be confirmed by looking at assembly code.
while for gcc, there is still the call to
_ZL25test_core_extern__destroyP16test_core_extern
which is
test_core_extern__destroy(test_core_extern*)
This is just a difference between compiler optimizations
between gcc and clang. We don't need to worry about this.
- Sedat -
