RFR: 8343031: StopInterpreterAt not work on linux-x86_64
SendaoYan
syan at openjdk.org
Mon Nov 18 08:52:00 UTC 2024
On Mon, 18 Nov 2024 05:32:47 GMT, Julian Waters <jwaters at openjdk.org> wrote:
> I had to do some code archaeology here ...
>
> The x86 `int3` has always called `os::breakpoint` and `os::breakpoint` has always been just a call to an empty function so you can set a breakpoint in there when debugging with gdb. So `StopInterpreterAt` has never, ever worked the way you now want on x86. And `StopIntepreterAt` has been around forever too and so it seems to me that the way it is (or was) expected to be used is that you start the debugger, set a breakpoint in the `breakpoint()` function, then run your application with `-XX:StopInterpreterAt=N` and when the interpreter gets to that BCI you hit the breakpoint in the debugger.
>
> From what I can see the Aarch64 porters may not have examined this in depth and starting from the x86 code they replaced the `int3` (which I agree certainly looks like it will trigger the software trap) with the Aarch64 `brk` "equivalent". Hence it works quite differently to x86.
>
> Now I don't know how many people ever use `StopInterpreterAt` (I never have) but to change the way it works really needs some general community buy-in. At the moment I think it is working as designed.
Thanks for your detail explanation. I think you are right, I just found a [documentation](https://www.progdoc.de/papers/JavaOne2014/javaone2014_con3138.html) has shows the usage of `StopIntepreterAt` as you descript.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/21701#issuecomment-2482304680
More information about the hotspot-runtime-dev
mailing list