RFR(S): 8211852: inspect stack during error reporting

[David Holmes]

Hi Martin,

On 8/10/2018 10:54 PM, Doerr, Martin wrote:
> Hi,
> 
> after making os::print_location more reliable, I'd like to use it to inspect the top of the stack, too (in a dedicated step).
> 
> We already inspect the registers during error reporting, but some important pointers may be only on stack, especially on architectures which don't have so many registers.
> Since hs_err files are often all we get after a crash, it is often valuable to spend a little space for more information about what's referenced on top of the stack.
> 
> I've uploaded my proposal here:
> http://cr.openjdk.java.net/~mdoerr/8211852_stack_info/webrev.00/
> 
> I had thought about using print_location in the platform specific code (print_context), but I think using a dedicated step is better. Especially if print_location doesn't work we'll still get the dump of the context which contains a piece of the stack as hex dump without any further inspection.
> 
> Please review.

src/hotspot/share/runtime/os.cpp

What is the actual output format of a line? I guessing it will look 
something like:

0x12345679 points into unknown readable memory: (byte 1 of) 0x12345678: 
   0xCAFEBABE

The "(byte 1 of)" looks a little odd to me. And it doesn't combine 
cleanly with the print_hex_dump output. Do we really need print_hex_dump 
just for dereferencing one address?

---

src/hotspot/share/utilities/vmError.cpp

Seems odd to have:

751   STEP("printing top of stack info")

then

769   STEP("printing registers, top of stack, instructions near pc")

as they both refer to "top of stack". Should they be merged (I know you 
touch on this above)? Should they be the other way round? Should they 
use different descriptions?

Any particular reason to show 8 slots? Or is it just a "Goldilocks number"?

Thanks,
David

> Best regards,
> Martin
>