GDB: how to print function argument values when no name symbols available

Question

I'm inspecting a core dump and need to print function arguments values when only their types are known (no argument name symbols):

(gdb) frame 7
#7  0x00007f201a269e82 in f1(std::basic_string<char, std::char_traits<char>, std::allocator<char> >, unsigned char*, int, std::basic_string<char, std::char_traits<char>, std::allocator<char> >*) () from /usr/lib64/libsome.so
(gdb) info args
No symbol table info available.
(gdb) info f
Stack level 7, frame at 0x7f200ebf9e50:
 rip = 0x7f201a269e82
    in f1(std::basic_string<char, std::char_traits<char>, std::allocator<char> >, unsigned char*, int, std::basic_string<char, std::char_traits<char>, std::allocator<char> >*); saved rip 0x7f201b430905
 called by frame at 0x7f200ebfa1c0, caller of frame at 0x7f200ebf9e00
 Arglist at 0x7f200ebf9df8, args:
 Locals at 0x7f200ebf9df8, Previous frame's sp is 0x7f200ebf9e50
 Saved registers:
  rbx at 0x7f200ebf9e28, rbp at 0x7f200ebf9e30, r12 at 0x7f200ebf9e38, r13 at 0x7f200ebf9e40, rip at 0x7f200ebf9e48

Specifically, I need to know what's in the first argument (std::string) and in the last one (std::string*). The arglist and the locals in this frame both point to the same address...

Answer 1

There is no simple way to do this.

What you need to do is to look up the ABI for your platform and then use that to understand the argument-passing convention. This isn't always easy but it can be done. This will tell you how to find the arguments, whether they are in registers or memory; and then you can use casts to the appropriate types to print them.

Of course, the casting may also be difficult if you don't have debuginfo. Though there is a trick: compile a dummy file with -g that has the types you need and then symbol-file it into gdb to get access to the types. This of course has caveats, you have to use the correct compiler and library versions, correct compiler target and ABI-changing flags, etc.

It's really much, much, much better to plan ahead and always have debug info somewhere. Which doesn't help you now but could in the future. Being able to ship a program but keep the debug info available for later is basically the reason that split debuginfo was invented.

Also, it's worth noting that the gdb frame output hasn't changed much since the stabs days, which are long gone. I think the "arglist" and "locals" information is truly meaningless with DWARF and modern ABIs. There's a gdb bug open about fixing this.