From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28640 invoked by alias); 28 Apr 2009 19:18:02 -0000 Received: (qmail 28615 invoked by uid 22791); 28 Apr 2009 19:18:00 -0000 X-SWARE-Spam-Status: No, hits=-2.2 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_55,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: sourceware.org Received: from hel.is.scarlet.be (HELO hel.is.scarlet.be) (193.74.71.26) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 28 Apr 2009 19:17:50 +0000 Received: from [172.17.1.2] (ip-62-235-147-185.dsl.scarlet.be [62.235.147.185] (may be forged)) by hel.is.scarlet.be (8.14.2/8.14.2) with ESMTP id n3SJHY63017921; Tue, 28 Apr 2009 21:17:35 +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: <1240940884.29047.135.camel@dannypc> References: <1240929901.29047.110.camel@dannypc> <200904281702.30473.pedro@codesourcery.com> <1240940884.29047.135.camel@dannypc> Content-Type: text/plain Date: Tue, 28 Apr 2009 19:18:00 -0000 Message-Id: <1240946254.29047.159.camel@dannypc> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-DCC-scarlet.be-Metrics: hel 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/msg00763.txt.bz2 Here's more info, I've decoded more of the dump. I think the three chunks of memory included (see stream 8) are : #0 : 80 bytes from the program text at the point of the crash #1 : 380 bytes near the end of address space (I have no clue) #2 : some amount of memory from the frame pointer (see stream 6) I've run this report on two crash dumps just now, here are the last lines of both sets of output. Note that #2 differs. Roadmap (the first dump) is a real application (GPS stuff). The second dump is from a trivial test app called "callstack". =========== stream 6, type 8007 (Thread Callstack), size 24 Thread Call Stack List : 1 entries Process A0D26B72 thread A17A19A2, 1 frames Frame 0 : RetAddr 0x20039CE4 FP 0x201EF654 stream 7, type 800a (Bucket parameters), size 64 Bucket parameters : AppName [wroadmap.exe] OwnerName [wroadmap.exe] Module [wroadmap.exe] stream 8, type 8008 (Memory virtual list), size 56 Memory list 3 entries Entry 0 start 0x20039CA4 len 80 Rva 2C70 Entry 1 start 0xFFFFC800 len 380 Rva 2CF0 Entry 2 start 0x201EC000 len 4000 Rva 3070 stream 9, type 8009 (Memory physical list), size 8 Memory list 0 entries ========== stream 6, type 8007 (Thread Callstack), size 24 Thread Call Stack List : 1 entries Process 21623686 thread 236B284E, 1 frames Frame 0 : RetAddr 0x26011178 FP 0x2611FB0C stream 7, type 800a (Bucket parameters), size 64 Bucket parameters : AppName [callstack] OwnerName [callstack] Module [callstack] stream 8, type 8008 (Memory virtual list), size 56 Memory list 3 entries Entry 0 start 0x26011138 len 80 Rva 18D0 Entry 1 start 0xFFFFC800 len 380 Rva 1950 Entry 2 start 0x2611F000 len 1000 Rva 1CD0 stream 9, type 8009 (Memory physical list), size 8 Memory list 0 entries ========== So I think all the bits and pieces for gdb to do a backtrace might actually be there... Maybe memory dump #1 is a register dump :-) Danny On Tue, 2009-04-28 at 19:48 +0200, Danny Backx wrote: > 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