From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11492 invoked by alias); 6 May 2009 20:47:28 -0000 Received: (qmail 11482 invoked by uid 22791); 6 May 2009 20:47:27 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 06 May 2009 20:47:22 +0000 Received: (qmail 5174 invoked from network); 6 May 2009 20:47:20 -0000 Received: from unknown (HELO orlando.local) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 6 May 2009 20:47:20 -0000 From: Pedro Alves To: gdb-patches@sourceware.org, danny.backx@scarlet.be Subject: Re: Post mortem debugging for Windows CE Date: Wed, 06 May 2009 20:47:00 -0000 User-Agent: KMail/1.9.10 References: <1240929901.29047.110.camel@dannypc> <200905061535.07698.pedro@codesourcery.com> <1241640256.4083.253.camel@dannypc> In-Reply-To: <1241640256.4083.253.camel@dannypc> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200905062148.03196.pedro@codesourcery.com> X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2009-05/txt/msg00137.txt.bz2 On Wednesday 06 May 2009 21:04:16, Danny Backx wrote: > I've done a couple of tests. (See below, lengthy.) The bottom line : > - I should have used solib-search-path the first time you told me, not > =A0 after the second time :-) > - without setting solib-search-path, the output for both live and post- > =A0 mortem (minidump) sessions is a list of DLLs without address range. > - with setting solib-search-path, the output of both live and postmortem > =A0 sessions shows addresses for those DLLs found Right, that is because GDB only shows that info if it finds symbols for the shared library: From To Syms Read Shared Object Library No bad.dll ^^ vs: From To Syms Read Shared Object Library 0x01451000 0x01456044 Yes /home/danny/tmp/arm/test/pedro/bad.dll ^^^ On Wednesday 06 May 2009 21:04:16, Danny Backx wrote: > > BTW, does "info threads" show the correct list of threads? >=20 > Not yet. The place where I found the register contents until now was not > 'thread-safe' - there's only one set of registers there. >=20 > The only additional info I found points to memory regions that the minidu= mp > doesn't contain a copy of. >=20 > Further poking on MSDN reveals a table that explains the contents of "con= text > dumps" (limited in size) vs. "system dumps" and "complete dumps". > See http://msdn.microsoft.com/en-us/library/ms939598.aspx . Ah, I see. If the data ain't there, there's nothing we can do about it. > Also http://msdn.microsoft.com/en-us/library/ms939607.aspx describes > registry settings to influence dump handling. Can't find a way to change > the type of dump though. I think that if you clean this up and post it, it will be nice addition already. You'll need the copyright assignment issues sorted first before we can accept the code though, for binutils (bfd) and gdb. A few suggestions: - Please forgive me if you know this already. Your minidump bfd code should work on all hosts, 64-bit, 32-bit, big endian or little endian. This means that code like: typedef struct FooStructureMSDefinesToBePresentInTheFile { DWORD foo; char b; int c; } FooStructureMSDefinesToBePresentInTheFile; FooStructureMSDefinesToBePresentInTheFile bar; read (fildes, &bar, sizeof (bar)); ... is unacceptable. You need to use the bfd_get_32 and friends to parse the data on the file. - Be sure to follow the coding standards: http://www.gnu.org/prep/standards/html_node/Formatting.html Standard nit-picks: space between function name and '('. double space after periods in comments. tabs are prefered to spaces. - Don't forget a ChangeLog entry. --=20 Pedro Alves