Troubleshooting broken gdbserver/remote-target

[Grant Edwards <grant dot b dot edwards at gmail dot com>]

I've given up for now on trying to get threaded debugging
working. :(

Now I'm just trying to get normal symbolic debugging and
backtrace working.  As long as execution is in user-application
code, everything is fine.  I can do "next", "finish", set
breakpoints, display variables, backtraces, etc.

However, if I stop the program while it's in libc (e.g.
blocking on a read() call), gdb has absolutely no clue. Gdb is
unable to display any backtrace or figure out what the current
function is.

I've set solib-absolute-prefix to point to the directory
containing target libraries that are unstripped and contain
debug symbols.  On startup, everything works (gdb knows the PC
is pointing to line 332 in ldso/ldso/arm/elfinterp.c:332.

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

Here's the program:

   #include <stdio.h>
   
   char buffer[1024];
   int main(void)
   {
     while (1)
       {
         gets(buffer);
         puts(buffer);
       }
     return 0;
   }

And here's the debugging session:


   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()

   0000c5e8 T __libc_pselect
   0000c6d8 T ptrace
   0000c858 T quotactl
   0000c8e0 T __libc_read
   0000c968 T readlink
   0000c9f4 T __libc_readv
   0000ca78 T reboot

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

AFAICT from strace output gdbserver never tries to read
/proc/<pid>/[s]maps.  What mechanism is supposed to be used to
determine what executable file a particular address is in?

-- 
Grant Edwards                   grante             Yow! INSIDE, I have the
                                  at               same personality disorder
                               visi.com            as LUCY RICARDO!!