This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: [PATCH 0/9] eBPF support for GNU binutils
- From: jose dot marchesi at oracle dot com (Jose E. Marchesi)
- To: Jiong Wang <jiong dot wang at netronome dot com>
- Cc: binutils at sourceware dot org, Alexei Starovoitov <alexei dot starovoitov at gmail dot com>, Daniel Borkmann <daniel at iogearbox dot net>, bpf at vger dot kernel dot org
- Date: Tue, 21 May 2019 19:06:21 +0200
- Subject: Re: [PATCH 0/9] eBPF support for GNU binutils
- References: <1B2BE52B-527E-436E-AE49-29FA9E044FD3@netronome.com>
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 :)