[PATCH 0/9] eBPF support for GNU binutils
Jiong Wang
jiong.wang@netronome.com
Tue May 21 18:14:00 GMT 2019
> On 21 May 2019, at 18:06, Jose E. Marchesi <jose.marchesi@oracle.com> wrote:
>
>
> 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?
It is the same instruction operating on different register classes, sub-register
is a new register class, so define separate notation for them. This also
simplifies compiler back-end when generating sub-register instructions, at
least for LLVM, and is likely for GCC as well.
LLVM eBPF backend has full support for generating sub-register ISA,
> 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 :)
More information about the Binutils
mailing list