RFR: 8369994: Mixed mode jhsdb jstack cannot resolve symbol with cold attribute

[Yasumasa Suenaga]

On Thu, 16 Oct 2025 13:32:28 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> `jhsdb jstack --mixed` with coredump cannot resolve function symbol which has `.cold` attribute.
> 
> 
> ----------------- 120485 -----------------
> "Thread-0" #24 prio=5 tid=0x00007f50dc1aa7c0 nid=120485 waiting on condition [0x00007f50c0d1a000]
>    java.lang.Thread.State: TIMED_WAITING (sleeping)
>    JavaThread state: _thread_blocked
> 0x00007f50e4710735 __GI_abort + 0x8b
> 0x00007f50e1e01f33 ????????
> 
> 
> 0x7f50e1e01f33 was `os::abort(bool, void const*, void const*) [clone .cold]` and I could see it in GDB. However it has `.cold` suffix, it means the code has been relocated as ["cold" function](https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#index-cold-function-attribute). In GDB, we can see the code in another area from function body as following:
> 
> 
> (gdb) disas 0x7f50e1e01f2e, 0x7f50e1e01f34
> Dump of assembler code from 0x7f50e1e01f2e to 0x7f50e1e01f34:
>    0x00007f50e1e01f2e <_ZN2os5abortEbPKvS1_.cold+0>: call 0x7f50e1e01010 <abort at plt>
> => 0x00007f50e1e01f33: nop
> End of assembler dump.
> 
> 
> libsaproc.so checks address range to resolve symbol whether the address is in between `start` and `start + size - 1`. As you can see in assembler dump, the code in `.cold` section is `call` instruction, thus IP points next `nop`, thus we should allow address range between `start` and `start + size`.
> 
> After this PR, you can see the right symbol as following:
> 
> 
> ----------------- 120485 -----------------
> "Thread-0" #24 prio=5 tid=0x00007f50dc1aa7c0 nid=120485 waiting on condition [0x00007f50c0d1a000]
>    java.lang.Thread.State: TIMED_WAITING (sleeping)
>    JavaThread state: _thread_blocked
> 0x00007f50e4710735      __GI_abort + 0x8b
> 0x00007f50e1e01f33      os::abort(bool, void const*, void const*) [clone .cold] + 0x5

I looked into the spec / implementation in GDB, binutils, GCC - but I could not find out unfortunately... It might be a convention that debugger like GDB can handle it correctly.

In GDB, we can see following frame information. `_ZN2os5abortEbPKvS1_.cold` (`os::abort(bool, void const*, void const*) [clone .cold]` in demangling) from jumped by ` _ZN2os5abortEbPKvS1_` (`os::abort(bool, void const*, void const*)`), thus they are same frame.


(gdb) disas
Dump of assembler code for function _ZN2os5abortEbPKvS1_:
Address range 0x7f3e1ef0f850 to 0x7f3e1ef0f888:
   0x00007f3e1ef0f850 <+0>:     push   %rbp
   0x00007f3e1ef0f851 <+1>:     mov    %rsp,%rbp
   0x00007f3e1ef0f854 <+4>:     push   %rbx
   0x00007f3e1ef0f855 <+5>:     mov    %edi,%ebx
   0x00007f3e1ef0f857 <+7>:     sub    $0x8,%rsp
   0x00007f3e1ef0f85b <+11>:    call   0x7f3e1ef0f820 <_ZN2os8shutdownEv>
   0x00007f3e1ef0f860 <+16>:    test   %bl,%bl
   0x00007f3e1ef0f862 <+18>:    jne    0x7f3e1ef0f86e <_ZN2os5abortEbPKvS1_+30>
   0x00007f3e1ef0f864 <+20>:    mov    $0x1,%edi
   0x00007f3e1ef0f869 <+25>:    call   0x7f3e1da01250 <_exit at plt>
   0x00007f3e1ef0f86e <+30>:    lea    0x1167254(%rip),%rax        # 0x7f3e20076ac9 <DumpPrivateMappingsInCore>
   0x00007f3e1ef0f875 <+37>:    cmpb   $0x0,(%rax)
   0x00007f3e1ef0f878 <+40>:    je     0x7f3e1da01f2e <_ZN2os5abortEbPKvS1_.cold>
   0x00007f3e1ef0f87e <+46>:    call   0x7f3e1e1d2010 <_ZN11ClassLoader15close_jrt_imageEv>
   0x00007f3e1ef0f883 <+51>:    jmp    0x7f3e1da01f2e <_ZN2os5abortEbPKvS1_.cold>
Address range 0x7f3e1da01f2e to 0x7f3e1da01f33:
   0x00007f3e1da01f2e <-22075682>:      call   0x7f3e1da01010 <abort at plt>
End of assembler dump.


The key point is that `RIP` does not point jump'ed code (in `.cold`). `RIP` points the next instruction. It is not covered in both symtab and DWARF.


(gdb) disas 0x7f3e1da01f2e,0x7f3e1da01f34
Dump of assembler code from 0x7f3e1da01f2e to 0x7f3e1da01f34:
   0x00007f3e1da01f2e <_ZN2os5abortEbPKvS1_.cold+0>:    call   0x7f3e1da01010 <abort at plt>
=> 0x00007f3e1da01f33:  nop
End of assembler dump.


My goal is to unwind all of call frames in `jhsdb jstack --mixed` without any unknown symbols.  To realize it, I think it is better to scan the address `RIP - 1` when SA cannot resolve symbol / find DWARF CFA as a fallback. I think it is reasonable than to make change in symtab.c like this PR. @kevinjwalls What do you think?

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

PR Comment: https://git.openjdk.org/jdk/pull/27846#issuecomment-3418401185