Re: Post mortem debugging for Windows CE

[Danny Backx <danny dot backx at scarlet dot be>]

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