7

Sometimes there is some small stack corruption that causes gdb to fail doing a "backtrace", I have created the below gdb macro (x86-64, can be easily made to work for x86) that depends on turning off omit-frame-pointer (i.e. -fno-omit-frame-pointer) and shows me the functions in the backtrace. However, I'd like it to also show parameter values and ideally be able to select one of these frames. (i.e. something such as "frame 0x0123456789ABCDEF").

define et
set $frameptr = $rbp
while $frameptr != 0
 set $oldbp = *((void**)($frameptr+8))

 print $frameptr
 print $oldbp
 info symbol $oldbp

 set $frameptr = *((void**)($frameptr))
 end
end
Erik Elmgren
  • 760
  • 1
  • 4
  • 21
  • 1
    You can give `frame` an address argument. A frame's address is the stack pointer in the previous frame at the point of the function call that created the current frame. Looking at programs compiled with gcc on x86_64, after a function's prologue has been run, the frame address chosen by gdb seems to always be 16+$rbp. After selecting a frame, `info args` will show the function's arguments. – Mark Plotnick Jun 11 '14 at 17:42
  • unfortunately it does not work for me, gdb seems to only want to select frames it has found with its own stack walking. And "info frame" gives "internal-error: value_fetch_lazy: Assertion `frame != NULL' failed" after some other messages. It should really need both a frame ptr AND a instruction pointer to understand what debug-info to use to decode the frame, so I can understand why it fails, but a method to make it work would be very appreciated. Note that it will all work fine if you debug with a non-crashed stack, then it'll have found the frame at the address and work everything out. – Erik Elmgren Jun 12 '14 at 12:42
  • Oops, not a duplicate; you already have a working function and want to add features. See also [Force GDB to use frame-pointer based unwinding](https://stackoverflow.com/questions/42739893/force-gdb-to-use-frame-pointer-based-unwinding) for another implementation. – Peter Cordes Dec 10 '17 at 16:18
  • Out of curiosity, how does this get around stack corruption? Using a frame pointer like `rbp` only points to the location on the stack where the prior `rbp` can be found, and so on, so any stack corruption that smashed that would break the backtrace, and conversely the other methods of backtracing (like using debuginfo) would seem to be at least as tolerant of such corruption (and perhaps more). – BeeOnRope Dec 10 '17 at 16:29
  • @BeeOnRope I don't know why gdb got confused (don't have any example core file at hand). Even with frame pointers in the exe it refused to produce a real stack although I could do so manually and the macro worked. – Erik Elmgren Dec 13 '17 at 16:24

0 Answers0