From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2292 invoked by alias); 2 Feb 2007 16:51:04 -0000 Received: (qmail 2284 invoked by uid 22791); 2 Feb 2007 16:51:03 -0000 X-Spam-Check-By: sourceware.org Received: from nile.gnat.com (HELO nile.gnat.com) (205.232.38.5) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 02 Feb 2007 16:50:56 +0000 Received: from localhost (localhost [127.0.0.1]) by filtered-nile.gnat.com (Postfix) with ESMTP id 5E23848CBB4; Fri, 2 Feb 2007 11:50:54 -0500 (EST) Received: from nile.gnat.com ([127.0.0.1]) by localhost (nile.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 09003-01-5; Fri, 2 Feb 2007 11:50:53 -0500 (EST) Received: from takamaka.act-europe.fr (unknown [70.71.0.212]) by nile.gnat.com (Postfix) with ESMTP id B819B48CBAE; Fri, 2 Feb 2007 11:50:53 -0500 (EST) Received: by takamaka.act-europe.fr (Postfix, from userid 1000) id B10CE34C099; Fri, 2 Feb 2007 08:51:55 -0800 (PST) Date: Fri, 02 Feb 2007 16:51:00 -0000 From: Joel Brobecker To: Robert Dewar , Wiljan Derks , gdb@sourceware.org, Mark Kettenis Subject: Re: How to tell gdb about dlls using remote protocol Message-ID: <20070202165155.GS17864@adacore.com> References: <003f01c7457c$0f2d8090$9600000a@kamer> <20070131223113.GA15122@nevyn.them.org> <20070201175311.GG17864@adacore.com> <20070201225437.GA13740@nevyn.them.org> <20070201230301.GM17864@adacore.com> <20070201235944.GA16114@nevyn.them.org> <45C2D80E.2050403@adacore.com> <20070202114312.GA15239@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070202114312.GA15239@nevyn.them.org> User-Agent: Mutt/1.4.2.2i Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2007-02/txt/msg00016.txt.bz2 > Sorry, I have to disagree from my own experience. Pretty much any time > you stop a running program it's in those DLLs. And this is doubly true > for any threaded program - there's always a couple of threads that I > have no idea what the heck they're doing. In fact, we have a local modification in our tree (different from the one I recently suggested) where we default to using %ebp when inside a frameless function, and inside a DLL. This is a heuristic way to handle all those highly optimized functions for which prologue analysis cannot be used. Short of implementing support for MS symbol info, this is the only way we could get the backtrace of most threads. This is a hack I didn't submit because it's a bit crude, and it only exchanges certain failures for others - but we have found in practice that this was the right choice for us. I can certainly post it too, if you are interested. -- Joel