RFR: 8342607: Enhance register printing on x86_64 platforms [v3]

Richard Reingruber rrich at openjdk.org
Fri Oct 25 10:22:12 UTC 2024


On Thu, 24 Oct 2024 16:54:38 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> There are some situations in which the XMM registers are relevant to understand errors. E.g. C2 compiler uses them to spill GPR values (see https://github.com/openjdk/jdk/blob/d6eddcdaf92f2352266ba519608879141997cd63/src/hotspot/cpu/x86/x86_64.ad#L1312), so they may contain Oops etc. We may consider searching and printing the content for Oops in a future RFE.
>> I've implemented [JDK-8342607](https://bugs.openjdk.org/browse/JDK-8342607) such that linux and Windows show the same output format. (Skipped Intel-Mac because Apple has stopped shipping that platform. I don't have it and I'm not familiar with it.)
>> 
>> Example output (linux):
>> 
>> Registers:
>> RAX=0x00007fea8bdb3000, RBX=0x00007fea8b48d5d4, RCX=0x00007fea8b4d2255, RDX=0x0000000000000340
>> RSP=0x00007fea897d0b60, RBP=0x00007fea897d0b90, RSI=0x00007fea8b5f1448, RDI=0x00000000e0000000
>> R8 =0x00007fea8b48d5d4, R9 =0x0000000000000006, R10=0x00007fea8bb4b500, R11=0x00007fea7cc2f120
>> R12=0x0000000000000000, R13=0x00007fea897d0bc0, R14=0x00007fea897d0c50, R15=0x00007fea8402c9c0
>> RIP=0x00007fea8ac008e5, EFLAGS=0x0000000000010246, CSGSFS=0x002b000000000033, ERR=0x0000000000000006
>>   TRAPNO=0x000000000000000e
>> 
>> XMM[0]=0x0000000000000000 0x0000000000000000
>> XMM[1]=0x00007fea3c034200 0x0000000000000000
>> XMM[2]=0x00000000fffffffe 0x00007fea8402c9c0
>> XMM[3]=0x00007fea7c3d6608 0x0000000000000000
>> XMM[4]=0x00007f0000000000 0x0000000000000000
>> XMM[5]=0x00007fea897d0fe8 0x00007feaffffffff
>> XMM[6]=0x0000000000000000 0x00007fea897d0f98
>> XMM[7]=0x0202020202020202 0x0000000000000000
>> XMM[8]=0x0000000000000000 0x0202020202020202
>> XMM[9]=0x666e69206e6f6974 0x0000000000000000
>> XMM[10]=0x0000000000000000 0x6e6f6974616d726f
>> XMM[11]=0x0000000000000001 0x0000000000000000
>> XMM[12]=0x00007fea8b684400 0x0000000000000001
>> XMM[13]=0x0000000000000000 0x0000000000000000
>> XMM[14]=0x0000000000000000 0x0000000000000000
>> XMM[15]=0x0000000000000000 0x0000000000000000
>>   MXCSR=0x0000037f
>
> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Preserve offset in copied uc_mcontext in store_context.

I've done a little bit of adhoc testing. Seems to work now. We could add a new test to test/hotspot/jtreg/runtime/ErrorHandling but on the other hand I don't think it is really necessary.
Cheers, Richard.

src/hotspot/os_cpu/linux_x86/os_linux_x86.cpp line 551:

> 549:   st->cr();
> 550:   st->cr();
> 551:   for (int i = 0; i < 16; ++i) {

Better check if `fpregs` points into `*uc` before dereferencing it (asserting that it actually does).

src/hotspot/share/utilities/debug.cpp line 735:

> 733: #elif defined(AMD64)
> 734:   // In the copied version, fpregs should point to the copied contents. Preserve the offset.
> 735:   intptr_t fpregs_offset = (address)(void*)(((const ucontext_t*)context)->uc_mcontext.fpregs) - (address)context;

Reads better and is safer:
Suggestion:

  size_t fpregs_offset = pointer_delta(((const ucontext_t*)context)->uc_mcontext.fpregs, context, 1);

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

PR Review: https://git.openjdk.org/jdk/pull/21615#pullrequestreview-2394826913
PR Review Comment: https://git.openjdk.org/jdk/pull/21615#discussion_r1816418234
PR Review Comment: https://git.openjdk.org/jdk/pull/21615#discussion_r1816399838


More information about the hotspot-runtime-dev mailing list