How to fix solib path name?

How to fix solib path name?

[Danny Backx]

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.

Should it ?

If yes, where should the code for that be ?

Thanks for the help. Once this gets fixed, I can submit that part of my
work too.

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

Re: How to fix solib path name?

[Aleksandar Ristovski]

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.

See solib_find comment in "solib.c" for figuring out how it 
looks for it.

You can provide "find_and_open_solib" in your target_ops for 
customizing it (in case you want to provide "default" search 
algorithm when built-in solib-search-path mechanism fails to 
find it).

> 
> Should it ?
> 
> If yes, where should the code for that be ?
> 
> Thanks for the help. Once this gets fixed, I can submit that part of my
> work too.
> 
> 	Danny


-- 
Aleksandar Ristovski
QNX Software Systems

Re: How to fix solib path name?

[Pedro Alves]

On Wednesday 08 July 2009 15:45:23, Aleksandar Ristovski wrote:
> See solib_find comment in "solib.c" for figuring out how it 
> looks for it.
> 
> You can provide "find_and_open_solib" in your target_ops for 
> customizing it (in case you want to provide "default" search 
> algorithm when built-in solib-search-path mechanism fails to 
> find it).

Please don't go there, it's not really needed.

-- 
Pedro Alves

Re: How to fix solib path name?

[Aleksandar Ristovski]

Pedro Alves wrote:
> On Wednesday 08 July 2009 15:45:23, Aleksandar Ristovski wrote:
>> See solib_find comment in "solib.c" for figuring out how it 
>> looks for it.
>>
>> You can provide "find_and_open_solib" in your target_ops for 
>> customizing it (in case you want to provide "default" search 
>> algorithm when built-in solib-search-path mechanism fails to 
>> find it).
> 
> Please don't go there, it's not really needed.
> 

I thought the mechanism worked quite nicely. For us at least.

If solib-search-path is not set, we end up searching solibs 
using find_and_open_solib.

When solib-search-path is set, then it takes precedence and 
only if solib is not found there, we fallback to 
find_and_open_solib.

What would you do differently?


-- 
Aleksandar Ristovski
QNX Software Systems

Re: How to fix solib path name?

[Pedro Alves]

On Wednesday 08 July 2009 16:14:41, Aleksandar Ristovski wrote:
> Pedro Alves wrote:
> > On Wednesday 08 July 2009 15:45:23, Aleksandar Ristovski wrote:
> >> See solib_find comment in "solib.c" for figuring out how it 
> >> looks for it.
> >>
> >> You can provide "find_and_open_solib" in your target_ops for 
> >> customizing it (in case you want to provide "default" search 
> >> algorithm when built-in solib-search-path mechanism fails to 
> >> find it).
> > 
> > Please don't go there, it's not really needed.
> > 
> 
> I thought the mechanism worked quite nicely. For us at least.
> 
> If solib-search-path is not set, we end up searching solibs 
> using find_and_open_solib.
> 
> When solib-search-path is set, then it takes precedence and 
> only if solib is not found there, we fallback to 
> find_and_open_solib.
> 
> What would you do differently?

Use "(gdb) set sysroot".

-- 
Pedro Alves

Re: How to fix solib path name?

[Aleksandar Ristovski]

Pedro Alves wrote:
> On Wednesday 08 July 2009 16:14:41, Aleksandar Ristovski wrote:
>> Pedro Alves wrote:
>>> On Wednesday 08 July 2009 15:45:23, Aleksandar Ristovski wrote:
>>>> See solib_find comment in "solib.c" for figuring out how it 
>>>> looks for it.
>>>>
>>>> You can provide "find_and_open_solib" in your target_ops for 
>>>> customizing it (in case you want to provide "default" search 
>>>> algorithm when built-in solib-search-path mechanism fails to 
>>>> find it).
>>> Please don't go there, it's not really needed.
>>>
>> I thought the mechanism worked quite nicely. For us at least.
>>
>> If solib-search-path is not set, we end up searching solibs 
>> using find_and_open_solib.
>>
>> When solib-search-path is set, then it takes precedence and 
>> only if solib is not found there, we fallback to 
>> find_and_open_solib.
>>
>> What would you do differently?
> 
> Use "(gdb) set sysroot".
> 

