Robert Shearman a écrit :
Mike Hearn wrote:
On Wed, 2004-02-18 at 19:49, Eric Pouech wrote:
this would be as intrusive as using the debugger (I assume that the running process would be in charge of printing the backtrace, or an external process - like a debugger - would print the backtrace, while the program is stopped (or after copying the stack for instrospection, which dbghelp doesn't provide btw))
Why would it be intrusive? Can't you just take a snapshot of the stack and walk it internally? That must be what StackWalk does, right, as apps often try and grab their own backtraces....
You're right that it wouldn't be intrusive (just like Linux kernel backtraces in the kernel log). However, StackWalk doesn't do exactly what you think it does. It generates frame pointer information (including the instruction pointer), but you need to call it recursively. Even then it won't be very readable unless you put in symbol lookups. Very soon you have completed one of the todo's by moving most of winedbg into imagehlp/dbghlp.
the point is that even just taking the snapshot of the stack *is* intrusive, however you do it. Morever, there are a couple of _interesting_ corner cases: - just taking a snapshot of the stack isn't enough: you need to resolve symbols from addresses, which depend on the loaded modules at the time you take the snapshot. Which means that either you load module information when modules are loaded (intrusive too), and when you want to do the stack snapshot (also intrusive) - finally, you end up using 80% of the core functions of a debugger
perhaps the easiest way to implement what you want would be to create a specific exception (like wine_stack_walk). This exception would be very close to the one for undefined symbols. You would insert throwing this except in the places you want in your code, and winedbg would react to it by printing the stack backtrace of current thread and continue execution (we could also extend this as a specific kind of breakpoint, to be set in the debugger)
A+