Hi Jiong.
> Despite using a different syntax for the assembler (the llvm assembler
> uses a C-ish expression-based syntax while the GNU assembler opts for
> a more classic assembly-language syntax) this implementation tries to
> provide inter-operability with clang/llvm generated objects.
I also noticed your implementation doesn’t seem to use the same sub-register
syntax as what LLVM assembler is doing.
x register for 64-bit, and w register for 32-bit sub-register.
So:
add r0, r1, r2 means BPF_ALU64 | BPF_ADD | BFF_X
add w0, w1, w1 means BPF_ALU | BPF_ADD | BPF_X
ASAICT, different register prefix for different register width is also adopted
by quite a few other GNU assembler targets like AArch64, X86_64.
Right. I opted for using different mnemonics for alu and alu64
instructions, as it seemed to be simpler.
What was your rationale for using sub-register notation? Are you
planning to support instructions (or pseudo-instructions) mixing w and x
registers in the future?
> In particular, the numbers of the relocations used for instruction
> fields are the same. These are R_BPF_INSN_64 and R_BPF_INSN_DISP32.
> The later is resolved at load-time by bpf_load.c.
I think you missed the latest JMP32 instructions.
https://github.com/torvalds/linux/blob/master/Documentation/networking/filter.txt#L870
Oh thanks for spotting that.
Adding support for it :)
