RFR: 8343031: StopInterpreterAt not work on linux-x86_64

[Julian Waters]

On Mon, 18 Nov 2024 05:01:50 GMT, David Holmes <dholmes 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.

Off topic, but I think this is another LTO trap, if that's how it's meant to work. It will likely get inlined into oblivion across compilation unit boundaries and then the debugger will have nothing to break on when it gets to an intended breakpoint

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21701#issuecomment-2481992982