RFR: 8342607: Enhance register printing on x86_64 platforms

[Julian Waters]

On Tue, 22 Oct 2024 01:35:20 GMT, Julian Waters <jwaters 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, 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
>
> src/hotspot/os_cpu/windows_x86/os_windows_x86.cpp line 444:
> 
>> 442:   st->cr();
>> 443:   for (int i = 0; i < 16; ++i) {
>> 444:     const uint64_t *xmm = ((const uint64_t*)&(uc->Xmm0)) + 2 * i;
> 
> Using a more specific cast is generally better, in this case since it's a pointer to pointer, reinterpret_cast might suffice. And if that is used, the const is not required (I think)

Actually, scratch that. The const is probably needed even with reinterpret_cast. I got it mixed up with something else

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21615#discussion_r1809733463