Re: [PATCH 0/9] eBPF support for GNU binutils

[Jiong Wang <jiong.wang@netronome.com>]

> 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 :)