objdump issue on p.abs-->p.avg ; p.subRNr-->p.mac.zh.sh ; p.adduRNr" --> "p.mac.sh.sl

[yaronbe1]

following are compiling 3 issues we have encountered using objdump:

1. the following code: p.abs x4, x3 is turning to 80000082: 04018233 p.avg tp,gp,zero

2. p.subrnr into p.mac.zh.sh Original code:

             c.addi a5, -22
             p.subrnr a3, sp, gp
             and s0, a0, a0

Disassembled code:

8000014a: 17a9 addi a5,a5,-22 8000014c: 403176db p.mac.zh.sh a3,sp,gp,zero 80000150: 00a57433 and s0,a0,a0

3. Instruction "p.adduRNr" Somehow become "p.mac.sh.sl"

Original code: xori a4, s4, -576 p.addurnr a2, t6, t6 p.subun t0, tp, a7, 17

[sermazz]

Can reproduce!

It seems that from Xpulpv2 on (i.e. Xpulpv2, Xgap8, Xpulpv3, Xpulpnn, Xgap9) p.avg opcode has been assigned to p.abs instead, but the macro MATCH_AVG in pulp-riscv-binutils-gdb/include/opcode/riscv-opc.h kept the same name (maybe to still support Xpulpv0 and Xpulpv) and was assigned to p.abs too in the file pulp-riscv-binutils-gdb/opcodes/riscv-opc.c.

With this opcode 0x04000033 having two different semantics basing on the Xpulp version, the assembler uses the first match, which is why p.abs might be disassembled as p.avg.

[bluewww]

Sometimes you have to tell objdump to use a certain architecture because the instruction encoding space of some pulp extension version are overlapping as sermazz said. You can do this with the -march flag. Ideally we would look at the riscv-attributes section and automatically set the correct architecture, but that would require quite a bit of hacking around on the libopcodes codebase.

[sermazz]

Thanks for the suggestion. Just a remark: objdump does not have a specific -march flag to specify the RISC-V architecture; this can be done instead by passing such additional information to objdump with the flag --disassembler-option=, parsed directly by the RISC-V disassembler libraries.

E.g. with --disassembler-option="march=rv32gXpulpv2" the binary of p.abs gets correctly disassembled for me.

[bluewww]

I should have been more precise, the argument can be shortened to `-Mmarch=rv32gxpulpv2".

Also it also not possible for objdump to conveniently decide what kind of extensions are enabled. In later gcc releases a riscv attribute was added to the elf allowing the gnu tools to infer the march flag.