Re: x64 machine code and stack frames
Pedro Alves <[email protected]>
| Newsgroups | gmane.comp.gdb.devel |
|---|---|
| Message-ID | <[email protected]> |
On 01/22/2016 06:46 AM, Dov Grobgeld wrote: > Thanks. Indeed it sounds like the right direction. I have to figure > out how it works in a mixed environment with both static DWARF based > code as well as dynamically allocated code. > > On Fri, Jan 22, 2016 at 4:27 AM, Matt Rice <[email protected]> wrote: >> >> >> On Thu, Jan 21, 2016 at 11:45 AM, Dov Grobgeld <[email protected]> >> wrote: >>> >>> Hello, >>> >>> I've inherited some clever x64 machine code for linux that creates an >>> machine code wrapper around a c-function call. I guess that in higher >>> language terms the code might be called a decorator or a closure. The >>> code is functioning well, but with the unfortunate artifact that when >>> the wrapper is called, it gobbles the stack trace in gdb. >>> >>> From what I have learned from the net gdb uses >>> https://en.wikipedia.org/wiki/DWARF as a guide for separating the >>> stack frames in the stack. This works well for static code, but >>> obviously code generated and called at run time isn't registered in >>> the DWARF framework. >>> >>> My question is if there is any way to rescue the stack trace in this >>> situation? >> >> >> While i haven't really used it before & can't comment on the particulars, >> It sounds like you should be using the jit interface to make gdb aware of >> the symbols generated at runtime. >> >> https://sourceware.org/gdb/onlinedocs/gdb/JIT-Interface.html And for unwinding itself, the new Python unwinder API is something to look at too, if you want to try to avoid DWARF: https://sourceware.org/gdb/current/onlinedocs/gdb/Unwinding-Frames-in-Python.html Thanks, Pedro Alves