That is for absolute paths. For relative paths 
find_and_open_solib is still a way to go IMHO - if you 
disagree I would like to hear your rationale.


Thanks,

Aleksandar

Re: How to fix solib path name?

[Pedro Alves]

On Wednesday 08 July 2009 16:37:31, Aleksandar Ristovski wrote:

> >> What would you do differently?
> > 
> > Use "(gdb) set sysroot".
> > 
> 
> That is for absolute paths. For relative paths 
> find_and_open_solib is still a way to go IMHO - if you 
> disagree I would like to hear your rationale.

Where would this look?  What benefit does this have over
solib-search-path?  Windows dlls can be everywhere on
the filesystem.

-- 
Pedro Alves

Re: How to fix solib path name?

[Pedro Alves]

On Wednesday 08 July 2009 16:37:31, Aleksandar Ristovski wrote:

> >> What would you do differently?
> > 
> > Use "(gdb) set sysroot".
> > 
> 
> That is for absolute paths. For relative paths 
> find_and_open_solib is still a way to go IMHO - if you 
> disagree I would like to hear your rationale.

Where would this look?  What benefit does this have over
solib-search-path?  Windows dlls can be everywhere on
the filesystem.

-- 
Pedro Alves

Re: How to fix solib path name?

[Aleksandar Ristovski]

Pedro Alves wrote:
> On Wednesday 08 July 2009 16:37:31, Aleksandar Ristovski wrote:
> 
>>>> What would you do differently?
>>> Use "(gdb) set sysroot".
>>>
>> That is for absolute paths. For relative paths 
>> find_and_open_solib is still a way to go IMHO - if you 
>> disagree I would like to hear your rationale.
> 
> Where would this look?  What benefit does this have over
> solib-search-path?  Windows dlls can be everywhere on
> the filesystem.
> 

Our case is cross-debugging with different host 
architectures (win32, linux, nto).

We set sysroot in "architecture_changed" event. We set it 
only if it hasn't been set previously, thus allowing users 
to specify their own.

We used to have solib-search-path "automagically" set which, 
then, gave problems when users wanted to specify their own 
because "set solib-search-path" will replace previously set 
path, forcing users to specify their own + all the default ones.

The solution I ended up with, that made the most sense to 
me, is:

* we set solib-absolute-prefix as described above (and the 
path itself is determined by env. variable and architecture),
* solib-search-path - we don't touch it internally, user can 
specify it if needed in which case default search algorithm 
will take over, whether absolute path was not found in 
sysroot or relative path is specified
* and we have "find_and_open_solib" that will search 
internally built solib-search-path based on the same env. 
variable, architecture and usual paths (e.g. lib, usr/lib 
etc...) using basename of the given path and the search path.


In Danny's case, if he wanted to follow the same scenario, 
he could either not set sysroot or set it to a reasonable 
default (if he doesn't want to use env. var).

find_and_open_solib could use sysroot to build "usual" 
paths, which I presume would be "Windows" and such.

Finally, we don't have the issue of fwd/backward slashes, 
but I think it could be fixed in Danny's case by configuring 
gdb to define HAVE_DOS_BASED_FILE_SYSTEM, or by taking care 
of it in find_and_open_solib.


Anyway... just my two cents.


Thanks,

-- 
Aleksandar Ristovski
QNX Software Systems

Re: How to fix solib path name?

[Pedro Alves]

On Wednesday 08 July 2009 18:15:05, Aleksandar Ristovski wrote:
> Finally, we don't have the issue of fwd/backward slashes, 
> but I think it could be fixed in Danny's case by configuring 
> gdb to define HAVE_DOS_BASED_FILE_SYSTEM,

Defines/macros influencing GDB's view of the *target* are bad (TM).  :-/

> or by taking care  
> of it in find_and_open_solib.

Windows targets use solib-target.c, pretty much agnostic
of Windows, really.


CE's version of explorer doesn't allow creating files with
'/' slashes --- it claims it's an invalid character for a filename.
Not so sure if it's allowed at the filesystem or win32 api
levels though.  We could just punt and make gdbserver do the
translation.  We already do it when creating a
process (win32-low.c:create_process).

BTW, IIRC, CE doesn't have notion of drive letters either ("c:", "d:"), it
has a single rooted filesystem.  Yay for something MSFT did right!

Then there's case sensitivity as well (which could be considered
a filesystem, not target property) ...  I hope that the OS is
reporting the filename exactly as as seen on the filesystem --- which
is what I've been seeing so far.  I think that with other Windows
versions we have a problem here.

