Re: Post mortem debugging for Windows CE

Danny Backx
2009-05-11T15:00:14Z

I had not included material for interested parties to actually do a
little test with.

I won't put such executables on the mailing list, instead I put it up on
my site :
http://danny.backx.info/download/gdb/gdb-minidump-example.tar.gz

The file is 11446 bytes long, and contains :
pavilion: {185} tar tvfz /tmp/gdb-minidump-example.tar.gz
-rw-rw-r-- danny/danny 371 2009-04-28 19:37 examples/callstack.c
-rw-rw-r-- danny/danny 24586 2009-04-30 15:07 examples/callstack.exe
-rw------- danny/danny 11480 2009-04-30 15:01
examples/Ce042809-01.kdmp

This produces output such as :

pavilion: {186} 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) where
#0 0x00011178 in fibo (n=2) at callstack.c:11
#1 0x000111ac in fibo (n=3) at callstack.c:15
#2 0x000111ac in fibo (n=4) at callstack.c:15
#3 0x000111ac in fibo (n=5) at callstack.c:15
#4 0x000111ac in fibo (n=6) at callstack.c:15
#5 0x000111ac in fibo (n=7) at callstack.c:15
#6 0x000111ac in fibo (n=8) at callstack.c:15
#7 0x000111ac in fibo (n=9) at callstack.c:15
#8 0x000111ac in fibo (n=10) at callstack.c:15
#9 0x000111ac in fibo (n=11) at callstack.c:15
#10 0x000111ac in fibo (n=12) at callstack.c:15
#11 0x000111ac in fibo (n=13) at callstack.c:15
#12 0x000111ac in fibo (n=14) at callstack.c:15
#13 0x000111ac in fibo (n=15) at callstack.c:15
#14 0x000111ac in fibo (n=16) at callstack.c:15
#15 0x000111ac in fibo (n=17) at callstack.c:15
#16 0x000111ac in fibo (n=18) at callstack.c:15
#17 0x000111ac in fibo (n=19) at callstack.c:15
#18 0x000111ac in fibo (n=20) at callstack.c:15
#19 0x00011204 in WinMain (a=0x21623686, b=0x0, c=0x2611fed8, d=5) at
callstack.c:22
#20 0x00011134 in WinMainCRTStartup (hInst=0x21623686, hPrevInst=0x0,
lpCmdLine=0x2611fed8,
nCmdShow=5)
at /home/danny/src/cegcc/svn.sf.net/cegcc/trunk/cegcc/src/mingw/crt3.c:62

Hope this helps.

Danny

On Mon, 2009-05-11 at 16:03 +0200, Danny Backx wrote:
> Here is a first cut of my work. Please comment.
>
> Danny
>
> On Sun, 2009-05-10 at 20:21 +0100, Pedro Alves wrote:
> > On Thursday 07 May 2009 02:21:04, Danny Backx wrote:
> > > On Wed, 2009-05-06 at 21:48 +0100, Pedro Alves wrote:
> > > > A few suggestions:
> > > >
> > > > - Please forgive me if you know this already.
> > > > Your minidump bfd code should work on all hosts, 64-bit, 32-bit,
> > > > big endian or little endian. This means that code like:
> > > [..]
> > > > ... is unacceptable. You need to use the bfd_get_32 and friends
> > > > to parse the data on the file.
> > >
> > > I'll start doing all that. I didn't know about avoiding structs so
> > > this'll be some work.
> > >
> > > Should they be avoided completely ? I wrote code like the snippet below.
> > > Should the sizeof (CEDUMP_THREAD_CALL_STACK_LIST) be replaced ? Should
> > > the struct definitions be gone completely, or still be there in
> > > comment ?
> >
> > Take a look at src/include/coff/external.h and
> > src/include/coff/internal.h, or grep for Internal and External
> > in src/include/elf/, or grep for "swap" in bfd. The external variants
> > are the ones that are read out of file. The internal variants
> > are the ones used internally. Presumably, you won't have that much
> > code, so you may chose to always use "external" types, and extract
> > the fields with bfd_get_foo.
> >
> > > Also this'll work for CE based minidumps now, not the ones from desktop
> > > Windows. This may be as simple as getting the code to handle not only
> > > the
> > > ceStreamThreadCallStackList = 0x8007
> > > but also the desktop value. But life is usually not that simple.
> >
> > If this is not useful to you, then you don't have to implement it.
> > I'm sure someone else having an interest in desktop Windows will
> > take of adding such functionality.
> >
> > > rva = minidump_core_locate_stream(abfd, ceStreamThreadCallStackList);
> > > if (bfd_seek (abfd, (file_ptr) rva, SEEK_SET) != 0)
> > > return;
> > > nread = bfd_bread (&tcsl, (bfd_size_type) sizeof
> > > (CEDUMP_THREAD_CALL_STACK_LIST), abfd);
> > > if (nread != sizeof (CEDUMP_THREAD_CALL_STACK_LIST))
> > > {
> > > if (bfd_get_error () != bfd_error_system_call)
> > > bfd_set_error (bfd_error_wrong_format);
> > > return;
> > > }
> > >
> > > /*
> > > * Need to read all the CEDUMP_THREAD_CALL_STACK entries,
> > > * they're just after the CEDUMP_THREAD_CALL_STACK_LIST.
> > > * The CEDUMP_THREAD_CALL_STACK_FRAME fields are in potentially other
> > > places though.
> > > * So allocate space for enough CEDUMP_THREAD_CALL_STACK_LIST entries.
> > > */
> > > sz = tcsl.NumberOfEntries * sizeof(CEDUMP_THREAD_CALL_STACK);
> >
> > Right, this is exactly what you should *not* do. That
> > 'tcsl.NumberOfEntries' field will return garbage if e.g., the
> > host machine running gdb is big endian, while the minidump data
> > is supposedly stored in little endian (ARM). Same for hidden
> > padding the compiler may insert in the structure, influencing
> > the tcsl fields offsets, and the size of the structure in the
> > view of the host.
> >