Hi Thomas,
thanks for reviewing.
> Could you please move ucontext_get_lr() to the Aix resp Linux namespaces, like the other ucontext_xxx functions, or at least make them static file scope ?
This could be done on AIX, but I don’t see how it could be done on Linux without touching shared linux code. I don’t want to change non-ppc/s390 files because the PC retrieval is specific to these platforms.
The new functions are already static file scope. Or did you mean something else?
Best regards,
Martin
From: Thomas Stüfe [mailto:thomas.stuefe at gmail.com]
Sent: Dienstag, 30. Januar 2018 15:42
To: Doerr, Martin <martin.doerr at sap.com>
Cc: hotspot-compiler-dev at openjdk.java.net; Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; Schmidt, Lutz <lutz.schmidt at sap.com>
Subject: Re: RFR(S): 8196401: PPC64+s390: get_frame_at_stack_banging_point uses wrong PC
Hi Martin,
Could you please move ucontext_get_lr() to the Aix resp Linux namespaces, like the other ucontext_xxx functions, or at least make them static file scope ?
Otherwise, this looks good.
Regards, Thomas
On Tue, Jan 30, 2018 at 2:47 PM, Doerr, Martin <martin.doerr at sap.com<mailto:martin.doerr at sap.com>> wrote:
Hi,
we have found a bug in get_frame_at_stack_banging_point on PPC64 and s390 by reading code.
C1 and C2 JIT compilers generate stack banging code before the code for saving the PC on PPC64 and s390.
Hence, the PC needs to be picked from the signal context (LR on PPC64 and R14 on s390) to create a correct frame object.
Currently, the top frame can not be checked for reserved stack annotation because the frame doesn't get a PC which points into the nmethod.
Proposed fix:
http://cr.openjdk.java.net/~mdoerr/8196401_ppc64_s390_stack_bang_pc/webrev.00/
Please review.
Best regards,
Martin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20180130/a7b33ee8/attachment-0001.html>