Re: How to fix solib path name?

[Pedro Alves <pedro at codesourcery dot com>]

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.

-- 
Pedro Alves