Re: Post mortem debugging for Windows CE

[Danny Backx <danny.backx@scarlet.be>]

After a good deal of actually using gdb to debug itself (as I did a lot
in these days), here is where I am at :

dannypc: {1013} gdb/gdb examples/callstack.exe examples/Ce042809-01.kdmp
GNU gdb 6.8
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show
copying"
and "show warranty" for details.
This GDB was configured as "--host=i686-pc-linux-gnu
--target=arm-mingw32ce"...

warning: exec file is newer than core file.
Error while mapping shared library sections:
coredll.dll.0409.mui: No such file or directory.
Error while mapping shared library sections:
coredll.dll: No such file or directory.
Symbol file not found for coredll.dll.0409.mui
Symbol file not found for coredll.dll
Core was generated by `callstack'.
Program terminated with signal 11, Segmentation fault.
[New process 594225230]
#0  0x00011178 in fibo (n=2) at callstack.c:11
11                      return *i;
(gdb) info sharedlibrary 
From        To          Syms Read   Shared Object Library
                        No          coredll.dll.0409.mui
                        No          coredll.dll
(gdb) 

It doesn't print from- and to-addresses in this example. I believe that
this is because solib_map_sections can't read the DLL files (they're
target DLLs from Windows CE, I don't have them on my host). So it fails
in :
  scratch_chan = solib_open (filename, &scratch_pathname);

  if (scratch_chan < 0)
    {
      perror_with_name (filename);
    }

Am I right in concluding that this is the way it should work ?

Does anyone have tricks to produce some fake DLL file for this type of
scenario ?

	Danny


On Tue, 2009-05-05 at 17:53 +0100, Pedro Alves wrote:
> On Tuesday 05 May 2009 14:30:51, Danny Backx wrote:
> 
> > It looks like I'm getting close to something that works. Small session
> > below. Cleanup and more testing are certainly required.
> 
> This is looking very good!
> 
> > I'm about to look into your suggestion about .module sections.
> > 
> > How can I observe the effect of that ? How can I test ?
> 
> The .modules sections would contain the list of loaded modules
> at the time of the crash.  So, 'info sharedlibrary' should list the same
> list of dlls as the live inferior had, and their load addresses should
> be the same.
> 
> You could tweak your test app to move the crashing code into a mini
> dll you'd write.  Use 'set sysroot' or 'set solib-search-path' command to
> point GDB at the host copy of the dll, and load the minidump
> into GDB.  GDB should be able to show you the crash site source code,
> backtracing from the function in  the dll should work, and
> 'info sharedlibrary' should report correct data, of course.
> 
-- 
Danny Backx ; danny.backx - at - scarlet.be ; http://danny.backx.info