RFR: 8368787: Error reporting: hs_err files should show instructions when referencing code in nmethods

[Martin Doerr]

On Mon, 6 Oct 2025 13:18:01 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> I think hex dump is most bullet-proof, as we can always disassemble offline it at different offsets.

Right. The disassembler produces garbage if it starts disassembling somewhere besides the correct instruction start (on x86).
If that happens, we can play with the offset in the hex dump until the sequence looks feasible.
So, I think printing some hex dump around the address is always a good thing.

> I don't think we want to specialize for reloc types, it does not gain us much? Also, relocs solve the variable-sized encoding only if you are lucky to hit the reloc right at the location you are decoding, right? Anything in between relocs is still pretty foggy. I suspect current patch would work in 99% of the cases, as it is hard to imagine e.g. the value in the register that points into nmethod and does not have some sort of reloc.

Yeah, nmethods don't contain a lot of data which is something else than valid instructions. So, most of the time, disassembly works as proposed here, but we may still produce garbage in rare cases. That's not a big problem if we have the hex dump.

> Then I also suspect that disassemblers actually able to figure the instruction boundaries pretty well? Because I don't quite see how our usual printout of decode(pc - 64, pc + 64) would otherwise work: pc-64 starts at arbitrary boundary. You might want to check if this whole reloc thing is even needed. What happens if we just do Disassembler::decode(MAX2(nm->entry_point(), addr - 64), MIN2(nm->code_end(), addr + 64))?

`decode(pc - 64, pc + 64)` works fine on platforms like aarch64 and PPC64. I hope we don't have such code for x86. I got complete garbage when trying a wrong offset on x86.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27530#issuecomment-3374109251