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.