-- 
Pedro Alves

Re: How to fix solib path name?

[Pedro Alves]

On Wednesday 08 July 2009 18:15:05, Aleksandar Ristovski wrote:
> Finally, we don't have the issue of fwd/backward slashes, 
> but I think it could be fixed in Danny's case by configuring 
> gdb to define HAVE_DOS_BASED_FILE_SYSTEM,

Defines/macros influencing GDB's view of the *target* are bad (TM).  :-/

> or by taking care  
> of it in find_and_open_solib.

Windows targets use solib-target.c, pretty much agnostic
of Windows, really.


CE's version of explorer doesn't allow creating files with
'/' slashes --- it claims it's an invalid character for a filename.
Not so sure if it's allowed at the filesystem or win32 api
levels though.  We could just punt and make gdbserver do the
translation.  We already do it when creating a
process (win32-low.c:create_process).

BTW, IIRC, CE doesn't have notion of drive letters either ("c:", "d:"), it
has a single rooted filesystem.  Yay for something MSFT did right!

Then there's case sensitivity as well (which could be considered
a filesystem, not target property) ...  I hope that the OS is
reporting the filename exactly as as seen on the filesystem --- which
is what I've been seeing so far.  I think that with other Windows
versions we have a problem here.

-- 
Pedro Alves

Re: How to fix solib path name?

[Pedro Alves]

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.

-- 
Pedro Alves

Re: How to fix solib path name?

[Pedro Alves]

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

Re: How to fix solib path name?

[Danny Backx]

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

Re: How to fix solib path name?

[Danny Backx]

[-- Attachment #1: Type: text/plain, Size: 3354 bytes --]

On Wed, 2009-07-08 at 17:31 +0200, Danny Backx wrote:
> On Wed, 2009-07-08 at 16:07 +0100, Pedro Alves wrote:
> > 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 ?

If the answer to my question is yes, then it's not a hard fix. It's
attached.

2009-07-08  Danny Backx  <dannybackx@users.sourceforge.net>

	* server.c : Strip path from DLL names.


Result is below. (Initial spooky messages due to gdb reading the wrong
directory to find the DLL. The i386 gdb tried to read an ARM dll.)

	Danny

pavilion: {109} 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 68419598]
Error while mapping shared library sections:
"/opt/mingw32ce/bin/libgcc_s_sjlj-1.dll": not in executable format: File
format not recognized.
Error while mapping shared library sections:
libstdc++-6.dll: No such file or directory.
Error while mapping shared library sections:
coredll.dll: No such file or directory.
Error while reading shared library symbols:
"/opt/mingw32ce/bin/libgcc_s_sjlj-1.dll": can't read symbols: File
format not recognized.
Symbol file not found for libstdc++-6.dll
Symbol file not found for coredll.dll
WinMainCRTStartup (hInst=0x407000e, hPrevInst=0x0, lpCmdLine=0x2a01fc70,
nCmdShow=5)

