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

[Aleksey Shipilev]

On Mon, 6 Oct 2025 09:30:40 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> Hotspot currently dumps code (hex or disassembled) when the nmethod is on stack of the crashing thread. That is completely missing when it's not on stack. [...] Should we print both, hex dump and disassembly?

Yes, I think if we know the location is within nmethod, it makes sense to dump around the location. 

I think hex dump is most bullet-proof, as we can always disassemble offline it at different offsets. 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.

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))`?

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

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