From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29247 invoked by alias); 28 Apr 2009 17:48:31 -0000 Received: (qmail 29235 invoked by uid 22791); 28 Apr 2009 17:48:30 -0000 X-SWARE-Spam-Status: No, hits=-2.1 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_55,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: sourceware.org Received: from sif.is.scarlet.be (HELO sif.is.scarlet.be) (193.74.71.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 28 Apr 2009 17:48:24 +0000 Received: from [172.17.1.2] (ip-62-235-147-185.dsl.scarlet.be [62.235.147.185] (may be forged)) by sif.is.scarlet.be (8.14.2/8.14.2) with ESMTP id n3SHm4tM002183; Tue, 28 Apr 2009 19:48:04 +0200 Subject: Re: Post mortem debugging for Windows CE From: Danny Backx Reply-To: danny.backx@scarlet.be To: Pedro Alves Cc: gdb-patches@sourceware.org In-Reply-To: <200904281702.30473.pedro@codesourcery.com> References: <1240929901.29047.110.camel@dannypc> <200904281702.30473.pedro@codesourcery.com> Content-Type: text/plain Date: Tue, 28 Apr 2009 17:48:00 -0000 Message-Id: <1240940884.29047.135.camel@dannypc> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-DCC-scarlet.be-Metrics: sif 20001; Body=3 Fuz1=3 Fuz2=3 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-04/txt/msg00762.txt.bz2 On Tue, 2009-04-28 at 17:02 +0100, Pedro Alves wrote: > On Tuesday 28 April 2009 15:45:01, Danny Backx wrote: > > Hi, > > > > I wrote a program, see below, that can be used either on a development > > host, or on a Windows CE target, to decode stuff from a dump file as > > generated by CE. > > > > I don't think gdb currently has this capability (to inspect postmortem > > dump files) for debugging CE applications. > > These are minidump files, right? The same infrastructure could > be used for minidumps for desktop Windows apps? I've never used > a minidump, but, IIRC, these are a form of bare-essential core > dumps, without much of memory contents? I'm not exactly sure what > kinds of info a minidump contains -- I'd expect at least the register > contexts of all threads in the process, and the list of loaded > dlls, along with their load addresses. Is it possible to recontruct > a call stack from these? Do they include stack memory? Yes, minidumps are one of the terms Microsoft uses. "Dr. Watson" is another, although that usually refers to the tool to read those dumps. All of the info I have on this comes from MSDN, you can look around near http://msdn.microsoft.com/en-us/library/ms939593.aspx . I searched for "minidump format vista" on MSDN and found http://support.microsoft.com/kb/315263 which describes that desktop Windows uses the same mechanism. One of the comments in the first link I provided is that the dump file format is the same across architectures. There are several "streams" in such a dump file, for CE they're named ceStreamSystemInfo ceStreamException ceStreamModuleList ceStreamProcessList ceStreamThreadList ceStreamThreadContextList ceStreamThreadCallStackList ceStreamMemoryVirtualList ceStreamMemoryPhysicalList ceStreamBucketParameters I've not decoded them all yet. The example I sent in the earlier mail shows output after the "stream %d, .." line if I decode that stream already. > > Is this something I should port into the gdb source tree and submit, or > > is it not worth it ? If yes, please advise where this belongs. > > Can you clarify what you mean exactly by porting to the gdb source > tree? If you mean integrating it as a standalone app as is currently, > then, this would better go into binutils, as a minidump > dumper. You'd want to make it build independantly if any CE headers. Good questions. The last one is simple : - right now the source depends on only one header file (except from the Linux includes on my PC). This one header file has been created by reading MSDN material only. Look around at the first link above and you'll find it all. - so : no dependencies you don't want in the gdb or bfd sources Your other question is basically what I wanted to ask about. My idea was your option #2 below. But before I even start thinking about doing that, I'd like to know whether this is a sensible thing to put my time in, and pointers on where to start. Danny > If you mean adding gdb support to load minidump files, I can think > of several ways to skin that cat: > > 1) write a minidump -> elf core dump translator. Base the core file > notes on the cygwin elf core format, for e.g.. See e.g, > src/bfd/elf.c:elfcore_grok_win32pstatus, and cygwin's dumper utility > sources for inspiration. Probably no bfd changes are required > this way. Teach src/gdb/arm-wince-tdep.c how to extract loaded > dll list from the core's .module sections. See > src/gdb/i386-cygwin-tdep.c:windows_core_xfer_shared_libraries. We could > probably reuse most of this. > > 2) teach bfd proper about minidumps, and export the register > set info with fake .reg sections, similarly to how we do for elf > core dumps. If you export the same set of sections GDB expects from > elf cores (e.g., .reg/XXX sections for thread register sets, .module sections > for loaded dlls.), then the GDB tweaks are the same as > for #1 above. E.g, teach src/gdb/arm-wince-tdep.c how to extract the loaded > dll list from the core's .module sections. > > 3) Teach GDB about minidumps, by adding a new minidump target_ops, > similar in vein to src/gdb/corelow.c. GDB doesn't currenly like > having more than on core file target_ops, though. > > 4) forget about adding support for minidumps, or post-processing them > to elf; and instead port cygwin's dumper.exe utility to CE, making > it spit real elf full-contents core dumps. This assumes you have > memory space on the device for this, of course. > -- Danny Backx ; danny.backx - at - scarlet.be ; http://danny.backx.info