RFR(S): 8247732: validate user-input intrinsic_ids in ControlIntrinsic
xxinliu at amazon.com
Thu Jul 23 16:02:42 UTC 2020
That is my intention too, but CompilerOracle doesn't exit JVM when it encounters parsing errors.
It just exacts information from CompileCommand as many as possible. That makes sense because compiler "directives" are supposed to be optional for program execution.
I do put the error message in parser's errorbuf. I set a flag "exit_on_error" to quit JVM after it dumps parser errors. yes, I treat undefined intrinsics as fatal errors.
This behavior is from Nils comment: "I want to see an error on startup if the user has specified unknown intrinsic names." It is also consistent with JVM option -XX:ControlIntrinsic=.
From: Tobias Hartmann <tobias.hartmann at oracle.com>
Sent: Thursday, July 23, 2020 2:13 AM
To: Liu, Xin; Nils Eliasson; hotspot-compiler-dev at openjdk.java.net; hotspot-runtime-dev
Subject: RE: [EXTERNAL] RFR(S): 8247732: validate user-input intrinsic_ids in ControlIntrinsic
CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.
On 22.07.20 09:12, Liu, Xin wrote:
> 1. I move the validation logic for compiler directives to compilerOracle::scan_flag_and_value.
> If something wrong happens in parser, the patch will "gracefully" quit JVM using jvm_exit(1). is that okay?
With "piggy-back on the error mechanism" I meant that you should use the existing bailout mechanism
in the parser. In this case, couldn't you simply put the error message in 'errorbuf' and let the
caller take care of handling it?
More information about the hotspot-runtime-dev