gdb attach to process to produce stacktrace

Christopher Faylor
Wed Sep 20 19:37:00 GMT 2006

On Wed, Sep 20, 2006 at 03:17:29PM -0400, Ethan Tira-Thompson wrote:
>Wait, wait, don't give up so quickly -- this is the same problem I  
>reported a while back as well, and I'd like to see a better  
>resolution than "doctor, it hurts when I move my arm"; "well then  
>don't move your arm!" ...some of us actually need to use our arms.   
>Maybe you can get around using sleep() this time, but you can't avoid  
>ever using system calls...
>I see two problems when attaching to a process, or breaking (ctl-C)  
>one already loaded and running:
>(1) All of the function calls on the stack prior to a "context"  
>switch (call from cygwin code to windows code, and also possibly from  
>user code to cygwin1.dll code) show up as '??', even though symbols  
>are available.  This makes the stack trace useless because we don't  
>know where the user code is at when it made the call, can't use 'up'  
>and examine locals or arguments at the point of the call, etc...

It's not symbols that are the problem.  It's the lack of a proper stack
frame in many Windows (and Cygwin for that matter) functions.  If the
ebp register hasn't been stored on the stack then gdb will be confused.

Cygwin also messes with the stack in order to handle signals which makes
getting a backtrace harder if you happen to catch execution in a Cygwin

>Personally, I don't consider cross-development under cygwin feasible  
>without a working debugger.  So is there a workaround to these issues  
>besides replacing all the system calls?  (In other words, not running  
>Windows...)  Because if not, there's no point in me trying to support  
>our robot simulator under cygwin because users won't be able to debug  
>their code, which is the whole point of the simulator.

Personally, I always just look at the contents of the stack to infer
a stack trace but that's hardly a "workaround".


Unsubscribe info:
Problem reports:

More information about the Cygwin mailing list