symbol files and source files of shared objects when debugging remote target

Hello,
 
I'm debugging a remote target using gdb/gdbserver.
 
This procedure works fine for the source files included in
the program
symbol table. However, I cannot step into functions included
in a shared
library. The 'directory' command does not help in this
situation.

BTW, when trying to step into the functions locally (with
same files) it
works fine.

I'm using gdb/gdbserver (front end is insight)  6.5.

Regards,

Avi

On Tue, Dec 12, 2006 at 01:36:16PM +0200, Avi Gozlan wrote:
> Hello,
>  
> I'm debugging a remote target using gdb/gdbserver.
>  
> This procedure works fine for the source files included
in the program
> symbol table. However, I cannot step into functions
included in a shared
> library. The 'directory' command does not help in this
situation.

Does info shared work?  Did you set
"solib-absolute-prefix" or
"solib-search-path" to find the shared libraries
on your host system?

-- 
Daniel Jacobowitz
CodeSourcery

Thanks. I managed to have the symbols loaded using
"solib-search-path".
However I encountered several issues as follows:

1) I succeeded steping into a function defined in one of my
shared
libraries. However, when I tried to step into another one I
got the
following message:

0x007c5050 in __nss_protocols_lookup () from
/lib/tls/libc.so.6

It is worth mentioning the stepping into the second function
involved
stepping into another function whose symboles were not
loaded. Also it is
maybe worth mentioning that libc.so.6 in the target system
is different from
libc.so.6 on the host system.

2) When I run 'set solib-search-path path' on the host, I
get the following
warning several times on the target:

gdb: error initializing thread_db library: version mismatch
between
libthread_db and libpthread.

By the way, when the program symbol file loads, I get the
following message:
Using host libthread_db library
"/lib/tls/libthread_db.so.1"
But when running "info share" I don't see
libthread_db.so.1 but rather
/lib/tls/libpthread.so.0

I'm using gdb and gdbserver of version 6.5. Both are
configured and compiled
for i686-pc-linux-gnu. Both the host and target are Linux
2.4.21

3) Why it is necessary to run 'set solib-search-path' only
after the program
enters user entry point? Running it beforehand left the so
symbols unloaded.
The implication is that the command cannot be executed
during gdb
initialization (e.g. in ini file).

Regards,

Avi

-----Original Message-----
From: Daniel Jacobowitz [mailto:drowfalse.org] 
Sent: Tuesday, December 12, 2006 4:45 PM
To: Avi Gozlan
Cc: gdbsourceware.org
Subject: Re: symbol files and source files of shared objects
when debugging
remote target

On Tue, Dec 12, 2006 at 01:36:16PM +0200, Avi Gozlan wrote:
> Hello,
>  
> I'm debugging a remote target using gdb/gdbserver.
>  
> This procedure works fine for the source files included
in the program 
> symbol table. However, I cannot step into functions
included in a 
> shared library. The 'directory' command does not help
in this situation.

Does info shared work?  Did you set
"solib-absolute-prefix" or
"solib-search-path" to find the shared libraries
on your host system?

--
Daniel Jacobowitz
CodeSourcery

On Thu, Dec 21, 2006 at 02:40:23PM +0200, Avi Gozlan wrote:
> 2) When I run 'set solib-search-path path' on the host,
I get the following
> warning several times on the target:
> 
> gdb: error initializing thread_db library: version
mismatch between
> libthread_db and libpthread.

Then it is very likely you are pointed at the wrong
libraries.

> By the way, when the program symbol file loads, I get
the following message:
> Using host libthread_db library
"/lib/tls/libthread_db.so.1"
> But when running "info share" I don't see
libthread_db.so.1 but rather
> /lib/tls/libpthread.so.0

That's unrelated.

> 3) Why it is necessary to run 'set solib-search-path'
only after the program
> enters user entry point? Running it beforehand left the
so symbols unloaded.
> The implication is that the command cannot be executed
during gdb
> initialization (e.g. in ini file).

Try using solib-absolute-prefix.  It probably found the
wrong ld.so.

-- 
Daniel Jacobowitz
CodeSourcery