On Mon, 2 Nov 2026 03:11:50 GMT, Long Yang <[email protected]> wrote:
>> src/jdk.hotspot.agent/linux/native/libsaproc/dwarf.hpp line 110:
>>
>>> 108: enum DWARF_Register get_ra_register() { return
>>> _state.return_address_reg; }
>>> 109: int get_offset_from_cfa(enum DWARF_Register reg) {
>>> 110: // Malformed DWARF can supply a register number outside the map
>>
>> In general are we writing our DWARF parsing code to handle malformed DWARF?
>> Was there something that triggered the need for this code?
>
> Thanks for pointing this out. This is defensive code, not prompted by a
> real-world issue with compiler-generated DWARF.
>
> The `offset_from_cfa` is fixed size. Hand-written assembly could specify a
> return-address column outside the initialized register range without
> supplying a recovery rule; operator[] would then insert an offset of zero,
> causing SA to read the word at CFA as the return address, potentially
> producing a bogus PC and an incorrect or truncated stack trace. Returning
> INT_MAX instead marks the offset as unavailable and avoids that read.
> https://github.com/openjdk/jdk/blob/592affb46a0734aabbf8f185a33d4d3a7a37a021/src/jdk.hotspot.agent/linux/native/libsaproc/dwarf.cpp#L47-L56
>
> I’m happy to remove this check if you prefer.
I give +1 to this change because `DwarfParser` might meet unknown registers in
the process in future. I guess it might be Intel APX register (R16 for
example). This change could prevent undefined behavior on new CPU architectures.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/33374#discussion_r4438926994
