os::current_stack_pointer seems a little strange

[Julian Waters]

Hi all,

While looking through HotSpot I recently came across
os::current_stack_pointer, and the implementations seem a little odd.
On Windows x86, ARM64 and macOS Zero, it essentially returns the
address of the first local defined in itself, which should correspond
to the frame pointer of os::current_stack_pointer, which in turn
should equal the stack pointer of the caller, which is what we want to
get. Windows x64 instead delegates this task to runtime created
assembly from StubRoutines, Linux x86, PowerPC, ARM64, RISC-V, Zero as
well as AIX PowerPC all use __builtin_frame_address(0), Linux ARM32
loads the stack pointer using register address sp __asm__ ("sp");
which essentially loads the stack pointer into the sp local, and Linux
s390x and macOS x64 and ARM64 all use some form of handwritten
assembly to load the current stack pointer

(Someone please correct me if I'm wrong about what
os::current_stack_pointer  is trying to get, as in, the current stack
pointer)

My concern is that this seems to be a little easy to break. I cannot
comment on Windows x64, Linux s390x or macOS x64/ARM64 since I don't
really understand their implementations, but for Windows x86, ARM64
and macOS Zero, the obvious worry is when os::current_stack_pointer is
inlined or if a jmp instruction to os::current_stack_pointer is used
rather than a call as in tail recursion, which would result in an
address from anywhere between the frame pointer of the caller to the
stack pointer of the caller. The same issue would hold true for Linux
x86, PowerPC, ARM64, RISC-V, Zero as well as AIX PowerPC, albeit
instead of a range between the caller's frame and stack pointer it
would always return the frame pointer of the caller. On the flip side,
Linux ARM32 would only work if os::current_stack_pointer was inlined,
otherwise it would return the stack pointer of
os::current_stack_pointer instead. I see some definitions of
os::current_stack_pointer are marked with NOINLINE as appropriate, but
not all of them are. There are probably some more issues that I
haven't thought of with the current implementations, such as the
prologue of os::current_stack_pointer potentially also distorting the
returned address. Is this an issue worth looking into?

best regards,
Julian