When following up on JVM crashes in the field, we frequently want to disassemble the "Instructions:" block in hs_err. Unfortunately, some architectures print out the instructions in 4-byte chunks, which is affected by platform endianness. The simple scripts would then fail to parse the instruction stream, because they have no assumptions about the endianness.

For example, here is an attempt to decode a piece of AArch64 "Instructions:" block:

```
% cat asm.txt; xxd -r asm.txt > asm.bin; hexdump -C asm.bin; objdump -D -m aarch64 -b binary asm.bin
924cfce4g 382268bf 12800000 f9400881 8b020422
924cfcf4g 39000440 17ffffaa 52800002 528000a1


00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
924cfce0 00 00 00 00 38 22 68 bf 12 80 00 00 f9 40 08 81 |....8"h......@..|
924cfcf0 8b 02 04 22 39 00 04 40 17 ff ff aa 52 80 00 02 |..."9..@....R...|
924cfd00 52 80 00 a1 |R...|
924cfd04

asm.bin: file format binary


Disassembly of section .data:

0000000000000000 <.data>:
...
    924cfce4: bf682238 .inst 0xbf682238 ; undefined
    924cfce8: 00008012 .inst 0x00008012 ; undefined
    924cfcec: 810840f9 .inst 0x810840f9 ; undefined
    924cfcf0: 2204028b .inst 0x2204028b ; undefined
    924cfcf4: 40040039 .inst 0x40040039 ; undefined
    924cfcf8: aaffff17 orn x23, x24, xzr, ror #63
    924cfcfc: 02008052 .inst 0x02008052 ; undefined
    924cfd00: a1008052 .inst 0xa1008052 ; undefined
```

Note how `382268bf` is written out in the original dump, and that value is big-endian for AArch64. But `xxd` then treats this as just a sequence of bytes, which effectively writes it down to binary file as little-endian, and then the decoding breaks.

Of course, one can convert the endianness, assuming there are 4-byte blocks in instruction stream for AArch64, and then the decoding would work:

```
$ hexdump -v -e '1/4 "%08x"' -e '"\n"' asm.bin | xxd -r -p > asm.reversed.bin
$ objdump -D -m aarch64 -b binary asm.reversed.bin

asm.reversed.bin: file format binary


Disassembly of section .data:

0000000000000000 <.data>:
...
    924cfce4: 382268bf strb wzr, [x5, x2]
    924cfce8: 12800000 mov w0, #0xffffffff // #-1
    924cfcec: f9400881 ldr x1, [x4, #16]
    924cfcf0: 8b020422 add x2, x1, x2, lsl #1
    924cfcf4: 39000440 strb w0, [x2, #1]
    924cfcf8: 17ffffaa b 0x924cfba0
    924cfcfc: 52800002 mov w2, #0x0 // #0
    924cfd00: 528000a1 mov w1, #0x5 // #5
```

...but that is rather cumbersome.

It would be easier to dump the "Instructions:" block in byte unit, so that endianness does not even enter the picture here, and the hex dump would just follow the natural order of bytes in the dump.

x86 already does the byte-unit dump, since it has a variable-size encoding. The ease of debugging would be improved for fixed-size encoding here too.