delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin/2006/09/20/15:37:22

X-Spam-Check-By: sourceware.org
Date: Wed, 20 Sep 2006 15:36:48 -0400
From: Christopher Faylor <cgf-no-personal-reply-please AT cygwin DOT com>
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: <eerlgl$fnq$1 AT sea DOT gmane DOT org> <027801c6dccb$91bb4980$a501a8c0 AT CAM DOT ARTIMI DOT COM> <eerpq2$1a9$1 AT sea DOT gmane DOT org> <07400671-D3C8-4F0E-903A-1BB3233C6D31 AT andrew DOT cmu DOT edu>
Mime-Version: 1.0
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
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
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/

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019