RFR(xs): 8147510: [windows] no text locations shown for register info in hs-err file
David Holmes
david.holmes at oracle.com
Thu Jan 28 04:19:17 UTC 2016
Hi Thomas,
On 27/01/2016 6:11 PM, Thomas Stüfe wrote:
> Hi David,
>
> thank you for the review! Answer inline.
>
> On Wed, Jan 27, 2016 at 6:44 AM, David Holmes <david.holmes at oracle.com
> <mailto:david.holmes at oracle.com>> wrote:
>
> Hi Thomas,
>
> On 20/01/2016 5:53 PM, Thomas Stüfe wrote:
>
> May I please have a review and a sponsor?
>
> Thank you!
>
> On Sat, Jan 16, 2016 at 10:42 AM, Thomas Stüfe
> <thomas.stuefe at gmail.com <mailto:thomas.stuefe at gmail.com>>
> wrote:
>
> Hi,
>
> could I please have reviews and a sponsor for this small fix:
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8147510
> Webrev:
> http://cr.openjdk.java.net/~stuefe/webrevs/8147510-windows-register-info-print-location/webrev.00/
>
> When we print register to memory info in hs-err file, text
> addresses are
> not resolved on windows like on other platforms:
>
> "RCX=0x000000005efa0000 is an unknown value"
>
> This fix changes this (the same way it is implemented on
> other platforms):
>
>
> In the sense that something is better than nothing this seems okay,
> but I have to wonder why the other OS do what they do in os::find
> and don't call os::dll_address_to_library_name? I'm not an expert on
> dll querying on any platform.
>
>
> You are totally right. There is a lot of code duplication. My guess is
> that os::find was originally used as a debugging aid (called from within
> the debugger, if that is supported).
>
> I wanted to have a basic fix first and then do a real cleanup later,
> therefore I opened https://bugs.openjdk.java.net/browse/JDK-8147512. I
> thought that way it is easier to get reviews.
Okay. We will need a second review for this, but I'm happy to sponsor it
for you.
Thanks,
David
> Thanks, Thomas
>
>
> Thanks,
> David
> -----
>
>
>
> "RCX=C:\d031900\openjdk\jdk9-hs-rt\output\images\jdk\bin\server\jvm.dll
> +
> 0"
>
> Please note that this printout and the code behind it could
> be improved
> and cleaned up a lot. For instance, I know that using an
> on-stack buffer in
> os::find() is not the best implementation here. But I wanted
> a minimal
> change. For the follow-up work, I opened a new bug:
> https://bugs.openjdk.java.net/browse/JDK-8147512.
>
> Thanks & Regards, Thomas
>
>
>
>
>
More information about the hotspot-runtime-dev
mailing list