Project Home
Project Home		 Source Code
Source Code		 Documents
Documents		 Wiki
Wiki		 Discussion Forums
Discussions		 Project Information
Project Info
Core Development Tools/Discussion/General/nto-gdb-6.7-u5 solib-search-path issues/List of Posts
Forum Topic - nto-gdb-6.7-u5 solib-search-path issues: (7 Items)
   
Update
dave carlson(deleted)
03/11/2008 9:21 AM
post5687
nto-gdb-6.7-u5 solib-search-path issues   
Using GCC4.2.1, I am having trouble getting the solib search path to be "right".  I am using the same .gdbinit set solib
-search-path I used with gdb 5.2.1 but am getting different results.

1.  The solib-search-path is not set startup read of .gdbinit.  A default path is present (as if I had started -nx).

I do have a /cygdrive/c path in my solib-search-path.  If cygwin paths are not supported, what is the syntax for C:/
QNX630 search paths when gdb uses ":" as a path seperator?

2.  warning: Host file C:/QNX630/target/qnx6/armle/usr/lib/ldqnx.so.2 does not match target file /usr/lib/ldqnx.so.2

I am having a devil of a time getting gdb to "know" that our local relinked libc.so is in fact ldqnx.so.2 on our target 
and that pulling symbols from C:/QNX630 is "wrong".  Since the C:/QNX630 path does not exist in my solib-search-path, 
some system default is overriding the as-set solib-search-path.

Some of my binaries load shared libs from 8 different paths, so a working solib-search-path is required.  :-)

Thanks in advance.
Aleksandar Ristovski(deleted)
03/11/2008 9:29 AM
post5688
Re: nto-gdb-6.7-u5 solib-search-path issues   
dave carlson wrote:
> Using GCC4.2.1, I am having trouble getting the solib search path to be "right".  I am using the same .gdbinit set 
solib-search-path I used with gdb 5.2.1 but am getting different results.
>
> 1.  The solib-search-path is not set startup read of .gdbinit.  A default path is present (as if I had started -nx).
gdb will reset solib-search-path once "target qnx" is issued. This is how it used to work forever. In 5.2.1, though, it 
used to have some hard-coded defaults, but in 6.7 it doesn't.

>
> I do have a /cygdrive/c path in my solib-search-path.  If cygwin paths are not supported, what is the syntax for C:/
QNX630 search paths when gdb uses ":" as a path seperator?
Correct, /cygdrive/c path for does not mean anything to gdb 6.7. Use forward slashed windows path and windows path 
separator (';'), e.g. C:/Foo;C:/Bar...
>
> 2.  warning: Host file C:/QNX630/target/qnx6/armle/usr/lib/ldqnx.so.2 does not match target file /usr/lib/ldqnx.so.2
>
> I am having a devil of a time getting gdb to "know" that our local relinked libc.so is in fact ldqnx.so.2 on our 
target and that pulling symbols from C:/QNX630 is "wrong".  Since the C:/QNX630 path does not exist in my solib-search-
path, some system default is overriding the as-set solib-search-path.
Have you copied your <target>/lib/libc.so.2 over <target>/usr/lib/ldqnx.so.2 ?

>
> Some of my binaries load shared libs from 8 different paths, so a working solib-search-path is required.  :-)

Are you using IDE? If yes, use IDE setting in debug dialog (under Debugger tab).

If not, in your init file set solib-search-path and solib-absolute-prefix AFTER the target qnx .....
Aleksandar Ristovski(deleted)
03/11/2008 9:43 AM
post5690
Re: nto-gdb-6.7-u5 solib-search-path issues   
> Have you copied your <target>/lib/libc.so.2 over <target>/usr/lib/ldqnx.so.2 ?

Just to clarify: copy your host side libc.so.2 (the relinked one) over your host side <target>/usr/lib/ldqnx.so.2  

e.g. 

copy C:\QNX632\target\qnx6\<cpu>\lib\libc.so.2 C:\QNX632\target\qnx6\<cpu>\usr\lib\ldqnx.so.2

On your target, you will have softlink ldqnx.so.2 -> libc.so.2, that is how it's supposed to be. 

In addition, check your QNX_HOST and QNX_TARGET environment variables, they should point to existing directories.

