This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Post mortem debugging for Windows CE


On Wednesday 06 May 2009 15:12:10, Danny Backx wrote:
> After a good deal of actually using gdb to debug itself (as I did a lot
> in these days), 

Welcome to the club.  :-)

> here is where I am at : 
> 
> dannypc: {1013} gdb/gdb examples/callstack.exe examples/Ce042809-01.kdmp
> GNU gdb 6.8

 ^^^ you'll need to move to CVS gdb at some point.  GDB's been changing
a lot since 6.8, but, I don't think you'll be much affected.

> 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 ?

Looking very good.  I had a vague memory that WinCE gdbserver reports
absolute dlls paths when doing live debugging.  Does it not?  What
does "info sharedlibrary" say when doing live debugging?

When paths are reported as relative (coredll.dll vs
/Windows/coredll.dll), then pointing gdb at a local host copy
of dlls with the 'set sysroot' command doesn't help.  You'll
need 'set solib-search-path'.

 (gdb) help set sysroot
 Set an alternate system root.
 The system root is used to load absolute shared library symbol files.
 For other (relative) files, you can add directories using
 `set solib-search-path'.

 (gdb) help set solib-search-path
 Set the search path for loading non-absolute shared library symbol files.
 This takes precedence over the environment variables PATH and LD_LIBRARY_PATH.

[ coredll.dll can't be (easilly) extracted from ROM, but, you're not
expected to debug coredll.dll anyway. ]

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

Completely untested, but something as simple as this?

bad.c:
int crashme (int *foofoo)
{
  return *foofoo;
}

arm-mingw32ce-gcc bad.c -o bad.dll -O0 -g3 -shared

main.c:
int main()
{
   crashme (NULL);
}

arm-mingw32ce-gcc main.c -o main.exe -O0 -g3 -L. -lbad

?

BTW, does "info threads" show the correct list of threads?

-- 
Pedro Alves


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]