RFR (S) 8217879: hs_err should print more instructions in hex dump

[Thomas Stüfe]

On Tue, Jan 29, 2019 at 12:15 PM Aleksey Shipilev <shade at redhat.com> wrote:

> On 1/29/19 11:57 AM, Thomas Stüfe wrote:
> > On Tue, Jan 29, 2019 at 11:31 AM Aleksey Shipilev <shade at redhat.com
> <mailto:shade at redhat.com>> wrote:
> > I would bail out right away for bogus/unreadable pc since those may
> happen more often than not.
>
> I like the current code, because it exercises the "adjustment" part often,
> implicitly verifying it.
>
> > Is this exponential stepping really necessary? You run a risk of loosing
> information, e.g. for a pc
> > 250 bytes int a readable page preceeded with an unmapped one. This
> coding runs during error
> > reporting, so no big speed concerns I think.
>
> Yes, that would print "only" -128 bytes from that page; still much better
> than nothing.
>
> I did exponential stepping because delivering hundreds of signals via
> SafeFetch is probably not a
> good practice for both performance and debugging. I'd hate to "gdb cont" a
> hundred times :)
>
> The ideal way out would be to have os::print_hex_dump that is page-aware
> and that can probe once per
> page.


Or, start at the pc and work your way downward byte for byte (or word for
word since SafeFetch aligns to word size anyway), squirreling the bytes
away temporarily, until -256 or first fault. Then print those bytes. You
only have to do this on the first leg, on the second you work upward, the
same direction you print, so no need to temporarily store the bytes.

But the change is fine for me as it is.

..Thomas



But there is a bigger fish to fry, and this seems good for the overwhelming
> majority of cases,
> and universally safe.
>
> -Aleksey
>
>