Remote debugging and dynamic libraries

Remote debugging and dynamic libraries

[frank]

Hello,

i'm trying to remote debug a program running on an arm system running
linux but i ran into various problems. If i interrupt the
debugged program i can't get symbolic information where it stopped.
Also backtraces don't seem to work.

frank@linux:~/> /usr/local/bin/arm-linux-gdb
GNU gdb 6.3
This GDB was configured as "--host=i686-pc-linux-gnu --target=arm-linux".
(gdb) target remote 192.168.1.133:5555
Remote debugging using 192.168.1.133:5555
0x400028b0 in ?? ()
(gdb) symbol-file test
Reading symbols from /home/frank/test...done.
(gdb) l
1       int main() {
2               while(1)
3               {
4                       printf("bla");
5
6               }
7
8       }
(gdb) b 1
Breakpoint 1 at 0x8428: file main.c, line 1.
(gdb) c
Continuing.

Breakpoint 1, main () at main.c:1
1       int main() {
(gdb) n
2               while(1)
(gdb) n
4                       printf("bla");
(gdb) n
0x0000832c in ?? ()
(gdb) n
Cannot find bounds of current function
(gdb)
Cannot find bounds of current function
(gdb) bt
#0  0x0000832c in ?? ()
(gdb)

When test is statically linked everything works
as expected:

frank@linux:~/uclibc_kram/apdf> /usr/local/bin/arm-linux-gdb
GNU gdb 6.3
This GDB was configured as "--host=i686-pc-linux-gnu --target=arm-linux".
(gdb) target remote 192.168.1.133:5555
Remote debugging using 192.168.1.133:5555
Couldn't establish connection to remote target
Remote communication error: Connection reset by peer.
(gdb) target remote 192.168.1.133:5555
Remote debugging using 192.168.1.133:5555
0x000080e0 in ?? ()
(gdb) symbol-file test
Reading symbols from /home/frank/uclibc_kram/apdf/test...done.
(gdb) l
1       int main() {
2               while(1)
3               {
4                       printf("bla");
5
6               }
7
8       }
(gdb) c
Continuing.

Program received signal SIGINT, Interrupt.
0x000282b4 in write ()
(gdb) bt
#0  0x000282b4 in write ()
#1  0x00025bd0 in _IO_new_file_write ()
#2  0x0002513c in new_do_write ()
#3  0x00025084 in _IO_new_do_write ()
#4  0x000254ac in _IO_new_file_overflow ()
#5  0x00025d10 in _IO_new_file_xsputn ()
#6  0x0001a2e0 in vfprintf ()
#7  0x000088b0 in printf ()
#8  0x000081ec in main () at main.c:4

Therefore i tried to set a path for the
dynamic libraries but neither:

1)
   set solib-absolute-prefix /usr/local/arm/arm-linux/
nor:
2)
set solib-absolute-prefix /dev/null
set solib-search-path /usr/local/arm/arm-linux/lib

had any effect.

Any ideas how i can fix this?

Regards,
  Frank

Re: Remote debugging and dynamic libraries

[Daniel Jacobowitz]

Sorry for the duplicate, fat-fingered the list address last time.

On Thu, Oct 27, 2005 at 10:52:00AM +0200, frank@betaversion.net wrote:
> Hello,
> 
> i'm trying to remote debug a program running on an arm system running
> linux but i ran into various problems. If i interrupt the
> debugged program i can't get symbolic information where it stopped.
> Also backtraces don't seem to work.
> 
> frank@linux:~/> /usr/local/bin/arm-linux-gdb
> GNU gdb 6.3
> This GDB was configured as "--host=i686-pc-linux-gnu --target=arm-linux".
> (gdb) target remote 192.168.1.133:5555
> Remote debugging using 192.168.1.133:5555
> 0x400028b0 in ?? ()
> (gdb) symbol-file test

Don't do this.  Use "file", not "symbol-file".

Can you tell me where you found anything which suggested that you
should use symbol-file?  This bug is reported several times a year, and
I still don't know where the incorrect documentation is - I don't think
it's part of GDB.

Without an "exec file" loaded, which symbol-file does not do, GDB won't
find the dynamic loader or be able to load shared libraries.

> 1)
>    set solib-absolute-prefix /usr/local/arm/arm-linux/

This is the correct way - IFF the directory under that path looks like
a root filesystem.  If it's laid out like an old-style cross toolchain,
this may not work.  Paths should match the paths on the target.

> nor:
> 2)
> set solib-absolute-prefix /dev/null
> set solib-search-path /usr/local/arm/arm-linux/lib

This is not the correct way nowadays.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: Remote debugging and dynamic libraries