at /home/danny/src/cegcc/svn.sf.net/cegcc/trunk/cegcc/src/mingw/crt3.c:35
35      {
Current language:  auto; currently c
(gdb) info sharedlibrary
From        To          Syms Read   Shared Object Library

No          /opt/mingw32ce/bin/libgcc_s_sjlj-1.dll
                        No          libstdc++-6.dll
                        No          coredll.dll
(gdb) set
solib-search-path /opt/x86mingw32ce/bin:/opt/x86mingw32ce/i386-mingw32ce/lib:/opt/x86mingw32ce/i386-mingw32ce/bin
Error while mapping shared library sections:
coredll.dll: No such file or directory.
Reading symbols from /opt/x86mingw32ce/bin/libgcc_s_sjlj-1.dll...done.
Loaded symbols for /opt/x86mingw32ce/bin/libgcc_s_sjlj-1.dll
Reading symbols from /opt/x86mingw32ce/i386-mingw32ce/lib/libstdc
++-6.dll...done.
Loaded symbols for /opt/x86mingw32ce/i386-mingw32ce/lib/libstdc++-6.dll
Symbol file not found for coredll.dll
(gdb) info sharedlibrary
From        To          Syms Read   Shared Object Library
0x41fc1000  0x41fcc1fc
Yes         /opt/x86mingw32ce/bin/libgcc_s_sjlj-1.dll
0x41ee1000  0x41fb2974
Yes         /opt/x86mingw32ce/i386-mingw32ce/lib/libstdc++-6.dll
                        No          coredll.dll










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

[-- Attachment #2: x --]
[-- Type: text/x-patch, Size: 970 bytes --]

Index: server.c
===================================================================
RCS file: /cvs/src/src/gdb/gdbserver/server.c,v
retrieving revision 1.102
diff -u -r1.102 server.c
--- server.c	30 Jun 2009 16:35:25 -0000	1.102
+++ server.c	8 Jul 2009 15:43:37 -0000
@@ -929,14 +929,24 @@
       for (dll_ptr = all_dlls.head; dll_ptr != NULL; dll_ptr = dll_ptr->next)
 	{
 	  struct dll_info *dll = (struct dll_info *) dll_ptr;
-	  char *name;
+	  char *name, *lastdir, *q;
 
 	  strcpy (p, "  <library name=\"");
 	  p = p + strlen (p);
 	  name = xml_escape_text (dll->name);
-	  strcpy (p, name);
+
+	  /* Strip directory names */
+	  lastdir = 0;
+	  for (q=name; *q; q++)
+	    if (*q == '\\' || *q == '/')
+	      lastdir = q;
+	  if (lastdir)
+	    strcpy(p, lastdir+1);
+	  else
+	    strcpy (p, name);
 	  free (name);
 	  p = p + strlen (p);
+
 	  strcpy (p, "\"><segment address=\"");
 	  p = p + strlen (p);
 	  sprintf (p, "0x%lx", (long) dll->base_addr);

Re: How to fix solib path name?

[Pedro Alves]

On Wednesday 08 July 2009 16:45:31, Danny Backx wrote:
> On Wed, 2009-07-08 at 17:31 +0200, Danny Backx wrote:
> > On Wed, 2009-07-08 at 16:07 +0100, Pedro Alves wrote:
> > > 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 ?
> 
> If the answer to my question is yes, then it's not a hard fix. It's
> attached.

No, that's the wrong direction.  Absolute paths are better.  I'd
rather we make a better effort at finding the pathname in the cases we
don't know them.

Losing information like this is never good.  At most, we could add a
knob to gdb to ignore the path information and look at the filename
only.

But, please, let's not go around and around, when I suggested "set sysroot"
several times already.  Did you actually try that?  Please do,
before posting more patches.

-- 
Pedro Alves

Re: How to fix solib path name?

[Danny Backx]

On Wed, 2009-07-08 at 16:57 +0100, Pedro Alves wrote:
> But, please, let's not go around and around, when I suggested "set sysroot"
> several times already.  Did you actually try that?  Please do,
> before posting more patches.

Sure. Just did. I don't see it affecting the "info sharedlibrary" report
though. I am probably doing something wrong. Is this functionality
supposed to strip the path off my libraries when it looks ? Or must the
directory structure in that sysroot match the directory structure on the
CE device ?


> > 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.
> 
> Heh.  That's the same dll you have issues with when reading
> it's filename, and also the one where you have that test app
> crashing, isn't it?  :-)  Where (which dir) in the device is
> it located?  Does it change anything if you put it next to
> the others, in case it isn't already?

Yes, that's the same DLL I'm having trouble with.

You ask where everything is.
The coredll.dll is in \windows , that's on the device.

The other two are on my PC in /home/danny/x86 :
pavilion: {64} ls -l /home/danny/x86/
total 2648
-rw-rw-r-- 1 danny danny  24852 2009-06-01 15:00 coredll.def
-rw-rw-r-- 1 danny danny   2459 2009-06-01 15:16 crypt32.def
-rw-rw-r-- 1 danny danny     29 2009-05-31 14:27 demodll.def
-rwxrwxr-x 1 danny danny  65463 2009-07-01 21:07 demodll.dll
-rwxrwxr-x 1 danny danny  24041 2009-07-01 22:07 dll.dll
-rw-rw-r-- 1 danny danny     90 2009-06-08 20:22 doit.bat
-rwxrwxr-x 1 danny danny  25058 2009-06-19 22:06 dynload.exe-
-rwxrwxr-x 1 danny danny  63008 2009-07-01 21:07 fail.dll
-rwxrwxr-x 1 danny danny  24043 2009-07-06 21:53 fibo.exe
-rwxrwxr-x 1 danny danny 374335 2009-07-08 18:07 gdbserver.exe
-rwxrwxr-x 1 danny danny  55666 2009-07-08 09:43 hello2.exe
-rwxrwxr-x 1 danny danny  56178 2009-07-07 22:03 hello.exe
-rwxr-xr-x 1 danny danny 388471 2009-05-31 11:20 libexpat-1.dll
-rwxr-xr-x 1 danny danny 227857 2009-06-17 21:42 libgcc_s_sjlj-1.dll
-rwxr-xr-x 1 danny danny  53751 2009-06-04 20:56 libssp-0.dll
-rwxrwxr-x 1 danny danny 845824 2009-06-25 23:18 libstdc++-6.dll
-rwxr-xr-x 1 danny danny  28355 2009-06-04 20:56 mingwm10.dll
-rwxrwxr-x 1 danny danny 374335 2009-07-08 10:23 ogdbs.exe
pavilion: {65} 

which is mounted on the ebox on \network\x86 :

\network\x86> net use
Connected resources:

Status        Local Name             Remote Name
--------------------------------------------------------------------
Connected     x86                    \\pavilion\dannyx86
Connected     (null)                 \\PAVILION\IPC$ 
Command completed successfully
\network\x86> 

so when gdb reports :
(gdb) info sharedlibrary
From        To          Syms Read   Shared Object Library
0x41fc1000  0x41fcc1fc
Yes         /opt/x86mingw32ce/bin/libgcc_s_sjlj-1.dll
0x41ee1000  0x41fb2974
Yes         /opt/x86mingw32ce/i386-mingw32ce/lib/libstdc++-6.dll
                        No          coredll.dll
(gdb) s

then the two DLLs it reports in /opt are actually next to each other in
the device (in \network\x86). The ones in /opt are the ones I copied to
the ~/x86 -> \network\x86 .

So, bottom line : I don't think the directory has anything to do with it
because the executable and the two non-system DLLs are sitting in the
same directory.

	Danny

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

Re: How to fix solib path name?

[Pedro Alves]

On Wednesday 08 July 2009 17:18:46, Danny Backx wrote:

> Sure. Just did. I don't see it affecting the "info sharedlibrary" report
> though. I am probably doing something wrong. Is this functionality
> supposed to strip the path off my libraries when it looks ? Or must the
> directory structure in that sysroot match the directory structure on the
> CE device ?

The latter.  http://sourceware.org/gdb/onlinedocs/gdb_16.html#IDX749

> The coredll.dll is in \windows , that's on the device.
> 
> The other two are on my PC in /home/danny/x86 :
> pavilion: {64} ls -l /home/danny/x86/

> -rwxr-xr-x 1 danny danny 227857 2009-06-17 21:42 libgcc_s_sjlj-1.dll
> -rwxrwxr-x 1 danny danny 845824 2009-06-25 23:18 libstdc++-6.dll

Group permissions are different, but this *probably* shouldn't
affect this.  Wild guess, could all these issues be related
to '+''s in the filename?

> So, bottom line : I don't think the directory has anything to do with it
> because the executable and the two non-system DLLs are sitting in the
> same directory.

Mystifying.  Something must be different.  Maybe there's a
"rand()" call in the kernel somewhere.  :-)

-- 
Pedro Alves

Re: How to fix solib path name?

[Pedro Alves]

On Wednesday 08 July 2009 16:31:13, Danny Backx wrote:
> 
> > 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.

Heh.  That's the same dll you have issues with when reading
it's filename, and also the one where you have that test app
crashing, isn't it?  :-)  Where (which dir) in the device is
it located?  Does it change anything if you put it next to
the others, in case it isn't already?

> Is it best to adapt gdbserver for this ?

I don't know what you mean by adapt here.  The point of absolute
pathnames is that you can have more than one dll with the
same name around, so gdb doesn't have to guess which is which.
Why not just use "set sysroot"?

-- 
Pedro Alves

Re: How to fix solib path name?

[Pedro Alves]

Going back to the previous hints, and answering myself:

On Wednesday 08 July 2009 15:56:09, Pedro Alves wrote:
> >                         No          \Windows\coredll.dll

On Wednesday 08 July 2009 15:56:09, Pedro Alves wrote:
> 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.
> 

This bit of code in solib.c:solib_find appears to indicate that
if the dll isn't found in the sysroot, then it should be found in
the solib-search-path:

  /* If not found, next search the solib_search_path (if any) for the basename
     only (ignoring the path).  This is to allow reading solibs from a path
     that differs from the opened path.  */
  if (found_file < 0 && solib_search_path != NULL)
    found_file = openp (solib_search_path, OPF_TRY_CWD_FIRST,
                        lbasename (in_pathname), O_RDONLY | O_BINARY,
                        &temp_pathname);


but, lbasename on a linux box isn't considering '\' a path separator.

-- 
Pedro Alves

Re: How to fix solib path name?

[Danny Backx]

On Wed, 2009-07-08 at 17:42 +0100, Pedro Alves wrote:
> Going back to the previous hints, and answering myself:
> 
> On Wednesday 08 July 2009 15:56:09, Pedro Alves wrote:
> > >                         No          \Windows\coredll.dll
> 
> On Wednesday 08 July 2009 15:56:09, Pedro Alves wrote:
> > 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.
> > 
> 
> This bit of code in solib.c:solib_find appears to indicate that
> if the dll isn't found in the sysroot, then it should be found in
> the solib-search-path:
> 
>   /* If not found, next search the solib_search_path (if any) for the basename
>      only (ignoring the path).  This is to allow reading solibs from a path
>      that differs from the opened path.  */
>   if (found_file < 0 && solib_search_path != NULL)
>     found_file = openp (solib_search_path, OPF_TRY_CWD_FIRST,
>                         lbasename (in_pathname), O_RDONLY | O_BINARY,
>                         &temp_pathname);
> 
> 
> but, lbasename on a linux box isn't considering '\' a path separator.

The combination of sysroot and solib-search-path *and* a fix to turn '\'
into '/' inside gdbserver does the trick.

Should that translation then be put in gdbserver ? Are such details of
the gdb/gdbserver protocol documented at all ?

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