Re: bt in traces

2004-02-20 Thread Eric Pouech
Dimitrie O. Paun a écrit : On Thu, 19 Feb 2004, Eric Pouech wrote: 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 th

Re: bt in traces

2004-02-19 Thread Dimitrie O. Paun
On Thu, 19 Feb 2004, Eric Pouech wrote: > 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

Re: bt in traces

2004-02-19 Thread Eric Pouech
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

Re: bt in traces

2004-02-19 Thread Fabian Cenedese
>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

RE: bt in traces

2004-02-18 Thread Robert Shearman
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 progr

Re: bt in traces

2004-02-18 Thread Mike Hearn
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 c

Re: bt in traces

2004-02-18 Thread Eric Pouech
Mike Hearn a écrit : On Wed, 18 Feb 2004 11:19:10 +0100, Fabian Cenedese wrote: But besides that: I like to have the full picture of what was going on, from program start to end. And it could also be that a function was called differently on different occasions. (If there was only one possibility

Re: bt in traces

2004-02-18 Thread Mike Hearn
On Wed, 18 Feb 2004 11:19:10 +0100, Fabian Cenedese wrote: > But besides that: I like to have the full picture of what was going on, > from program start to end. And it could also be that a function was > called differently on different occasions. (If there was only one possibility > a simple grep

Re: bt in traces

2004-02-18 Thread Fabian Cenedese
>>Is it possible to output the backtrace while the program is running? I >>mean that with a new debug command e.g. wine_dbg_bt or so you >>could output not only the name of the called function and the argument >>values (as with the debug channels) but also the call stack where it >>came from. That

Re: bt in traces

2004-02-18 Thread Boaz Harrosh
why can't you Just use a debugger? Fabian Cenedese wrote: Hi Is it possible to output the backtrace while the program is running? I mean that with a new debug command e.g. wine_dbg_bt or so you could output not only the name of the called function and the argument values (as with the debug chann

bt in traces

2004-02-18 Thread Fabian Cenedese
Hi Is it possible to output the backtrace while the program is running? I mean that with a new debug command e.g. wine_dbg_bt or so you could output not only the name of the called function and the argument values (as with the debug channels) but also the call stack where it came from. That's of c