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

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

[Avi Gozlan]

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

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

[Daniel Jacobowitz]

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

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

[Avi Gozlan]

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:drow@false.org] 
Sent: Tuesday, December 12, 2006 4:45 PM
To: Avi Gozlan
Cc: gdb@sourceware.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

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

['Daniel Jacobowitz']

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