X-Spam-Check-By: sourceware.org Date: Wed, 20 Sep 2006 15:36:48 -0400 From: Christopher Faylor To: cygwin AT cygwin DOT com Subject: Re: gdb attach to process to produce stacktrace Message-ID: <20060920193648.GA19097@trixie.casa.cgf.cx> Reply-To: cygwin AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com References: <027801c6dccb$91bb4980$a501a8c0 AT CAM DOT ARTIMI DOT COM> <07400671-D3C8-4F0E-903A-1BB3233C6D31 AT andrew DOT cmu DOT edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <07400671-D3C8-4F0E-903A-1BB3233C6D31@andrew.cmu.edu> User-Agent: Mutt/1.5.11 Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com 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 function. >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". cgf -- 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/