From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30130 invoked by alias); 28 Apr 2009 16:02:44 -0000 Received: (qmail 29882 invoked by uid 22791); 28 Apr 2009 16:02:42 -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; Tue, 28 Apr 2009 16:02:29 +0000 Received: (qmail 12546 invoked from network); 28 Apr 2009 16:02:27 -0000 Received: from unknown (HELO orlando) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 28 Apr 2009 16:02:27 -0000 From: Pedro Alves To: gdb-patches@sourceware.org, danny.backx@scarlet.be Subject: Re: Post mortem debugging for Windows CE Date: Tue, 28 Apr 2009 16:02:00 -0000 User-Agent: KMail/1.9.10 References: <1240929901.29047.110.camel@dannypc> In-Reply-To: <1240929901.29047.110.camel@dannypc> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200904281702.30473.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-04/txt/msg00759.txt.bz2 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? > 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. 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. -- Pedro Alves