gdb can not parse backtrace

[ZjW1nd]

Gdb only read ELF format vmcore which misses the vmalloc map in LOAD header, so that when CONFIG_VMAP_STACK is on, gdb can't get backtrace of the kernel because it can't access 0xffffc900 addr.

I use:

• gdb 16.2
• vmcore linux version: 6.13.7
• libkdumpfile 0.5.5 from pacman
• pykdumpfile from pip
• python 3.13.2

When VMAP_STACK is on, after using this gdbserver I found that gdb can access 0xffffc900 addr by using x /20gx 0xffffc90000233dd0, but when I use bt, it still cannot get correct backtrace.

pwndbg> bt
#0  0xffffffff811d440b in crash_prepare_elf64_headers (mem=0xffffc90000233dd8, need_kernel_map=0, addr=0x0 <fixed_percpu_data>, 
    sz=0xffffffffa00041b8) at kernel/crash_core.c:210
#1  0x00000000000001a0 in ?? ()
#2  0x0000000000000000 in ?? ()

pwndbg> x /20gx 0xffffc90000233dd8
0xffffc90000233dd8:     0x0000000000000008      0xffffc90000233e58
0xffffc90000233de8:     0xffffc90000233df8      0xf2a511a248595700
0xffffc90000233df8:     0x0000000000000008      0x0000000000000001
...

pwndbg> vmmap
There are no mappings for specified address or module.

PS: my gdb version has a bug which leads to a instant segfault when I execute gdb vmlinux vmcore (I dont know if it's related with this bug and I didn't find any solutions).

For other gdb15 in my ubuntu24.04 docker, it do work. But python3-libkdumpfile(0.5.4) from apt maybe too old, i cant run the script. Even if I build pykdumpfile by python setup.py, gdb still cant read 0xffffc90.

That's all I encountered. I dont know what is going on with all of this, so I just turned CONFIG_VMAP_STACK off now. 😫

[ZjW1nd]

1. GDB crash is unrelated with the problem of kdump-gdbserver

The gdb crash problem is reported here, it will be fixed in the next release. It only happens when gdb tries to open a coredump file.

2. Manually build:

I built libkdump0.5.5 manually in Ubuntu24.04 docker and use pip install pykdumpfile without using apt. It goes like this:

NVM, I realized that I missuse with the VMAP_STACK on kernel with the off vmcore.

[ptesarik]

First, thank you for your interest in kdump-gdbserver!
Second, I have not been able to reproduce the issue on my reference dump file, but that's kernel v6.6 (with CONFIG_VMAP_STACK=y).
Third, at first glance the issue seems unrelated to kdump-gdbserver, because you have confirmed that gdb can read stack virtual memory. However, even the initial frame looks incorrect:

#0  0xffffffff811d440b in crash_prepare_elf64_headers (mem=0xffffc90000233dd8, need_kernel_map=0, addr=0x0 <fixed_percpu_data>, 
    sz=0xffffffffa00041b8) at kernel/crash_core.c:210

Here, the sz argument looks like a valid pointer rather than valid size. This hints at incorrect (or incorrectly interpreted) debug information. Are you 100% sure that you're running gdb with the same vmlinux binary which produced the dump file?

[ZjW1nd]

I'm sorry that I maybe mismatch the VMAP_STACK=n vmlinux with a VMAP_STACK=y old vmcore ( or maybe mismatch the versions idk). I wrote a test program and try to reproduce it today but everything seems fine now.

Maybe it's because I have ever encountered so many weird situations during the development so that I don't trust this repo which is commited two years ago🥲. But still thank you for your help and again so sorry for bothering you.

And also thank you for this gdb-server, really appreciate that 💟 !

PS: there is a little bit problem which makes python warning everytime I start, I fixed it but there is no need for a PR:
From 231-238:

    M_PACKET = b'^m([0-9a-f]+),([0-9a-f]+)$'
    H_PACKET = rb'^H[a-z](p?[0-9a-f\.]+)$' 
    T_PACKET = rb'^T(p?[0-9a-f\.]+)$'
    Q_SUPPORTED_PACKET = b'^qSupported:(.+)$'
    Q_ATTACHED_PACKET = b'^qAttached:(.+)$'
    D_PID_PACKET = b'^D;[0-9a-f]+$'
    VKILL_PACKET = rb'^vKill;(p?[0-9a-f\.]+)$'
    T_INFO_PACKET = rb'^qThreadExtraInfo,(p?[0-9a-f\.]+)$'