[PATCH 1/2] RISC-V: Fix abort when displaying .dword

[Maciej W. Rozycki]

On Wed, 12 Feb 2025, Jan Beulich wrote:

> >> While this follows what's done in the 3-byte case, I don't consider this
> >> (or the 3-byte logic) correct. When I see .dword, I expect what's printed
> >> covers full 8 bytes. Imo fake .<N>byte directives (which the assembler
> >> doesn't recognize for non-power-of-2 N) would be more logical to use.
> > 
> > Well if I see .word, I also expect to print the full 4 bytes, so probably
> > just remove the case 3, and then make sure that we only have 1/2/4/8 for
> > data, which means .byte/.short/.word/.dword.
> 
> Except that there is no 4th byte to print in that case. That wants expressing
> somehow, without taking a value out of thin air.

 They could just do what backends for other fixed-length-instruction-word 
targets do, such as Alpha or MIPS one:

$ dd if=/dev/zero of=partial-insn.img bs=1 count=7
$ alpha-linux-gnu-objdump -b binary -m alpha -D partial-insn.img

partial-insn.img:     file format binary


Disassembly of section .data:

0000000000000000 <.data>:
   0:	00 00 00 00 	halt
   4:	Address 0x0000000000000004 is out of bounds.

$ mips-linux-gnu-objdump -b binary -m mips -D partial-insn.img

partial-insn.img:     file format binary


Disassembly of section .data:

00000000 <.data>:
   0:	00000000 	nop
   4:	Address 0x4 is out of bounds.

$ 

There are other means available, such as the `-s' option or `readelf', for 
dumping trailing partial data that is not a complete instruction and thus 
has no meaning.  I'm not sure if this is a corner case worth putting much 
effort into, beyond just making sure the tools don't crash or produce 
utter rubbish.

 FWIW,

  Maciej