Re: How to fix solib path name?

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

On Wed, 2009-07-08 at 16:07 +0100, Pedro Alves wrote:
> On Wednesday 08 July 2009 15:56:09, Pedro Alves wrote:
> > On Wednesday 08 July 2009 15:34:38, Danny Backx wrote:
> > > I'm preparing a gdb patch so it works in a cross-debugging environment.
> > > Host I'm using is a linux pc, target is running Windows CE Embedded 6.0.
> > > 
> > > The gdbserver part is getting complete, see other messages on this list.
> > > 
> > > The gdb still has a quirck or two.
> > > 
> > > (gdb) info sharedlibrary
> > > >From        To          Syms Read   Shared Object Library
> > >                         No          \network\x86\libgcc_s_sjlj-1.dll
> > > 0x41ee1000  0x41fb2974
> > > Yes         /opt/x86mingw32ce/i386-mingw32ce/lib/libstdc++-6.dll
> > >                         No          \Windows\coredll.dll
> > > (gdb) 
> > > 
> > > I'm guessing that it should strip the \network\x86 from the library name
> > > before it attempts to find it in the solib-search-path.
> > > 
> > 
> > Interesting.  Does this mean that CE6 always reports absolute path
> > names in dll events?  If so, you want to use "set sysroot", not
> > "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'.
> > 
> > You'll have to issue with backslashes on linux though.  I don't
> > remember if GDB head takes care of converting those to forward
> > slashes for you or not.
> > 
> > 
> > Here's what I see when debugging gdbserver with
> > itself on ARM CE 5.0 Pocket PC:
> > 
> > WinMainCRTStartup (hInst=0xf65999ae, hPrevInst=0x0, lpCmdLine=0x2613fed8 L"", nCmdShow=5)
> >     at /home/pedro/cegcc/trunk/cegcc/src/mingw/crt3.c:35
> > 35      {
> > (gdb) info sharedlibrary
> > From        To          Syms Read   Shared Object Library
> >                         No          ws2.dll
> >                         No          coredll.dll.0409.mui
> >                         No          coredll.dll
> > (gdb)  
> > 
> > That is, CE reports relative paths, at least for system dlls.  I'm yet
> > refresh my memory what happens against a non-system dll.
> > 
> 
> Okay, just confirmed it.  It's the same with non-system dlls.
> All reported paths are relative.  Here shreloc2.s and shreloc1.sl
> are both under /tmp, as well as shreloc, the main application.  (this
> is a test from gdb's testsuite).
> 
> (gdb) info sharedlibrary
> >From        To          Syms Read   Shared Object Library
>                         No          shreloc2.sl
>                         No          shreloc1.sl
>                         No          coredll.dll.0409.mui
>                         No          coredll.dll
> (gdb)                         
> 
> So, CE6 behaves differently to CE 5 and lower here.  I'm not that
> surprised, since the memory model on CE6 was completely revamped
> to eliminate the 32MB restrictions.
> 
> 
> Maybe we can make gdbserver smarter even on CE < 6?  I think I
> remember that if you had toolhelp.dll on the device, you'd get
> absolute paths, but I'm not sure if that's a valid memory I have.
> 

I've added one printf statement to gdbserver/server.c just after where
it assembles the library name list.

Output on the infamous C++ hello2.exe below. Two out of the three are
absolute path names. Not sure why the other one isn't.

Is it best to adapt gdbserver for this ?

	Danny

\network\x86> gdbserver :9999 /network/x86/hello2.exe
Process /network/x86/hello2.exe created; pid = 92471306
Listening on port 9999
Remote debugging from host 172.17.1.10
Yow {<library-list>
  <library name="\network\x86\libgcc_s_sjlj-1.dll"><segment
address="0x41fc1000"/></library>
  <library name="libstdc++-6.dll"><segment
address="0x41ee1000"/></library>
  <library name="\Windows\coredll.dll"><segment
address="0x40011000"/></library>
</library-list>
}


pavilion: {108} i386-mingw32ce-gdb hello2.exe
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=i386-mingw32ce"...
(gdb) target remote ebox:9999
Remote debugging using ebox:9999
[New Thread 92536842]
Error while mapping shared library sections:
\network\x86\libgcc_s_sjlj-1.dll: No such file or directory.
Error while mapping shared library sections:
libstdc++-6.dll: No such file or directory.
Error while mapping shared library sections:
\Windows\coredll.dll: No such file or directory.
Symbol file not found for \network\x86\libgcc_s_sjlj-1.dll
Symbol file not found for libstdc++-6.dll
Symbol file not found for \Windows\coredll.dll
WinMainCRTStartup (hInst=0x583000a, hPrevInst=0x0, lpCmdLine=0x2601fc70,
nCmdShow=5)

at /home/danny/src/cegcc/svn.sf.net/cegcc/trunk/cegcc/src/mingw/crt3.c:35
35      {
Current language:  auto; currently c


-- 
Danny Backx ; danny.backx - at - scarlet.be ; http://danny.backx.info