This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: Post mortem debugging for Windows CE
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