Re: Troubleshooting broken gdbserver/remote-target

Grant Edwards
2009-06-23T05:09:43Z

> But when the program is stopped while blocked in a call to
> read() inside gets(), gdb throws up its hands:

[...]

> GNU gdb 6.8
> [...]
> This GDB was configured as "--host=i386-pc-linux-gnu --target=arm-linux-uclibc".
> [New Thread 815]
> 0x40001350 in _start () at ldso/ldso/arm/elfinterp.c:332
> 332 }
> (gdb) c
> Continuing.
> ^C
> Program received signal SIGINT, Interrupt.
> 0x40031914 in ?? ()
> (gdb) bt
> #0 0x40031914 in ?? ()
>
>
> If I look at the maps or smaps file for the process, address
> 0x40031914 is clearly in uclibc.so:
>
> 40025000-4008a000 r-xp 00000000 01:00 637 /lib/libuClibc-0.9.30.1.so
>
> 40031914 is offset 0x0000c914 in /lib/libuClibc-0.9.30.1.so, and
> looking at the symbols in that file shows that offset 0x0000c914
> is in __libc_read()
[...]

> Why can't gdb figure out that the process is blocked in
> __libc_read() and print a proper backtrace?

I think I've found a clue why gdb is unable to figure out what
function contains address 0x40031914. Gdb seems to be aware of
the mappig of only one of the library files (/lib/ld-uClibc-0.9.30.1.so),
and doesn't appear to know that libuClibc-0.9.30.1.so is mapped:

(gdb) info file
Symbols from "/home/grante/hello/mecho".
Remote serial target in gdb-specific protocol:
Debugging a target over a serial line.
While running this, GDB does not access memory from...
Local exec file:
`/home/grante/hello/mecho', file type elf32-littlearm.
Entry point: 0x8420 0x000080f4 - 0x00008108 @ 0x000000f4 is .interp
0x00008108 - 0x00008160 @ 0x00000108 is .hash
0x00008160 - 0x00008270 @ 0x00000160 is .dynsym
0x00008270 - 0x0000833a @ 0x00000270 is .dynstr
0x0000833a - 0x0000835c @ 0x0000033a is .gnu.version
0x0000835c - 0x0000837c @ 0x0000035c is .gnu.version_r
0x0000837c - 0x000083ac @ 0x0000037c is .rel.plt
0x000083ac - 0x000083c4 @ 0x000003ac is .init
0x000083c4 - 0x00008420 @ 0x000003c4 is .plt
0x00008420 - 0x000085a0 @ 0x00000420 is .text
0x000085a0 - 0x000085b4 @ 0x000005a0 is .fini
0x000085b4 - 0x000085b8 @ 0x000005b4 is .eh_frame
0x000105b8 - 0x000105c0 @ 0x000005b8 is .ctors
0x000105c0 - 0x000105c8 @ 0x000005c0 is .dtors
0x000105c8 - 0x000105cc @ 0x000005c8 is .jcr
0x000105cc - 0x00010684 @ 0x000005cc is .dynamic
0x00010684 - 0x000106a8 @ 0x00000684 is .got
0x000106a8 - 0x000106b8 @ 0x000006a8 is .data
0x000106b8 - 0x00010ad8 @ 0x000006b8 is .bss
0x400000d4 - 0x40000240 @ 0x000000d4 is .hash in /home/grante/processors/atmel/RM9200/buildroot-2009.05/build_arm/staging_dir/lib/ld-uClibc.so.0
0x40000240 - 0x40000580 @ 0x00000240 is .dynsym in /home/grante/processors/atmel/RM9200/buildroot-2009.05/build_arm/staging_dir/lib/ld-uClibc.so.0
0x40000580 - 0x40000888 @ 0x00000580 is .dynstr in /home/grante/processors/atmel/RM9200/buildroot-2009.05/build_arm/staging_dir/lib/ld-uClibc.so.0
0x40000888 - 0x40000930 @ 0x00000888 is .rel.dyn in /home/grante/processors/atmel/RM9200/buildroot-2009.05/build_arm/staging_dir/lib/ld-uClibc.so.0
0x40000930 - 0x40008b70 @ 0x00000930 is .text in /home/grante/processors/atmel/RM9200/buildroot-2009.05/build_arm/staging_dir/lib/ld-uClibc.so.0
0x40008b70 - 0x40008ffc @ 0x00008b70 is .rodata in /home/grante/processors/atmel/RM9200/buildroot-2009.05/build_arm/staging_dir/lib/ld-uClibc.so.0
0x40011f14 - 0x40011f18 @ 0x00009f14 is .dtors in /home/grante/processors/atmel/RM9200/buildroot-2009.05/build_arm/staging_dir/lib/ld-uClibc.so.0
0x40011f18 - 0x40011fa8 @ 0x00009f18 is .dynamic in /home/grante/processors/atmel/RM9200/buildroot-2009.05/build_arm/staging_dir/lib/ld-uClibc.so.0
0x40011fa8 - 0x40012000 @ 0x00009fa8 is .got in /home/grante/processors/atmel/RM9200/buildroot-2009.05/build_arm/staging_dir/lib/ld-uClibc.so.0
0x40012000 - 0x40012008 @ 0x0000a000 is .data in /home/grante/processors/atmel/RM9200/buildroot-2009.05/build_arm/staging_dir/lib/ld-uClibc.so.0
0x40012008 - 0x4001205c @ 0x0000a008 is .bss in /home/grante/processors/atmel/RM9200/buildroot-2009.05/build_arm/staging_dir/lib/ld-uClibc.so.0

Here's the contents of /proc/<pid>/maps for the process being
debuged:

00008000-00009000 r-xp 00000000 01:00 130 /usr/bin/mecho
00010000-00011000 rw-p 00000000 01:00 130 /usr/bin/mecho
40000000-40009000 r-xp 00000000 01:00 642 /lib/ld-uClibc-0.9.30.1.so
40009000-4000a000 rw-p 40009000 00:00 0
40011000-40012000 r--p 00009000 01:00 642 /lib/ld-uClibc-0.9.30.1.so
40012000-40013000 rw-p 0000a000 01:00 642 /lib/ld-uClibc-0.9.30.1.so
40013000-4001c000 r-xp 00000000 01:00 212 /lib/libgcc_s.so.1
4001c000-40024000 ---p 4001c000 00:00 0
40024000-40025000 rw-p 00009000 01:00 212 /lib/libgcc_s.so.1
40025000-4008a000 r-xp 00000000 01:00 637 /lib/libuClibc-0.9.30.1.so
4008a000-40092000 ---p 4008a000 00:00 0
40092000-40093000 r--p 00065000 01:00 637 /lib/libuClibc-0.9.30.1.so
40093000-40094000 rw-p 00066000 01:00 637 /lib/libuClibc-0.9.30.1.so
40094000-40098000 rw-p 40094000 00:00 0
be98b000-be9a0000 rw-p befeb000 00:00 0 [stack]

Gdb figured out the /lib/ld-uClibc-0.9.30.1.so, but it's
missing /lib/libgcc_s.so.1 and /lib/libuClibc-0.9.30.1.so.

What would cause gdb to miss out on the fact that /lib/libuClibc-0.9.30.1.so
is mapped?

Where does gdb get mapping info?

--
Grant