[Frank Meerkoetter]

Daniel Jacobowitz wrote:

>>i'm trying to remote debug a program running on an arm system running
>>linux but i ran into various problems. If i interrupt the
>>debugged program i can't get symbolic information where it stopped.
>>Also backtraces don't seem to work.
>>
>>frank@linux:~/> /usr/local/bin/arm-linux-gdb
>>GNU gdb 6.3
>>This GDB was configured as "--host=i686-pc-linux-gnu --target=arm-linux".
>>(gdb) target remote 192.168.1.133:5555
>>Remote debugging using 192.168.1.133:5555
>>0x400028b0 in ?? ()
>>(gdb) symbol-file test
>>    
>>
>
>Don't do this.  Use "file", not "symbol-file".
>
>Can you tell me where you found anything which suggested that you
>should use symbol-file?  This bug is reported several times a year, and
>I still don't know where the incorrect documentation is - I don't think
>it's part of GDB.
>  
>
You're right. I picked it up in some mailinglist archive while searching for
a solution to my problem.

>Without an "exec file" loaded, which symbol-file does not do, GDB won't
>find the dynamic loader or be able to load shared libraries.
>  
>
>>1)
>>   set solib-absolute-prefix /usr/local/arm/arm-linux/
>>    
>>
>
>This is the correct way - IFF the directory under that path looks like
>a root filesystem.  If it's laid out like an old-style cross toolchain,
>this may not work.  Paths should match the paths on the target.
>  
>
I gave it a try using "file test" and
"set solib-absolute-prefix /usr/local/arm/arm-linux/" but had no success 
so far.

frank@linux:~/uclibc_kram/apdf> arm-linux-gdb
GNU gdb 6.3
Copyright 2004 Free Software Foundation, Inc.
This GDB was configured as "--host=i686-pc-linux-gnu --target=arm-linux".
(gdb) file test
Reading symbols from /home/frank/test...done.
(gdb) set solib-absolute-prefix /usr/local/arm/arm-linux/
(gdb) target remote 192.168.1.133:5555
Remote debugging using 192.168.1.133:5555
0x000080e0 in ?? ()
(gdb) l
1       int main() {
2               while(1)
3               {
4                       printf("bla");
5
6               }
7
8       }
(gdb) b 1
Breakpoint 1 at 0x8428: file main.c, line 1.
(gdb) c
Continuing.

Breakpoint 1, main () at main.c:1
1       int main() {
(gdb) n
2               while(1)
(gdb) n
0x0001a12c in ?? ()
(gdb) n
Cannot find bounds of current function
(gdb) n
Cannot find bounds of current function
(gdb) n
Cannot find bounds of current function

(gdb) The program is running.  Exit anyway? (y or n) y
frank@linux:~/uclibc_kram/apdf> arm-linux-gdb
GNU gdb 6.3
Copyright 2004 Free Software Foundation, Inc.
This GDB was configured as "--host=i686-pc-linux-gnu --target=arm-linux".
(gdb)  file test
Reading symbols from /home/frank/test...done.
(gdb) set solib-absolute-prefix /usr/local/arm/arm-linux/
(gdb) target remote 192.168.1.133:5555
Remote debugging using 192.168.1.133:5555
0x000080e0 in ?? ()
(gdb) c
Continuing.

Program received signal SIGINT, Interrupt.
0x000080e0 in ?? ()
(gdb) c
Continuing.

Program received signal SIGINT, Interrupt.
0x000282b4 in ?? ()
(gdb) bt
#0  0x000282b4 in ?? ()

test depends only on the libc and the dynamic linker.
On the target these files are installed in /lib. The GDB
should be able to found them in
/usr/local/arm/arm-linux/lib.

Any ideas how i can solve this problem?

Regards,
  Frank

Re: Remote debugging and dynamic libraries

[Daniel Jacobowitz]

On Mon, Oct 31, 2005 at 08:55:32PM +0100, Frank Meerkoetter wrote:
> I gave it a try using "file test" and
> "set solib-absolute-prefix /usr/local/arm/arm-linux/" but had no success 
> so far.
> 
> frank@linux:~/uclibc_kram/apdf> arm-linux-gdb

This is the first time I recall seeing that you were using uclibc. 
It's likely that shared library and thread debugging are simply broken
in your C library; you may want to ask the uclibc developers if they
expect it to work.

> (gdb) b 1
> Breakpoint 1 at 0x8428: file main.c, line 1.
> (gdb) c
> Continuing.
> 
> Breakpoint 1, main () at main.c:1
> 1       int main() {

"info shared" at this point?

-- 
Daniel Jacobowitz
CodeSourcery, LLC