RFD: Enhance crash log output when disassembler is not present

Vladimir Ivanov vladimir.x.ivanov at oracle.com
Tue Dec 10 03:56:50 UTC 2024


Personally, I like your proposal to make the output of abstract 
disassembler trivially parseable by existing platform tools.

In absense of hsdis library, it's already cryptic enough not to be 
negatively affected by extra formatting being proposed. And it would be 
very convenient to just feed a block into an assembler tool and get a 
readable assembly back.

Alternatively, an hsdis-based tool to parse existing output format can 
be introduced, but just relying on platform assembler looks like a 
simpler solution (both from usability and maintenance perspective).

Best regards,
Vladimir Ivanov

On 12/9/24 10:51, Andrew Haley wrote:
> Several times recently I have received a HotSpot error log from a user
> who did not have hsdis installed. Which, in practice, means most end users.
> The trouble it that the disassembly is unreadable.
> 
> The disassembly printed, when hsdis is not present, looks like this:
> 
> [MachCode]
> [Instructions begin]
>    ;; N526: #    out( B1 ) <- BLOCK HEAD IS JUNK  Freq: 1
>     0x00007f0c40564c20: 9090 448b | 5608 443b
> 
>     0x00007f0c40564c28: ;   {runtime_call Shared Runtime ic_miss_blob}
>     0x00007f0c40564c28: 5008 0f85 | b0d4 9aff
> [Verified Entry Point]
>    ;; B1: #    out( B34 B2 ) <- BLOCK HEAD IS JUNK  Freq: 1
>     0x00007f0c40564c30: 8984 2400 | 80fe ff55 | 4883 ec60 | 4181 7f20 | 
> 0100 0000 | 0f85 d806
> 
>     0x00007f0c40564c48: ;*synchronization entry
>                         ; - java.lang.StringBuilder::append at -1 (line 246)
>     0x00007f0c40564c48: 0000 8954 | 2410 488b | de4d 33c0 | 450f be00
> 
>     0x00007f0c40564c58: ;*getfield value {reexecute=0 rethrow=0 
> return_oop=0}
>                         ; - 
> java.lang.AbstractStringBuilder::ensureCapacityInternal at 1 (line 244)
>                         ; - java.lang.AbstractStringBuilder::append at 7 
> (line 804)
>                         ; - java.lang.StringBuilder::append at 2 (line 246)
>     0x00007f0c40564c58: 448b 4614
> 
>     0x00007f0c40564c5c: ; implicit exception: dispatches to 
> 0x00007f0c405651a8
>     0x00007f0c40564c5c: 478b 4cc4
> 
> I'd like to change it in the following ways:
> 
> - Replace the ";" with a platform-defined comment character
> - Replace the address with a comment
> - Replace the hex format with a line parseable by an assembler, in a 
> platform-defined format
> - A few other minor things
> 
> So we end up with something which is like this: not quite as nice, but 
> legal assembler
> syntax, retaining all comments:
> 
> # [MachCode]
> # [Instructions begin]
>       .text
>       .org 0x4c20
>   ## N526: #    out( B1 ) <- BLOCK HEAD IS JUNK  Freq: 1
>    /* 00007f0c40564c20: */ .byte 0x90, 0x90,  0x44, 0x8b,  0x56, 0x08,  
> 0x44, 0x3b
> 
>    /* 00007f0c40564c28: */ #   {runtime_call Shared Runtime ic_miss_blob}
>    /* 00007f0c40564c28: */ .byte 0x50, 0x08,  0x0f, 0x85,  0xb0, 0xd4,  
> 0x9a, 0xff
> # [Verified Entry Point]
>   ## B1: #    out( B34 B2 ) <- BLOCK HEAD IS JUNK  Freq: 1
>    /* 00007f0c40564c30: */ .byte 0x89, 0x84,  0x24, 0x00,  0x80, 0xfe,  
> 0xff, 0x55,  0x48, 0x83,  0xec, 0x60,  0x41, 0x81,  0x7f, 0x20,  0x01, 
> 0x00,  0x00, 0x00,  0x0f, 0x85,  0xd8, 0x06
> 
>    /* 00007f0c40564c48: */ #*synchronization entry
>                            # - java.lang.StringBuilder::append at -1 (line 
> 246)
>    /* 00007f0c40564c48: */ .byte 0x00, 0x00, 0x89, 0x54, 0x24, 0x10, 
> 0x48, 0x8b, 0x4d, 0xde, 0x33, 0xc0, 0x0f, 0x45, 0xbe, 0x00
> 
> And it can then be assembled with a platform assembler, requiring no 
> other tools:
> 
>      4c20:    90                       nop
>      4c21:    90                       nop
>      4c22:    44 8b 56 08              mov    0x8(%rsi),%r10d
>      4c26:    44 3b 50 08              cmp    0x8(%rax),%r10d
>      4c2a:    0f 85 b0 d4 9a ff        jne    0xffffffffff9b20e0
>      4c30:    89 84 24 00 80 fe ff     mov    %eax,-0x18000(%rsp)
>      4c37:    55                       push   %rbp
>      4c38:    48 83 ec 60              sub    $0x60,%rsp
>      ...
> 
> Obviously this is a little scrappy at present, and needs a good deal of 
> tidying
> up to be suitable for mainline. I'm asking for an "in principle" answer 
> here:
> if I could do a neat job, maintaining readability but making sure that 
> in the
> absence of hsdis we can print something that a maintenance programmer 
> can easily
> assemble and dump, would people be interested?
> 



More information about the hotspot-dev mailing list