From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12192 invoked by alias); 23 Aug 2006 18:10:44 -0000 Received: (qmail 12170 invoked by uid 22791); 23 Aug 2006 18:10:43 -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; Wed, 23 Aug 2006 18:10:39 +0000 Received: from localhost (localhost [127.0.0.1]) by filtered-nile.gnat.com (Postfix) with ESMTP id 7EF3A48CBF3 for ; Wed, 23 Aug 2006 14:10:37 -0400 (EDT) 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 24478-01-4 for ; Wed, 23 Aug 2006 14:10:37 -0400 (EDT) Received: from takamaka.act-europe.fr (unknown [70.71.0.212]) by nile.gnat.com (Postfix) with ESMTP id 2907A48CBDE for ; Wed, 23 Aug 2006 14:10:37 -0400 (EDT) Received: by takamaka.act-europe.fr (Postfix, from userid 507) id 732EC47EFA; Wed, 23 Aug 2006 11:10:36 -0700 (PDT) Date: Wed, 23 Aug 2006 21:30:00 -0000 From: Joel Brobecker To: gdb-patches@sources.redhat.com Subject: Re: [i386/fyi] small adjustment to i386 frame code Message-ID: <20060823181036.GE1060@adacore.com> References: <20060823173849.GG11591@adacore.com> <20060823175109.GA31254@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060823175109.GA31254@nevyn.them.org> User-Agent: Mutt/1.4i 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/msg00184.txt.bz2 > 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. Humpf, that could indeed mess things up. We've seen this on IRIX as well IIRC (static symbols not beeing part of the symbol table after the link). > 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. This is very interesting information, thanks! Just some thoughts... It looks like a very nice project for a Windows lover (I'm the opposite). I wonder what the implications would be in terms of licensing if we used the header. Here's what I'm thinking: Make the header optional during compile time. If found, then use it. Then make the DLL optional during runtime. If found, then load it, and then use it. That way, users that download the sources can build with extra support. Companies like us who provide binaries should be able to use the header file just during the build, and would not need to distribute. Actually, I'm not sure about making the DLL optional at link time. My experience with libunwind use in GDB tells me that it might be better to link the DLL in at build time. -- Joel