e.g.
QNX_HOST=C:/QNX632/host/win32/x86
QNX_TARGET=C:/QNX632/target/qnx6
dave carlson(deleted)
03/13/2008 11:16 AM
post5783
Re: nto-gdb-6.7-u5 solib-search-path issues   
I have an solib-search-path in my .gdbinit.  I have converted to ';'/forward slash as you recommend above.  I have the 
same problem with search path being reset.  I have NO "target qnx" in my .gdbinit.  I am looking at a core, sso that 
would not make a lot of sense anyway.

From the command line:
 ntoarm-gdb bsp/rev2/bin/symbols/io-net io-net.core
GNU gdb 6.7 qnx-nto (rev. 104)
Copyright (C) 2007 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=i386-mingw32msvc --target=arm-unknown-nto-qnx6.3.2"...
Reading symbols from C:/QNX630/target/qnx6/armle/lib/libecpp-ne.so.4...done.
Loaded symbols for C:/QNX630/target/qnx6/armle/lib/libecpp-ne.so.4
Reading symbols from C:/QNX630/target/qnx6/armle/lib/libc.so.2...done.
*** WRONG *** should have found my libc earlier on the solib path ***
Loaded symbols for C:/QNX630/target/qnx6/armle/lib/libc.so.2
Symbol file not found for devn-smc9000.so
Setting Dynamic-Linker Breakpoint based on C:/QNX630/target/qnx6/armle/usr/lib/ldqnx.so.2
#0  0x0103f23c in _resmgr_io_handler ()
   from C:/QNX630/target/qnx6/armle/lib/libc.so.2  
(gdb)
warning: exec file is newer than core file.
Error while mapping shared library sections:
devn-smc9000.so: No such file or directory.

warning: Host file C:/QNX630/target/qnx6/armle/usr/lib/ldqnx.so.2 does not match target file /usr/lib/ldqnx.so.2
show solib-search-path
The search path for loading non-absolute shared library symbol files is (null);C:/QNX630/target/qnx6/armle/lib;C:/QNX630
/target/qnx6/armle/usr/lib.
 
NOTE: my gdbinit path was reset to default as indicated in my early post.  Since it found "your" libc.so.2, it was reset
 before using my solib-path for the session.

***** run with no command line args *******
ntoarm-gdb 
GNU gdb 6.7 qnx-nto (rev. 104)
Copyright (C) 2007 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=i386-mingw32msvc --target=arm-unknown-nto-qnx6.3.2".
(gdb) show solib-search-path
The search path for loading non-absolute shared library symbol files is bsp/rev2/lib/symbols;bsp/rev2/bin/symbols;
platform/bin;foo/fee/bin/symbols;foo/fum/bin/symbols;foo/fom/bin/symbols;C:/QNX630/target/qnx6/armle/lib.
(gdb)

Now the solib-search-path from my .gdbinit "works".
Aleksandar Ristovski(deleted)
03/13/2008 11:32 AM
post5784
RE: nto-gdb-6.7-u5 solib-search-path issues   
Any 'target' will cause our gdb to override solib-absolute-prefix and
solib-search-path. Core is also a target: 'target core'. Overriding was
implemented in our gdb 5.2.1 and is still in gdb 6.7 (nto) for compatibility
reasons. However, you should be able to do what you want fairly easily (in
theory):

a) start with no cmd line args
b) (gdb) file <your file>
c) (gdb) target core <your core file>
this overrides solib-search-path
d) (gdb) show solib-search-path
e) (gdb) set solib-search-path <put your search-path here, appending system
solib search paths>
it should cause symbols to get reloaded and correct libraries found.
dave carlson(deleted)
03/14/2008 10:30 AM
post5811
Re: RE: nto-gdb-6.7-u5 solib-search-path issues   
So, the answer is:

.gdbinit file cannot be used to initialize a solib-search-path because it we be reset before being used.

Workaround:  manually cut-n-paste your gdbinit into your gdb session after loading the target.

Kinda Lame.
Aleksandar Ristovski(deleted)
03/14/2008 10:33 AM
post5812
RE: RE: nto-gdb-6.7-u5 solib-search-path issues   
> 
> Kinda Lame.

Yeah... I agree. I don't like the fact that we silently override settings. 

We will definitely address this.

Thanks,

Aleksandar

Return


  A subsidiary of BlackBerry             All content ©2004-2013, QNX Software Systems