gdb attach to process to produce stacktrace

[Ethan Tira-Thompson]

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...

(2) Can't step out of the Windows code back into the user code.   
You're right, we don't really care what windows is doing, and so we'd  
be happy to break out of it and get back to user code.  But stepping  
beyond the beginning of the "context switch" just continues  
execution, and doesn't let us return to the calling function.

With both (1) and (2) in place, it's very difficult to debug a  
program if we don't already know where the problem is, *particularly*  
if it's blocking/crashing on an irreplaceable system call.  What made  
the system call?  What arguments were in play?  No way to know!

The only work around it seems is that if you can *guess* where the  
execution is at, and set a breakpoint in your code after where the  
function is to return, *and if your execution isn't already hosed by  
this point*, gdb will stop at the breakpoint and then show you the  
stack of your code, with all the current variable values and such  
that make a debugger a debugger.

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.

-ethan

For a quick example, try figuring out why this example program is  
crashing... The idea is simple: set up an array of strings containing  
'a' through 'z', build a string from 100 random selections, and then  
display the result.

No fair figuring it out from looking at the code (it's a suitably  
subtle newbie type problem, though obfuscated enough it's not  
glaringly obvious) -- pretend it's a "real" problem in a piece of  
fairly complicated code that isn't just a dozen lines long, try using  
gdb to figure it out. (for the lazy/hurried, answer posted here,  
including comparison to what happens in cygwin: http://ethan.tira- 
thompson.com/stuff/gdb-answer.html )

-------------- next part --------------
A non-text attachment was scrubbed...
Name: test.c
Type: application/octet-stream
Size: 1335 bytes
Desc: not available
URL: <http://cygwin.com/pipermail/cygwin/attachments/20060920/732f8389/attachment.obj>
-------------- next part --------------


-------------- next part --------------
--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/