RFR: 8343031: StopInterpreterAt not work on linux-x86_64

[David Holmes]

On Fri, 25 Oct 2024 03:54:45 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> The VM option `-XX:StopInterpreterAt=1` doesn't work on linux-x86_64 before this PR. `MacroAssembler::int3` call `os::breakpoint()`, but the `os::breakpoint()` [implementation](https://github.com/openjdk/jdk/blob/master/src/hotspot/os/posix/os_posix.cpp#L284) is empty.
> In this PR, I replace call `os::breakpoint()` as emit int3 assemble code directly. Only affect `-XX:StopInterpreterAt` with debug build, risk is low.
> 
> Additional testing:
> 
> - [x] linux x64 build with release/fastdebug/slowdebug configure
> - [x] linux x64 jtreg tests(include tier1/2/3 etc.) with release build
> - [x] linux x64 jtreg tests(include tier1/2/3 etc.) with fastdebug build

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.

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

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