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

[Richard Reingruber]

On Thu, 24 Oct 2024 12:57:23 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:
> 
>   Use uc_mcontext.fpregs instead of __fpregs_mem._xmm and fix copied uc_mcontext in store_context.

> Also note that the copy fix above is kind of a hack. Should we use something like the following?
> 
> ```diff
> diff --git a/src/hotspot/share/utilities/debug.cpp b/src/hotspot/share/utilities/debug.cpp
> index 988e5dddd90..1389654b4b6 100644
> --- a/src/hotspot/share/utilities/debug.cpp
> +++ b/src/hotspot/share/utilities/debug.cpp
> @@ -731,7 +731,9 @@ static void store_context(const void* context) {
>  #if defined(PPC64)
>    *((void**) &g_stored_assertion_context.uc_mcontext.regs) = &(g_stored_assertion_context.uc_mcontext.gp_regs);
>  #elif defined(AMD64)
> -  *((void**) &g_stored_assertion_context.uc_mcontext.fpregs) = &(g_stored_assertion_context.uc_mcontext.fpregs);
> +  // In the copied version, fpregs should point to the copied contents. Preserve the offset.
> +  intptr_t offset = (address)(void*)(g_stored_assertion_context.uc_mcontext.fpregs) - (address)context;
> +  *((void**) &g_stored_assertion_context.uc_mcontext.fpregs) = (void*)((address)(void*)&g_stored_assertion_context + offset);
>  #endif
>  #endif
>  }
> ```

Looks like what I ment in [my comment above](https://github.com/openjdk/jdk/pull/21615#issuecomment-2434816007). I was wondering why you ignored it.

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

PR Comment: https://git.openjdk.org/jdk/pull/21615#issuecomment-2435356708