From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27677 invoked by alias); 23 Aug 2006 17:51:15 -0000 Received: (qmail 27669 invoked by uid 22791); 23 Aug 2006 17:51:14 -0000 X-Spam-Check-By: sourceware.org Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.31.1) with ESMTP; Wed, 23 Aug 2006 17:51:12 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1GFwsf-0008AZ-FO; Wed, 23 Aug 2006 13:51:09 -0400 Date: Wed, 23 Aug 2006 18:40:00 -0000 From: Daniel Jacobowitz To: Joel Brobecker Cc: gdb-patches@sources.redhat.com Subject: Re: [i386/fyi] small adjustment to i386 frame code Message-ID: <20060823175109.GA31254@nevyn.them.org> Mail-Followup-To: Joel Brobecker , gdb-patches@sources.redhat.com References: <20060823173849.GG11591@adacore.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060823173849.GG11591@adacore.com> User-Agent: Mutt/1.5.11+cvs20060403 X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-08/txt/msg00183.txt.bz2 On Wed, Aug 23, 2006 at 10:38:49AM -0700, Joel Brobecker wrote: > Although the new frame code gives more much more accurate results > most of the time, there are some occasional cases where we have > to unwind through functions which do not follow the ABI, and for > which no frame debugging info seem to be provided. In these particular > cases, the unwinder fails, and a backtrace from such function aborts > prematurely. One such example is WaitForSingleObjectEx (in one of > the windows DLL). I posted the assembly of this function a long while > ago, it's just plain impossible to determine where the frame base is. FYI: I'm not at all sure I agree with your assertion of impossibility. But when I tried to debug native Windows code, my main problem was figuring out the starts of symbols. The DLLs themselves don't have enough symbolic information in them. Things that look like a single function are actually often many functions in a row, only one of which was exported. Symbolic info files are available automatically from Microsoft, but it seems like a serious hassle to auto-download them. And if you want to get a lot of useful information out of them you need a DLL (which is freely distributable) but also its header (which isn't; it's part of the commercial Visual Studio offerings only). That's where I gave up. It should be possible to do this very nicely. I was considering a standalone program, not part of GDB, which would generate separate symbol files in a non-Microsoft format that GDB could understand (maybe Dwarf). As long as you don't redistribute the result I think that's OK by the MS licensing. I just didn't have time to work on it myself. -- Daniel Jacobowitz CodeSourcery