On 7/26/23 2:16 AM, Jose E. Marchesi wrote:
I see this in the verifier (bpf-next):
if (opcode == BPF_NEG) {
if (BPF_SRC(insn->code) != BPF_K ||
insn->src_reg != BPF_REG_0 ||
insn->off != 0 || insn->imm != 0) {
verbose(env, "BPF_NEG uses reserved fields\n");
return -EINVAL;
}
And along this llvm assembler test:
|
v
// CHECK: 84 01 00 00 00 00 00 00 w1 = -w1
w1 = -w1
Is enough evidence that NEG is supposed to use only dst and not src. I
Yes, in llvm (BPFInstrInfo.td),
class NEG_RR<BPFOpClass Class, BPFArithOp Opc,
dag outs, dag ins, string asmstr, list<dag> pattern>
: TYPE_ALU_JMP<Opc.Value, 0, outs, ins, asmstr, pattern> {
bits<4> dst;
let Inst{51-48} = dst;
let BPFClass = Class;
}
You can see only dst register is used. The further evidence
is from the above kernel check.
am sending a fix for standarization/instruction-set.rst.
Hello.
The neg (and neg32) instructions are documented to use (and encode) both
src and dst register operands in standarization/instruction-set.rst:
BPF_NEG 0x80 dst = -src
However, in llvm's BPFAsmParser::PreMatchCheck, it is checked that both
source and destination registers refer to the same register. If they
are not, an error is raised.
Is this to speed up JIT to different architectures, some like x86
featuring `NEG reg' and others like aarch64 featuring `NEG reg1,reg2'?
Should I send a patch for instruction-set.rst documenting the
requirement?
Thanks.
