> You're welcome, don't hesitate to ask if you think of something that could be useful, we are here to help :)
Thanks a lot! My current wish list if anyone has cycles to work on this would be (Cc @yonghong-song / @dafaust for additional input):
Pick a choice (LLVM BPF asm syntax vs gcc BPF asm syntax) to compare llvm/gcc compilation result with same disassembler
BTF viewer (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/bpf/btf.rst)
Perhaps this could be added to "+ Add new" menu as an output option.
Both gcc and clang support generating BTF, this can be dumped and introspected.
In the below pahole converts it from DWARF which is also very useful (see also BTF Generation from above link):
$ cat t.c
struct t {
int a:2;
int b:3;
int c:2;
} g;
$ gcc -c -O2 -g t.c
$ pahole -JV t.o
File t.o:
[1] STRUCT t kind_flag=1 size=4 vlen=3
a type_id=2 bitfield_size=2 bits_offset=0
b type_id=2 bitfield_size=3 bits_offset=2
c type_id=2 bitfield_size=2 bits_offset=5
[2] INT int size=4 bit_offset=0 nr_bits=32 encoding=SIGNED
(For pahole, also latest trunk would be recommended.)
This would help to compare generated BTF from both compilers.
Originally posted by @borkmann in https://github.com/compiler-explorer/compiler-explorer/issues/4408#issuecomment-1375448644
Sounds really interesting! I would need to read a bit more about BTF before really doing anything on that front.
IIUC, there are 2 asm dialects and GCC and LLVM don't use the same? To compare, you would need to objdump binary products with the same tool (llvm-objdump or binutils's objdump): hence the need to choose one.
Please note you already have pahole avail: https://c.godbolt.org/z/hP9Wb3zKd
Sounds really interesting! I would need to read a bit more about BTF before really doing anything on that front.
IIUC, there are 2 asm dialects and GCC and LLVM don't use the same? To compare, you would need to
objdumpbinary products with the same tool (llvm-objdumpor binutils'sobjdump): hence the need to choose one.
Yes, they don't use the same unfortunately, and yes you'd need to be able to pick the objdump flavor.
For example, if LLVM devs want to compare clang vs gcc compilation result, they would want the compilation result of both with llvm-objdump. Similarly, if gcc devs want to compare gcc vs clang compilation result, they'll use binutils's objdump.
From user PoV, this looks a bit similar pick as you have in "Output -> Intel asm syntax". Perhaps it's possible when "BPF clang *" is selected to have a "Output -> gcc BPF asm syntax" option, and vice versa when "BPF gcc *" is selected to have a "Output -> clang BPF asm syntax" option.
For the binutils selection, that looks like an interesting idea, not only for BPF, but everywhere we use binutils. Alas, it's not so similar to intel syntax implementation wise. For the intel syntax, it's usually an option for the compiler, whereas in this case, it's a matter of picking the objdumper based on the user input. Our code is not ready for that (but the foundations are here as we can already hardcode which objdump to use, so maybe "it's only a matter a UI"?).
For the BTF, I'm not really sure I understand what is the "canonical" way to get it. The documentation hints at 2 methods:
.BTF and .BTF.ext sections (only valid for LLVM IIUC)pahole to reconstruct the type information from the dwarf data.Having a new pane to show the output of a carefully crafted call to pahole can be done rather easily. I'm not sure we want a dedicated pane to only show a subset of the assembly output... You can already disable the Directives filter that is enabled by default.
GCC also generates btf in .BTF. It works for any target. Note that .BTF.ext is for CO-RE, not BTF proper.
As for dumping BTF, you could use GNU poke (https://jemarch.net/poke) instead of objdump for your pane:
$ cat dump-btf
#!/usr/local/bin/poke -L
!#
load elf;
load "btf-dump.pk";
var file = open (argv[0]);
var elf = Elf64_File @ file : 0#B;
var sec = elf.get_sections_by_name (".BTF")[0];
btf_dump (BTF_Section @ file : sec.sh_offset);
Then:
$ echo 'int foo () { return 0; }' | bpf-unkonwn-none-gcc -gbtf -o foo.o -xc -
$ ./dump-btf foo.o
[1] int 'int'(0x00000001U#B) size=0x00000004U#B offset=0x00UB#b bits=0x20UB#b SIGNED
[2] func_proto <anonymous> type=1
[3] func 'foo'(0x00000005U#B) type=2 linkage=1 (global)
Small headsup, linking with clang is still disabled, but you can use our new "compile to binary object" to have clang's output objdumped by llvm-objdump: https://godbolt.org/z/xWxMKd4T3
Currently, we have bpftool to dump bpf asm codes and btf as well. The dumped bpf asm code very similar to llvm-objdump disassembly code. The dumped btf is very similar to pahole -JV output. Also verifier log is also following the clang asm syntax. So consider most bpf users probably interact with bpftool and kernel verifier. It would be really nice for compiler explorer to emit kernel-style bpf asm and btf types by default, so it can be easily compared against kernel/bpftool output.
