Re: [non-commit patch] Fix gdbserver qXfer:libraries-svr4 regression in special cases

[Pedro Alves <palves at redhat dot com>]

On 04/10/2012 09:06 PM, Jan Kratochvil wrote:

> On Mon, 05 Mar 2012 16:53:02 +0100, Pedro Alves wrote:
>> GDBserver can ask GDB the address of _r_debug, using the qSymbols mechanism,
>> so it doesn't look that much trouble.  WDYT of the alternative patch below?
>> It fixes the testcase too.
> 
> I worked on it and it works great; just the testcase was bogus.
> 
> The testcase did:
> 	gdbserver ld.so prog &
> 	gdb:
> 	file ld.so
> 	target remote ...
> 	file prog
> But in reality people do:
> 	gdbserver ld.so prog &
> 	gdb:
> 	file prog
> 	target remote ...
> 
> In this case qSymbol for _r_debug cannot work as GDB will never find any new
> library, therefore GDB will never find ld.so to find _r_debug there.
> A chicken-and-egg problem.


Yeah, bummer.

> 
> There was another issue being dealt with in the patch below that originally
> GDB send qXfer:libraries-svr4:read before qSymbol and therefor GDB did the
> expensive (and unsuccessful) non-accelerated reading from gdbserver for the
> first time.
> 
>> @@ -4522,6 +4523,8 @@ linux_look_up_symbols (void)
>>  #ifdef USE_THREAD_DB
>>    struct process_info *proc = current_process ();
>>  
>> +  svr4_look_up_symbols ();
>> +
>>    if (proc->private->thread_db != NULL)
>>      return;
>>  
>  - Also here it is put into USE_THREAD_DB conditional, I think it should not
>    be related to USE_THREAD_DB.
> 
> If you move 'gdb_test "file ${binfile}"'... down before the "continue" command
> it works great; but it is not useful in practice.


Yeah.  qSymbols/_r_debug would still work for static binaries, and accelerate
those that dlopen other DSOs, though admittedly there may not exist many
of those binaries in practice.

> 
> So I plan to use the former patch of mine to just always fall-back to the
> non-accelerated linux-nat reading of memory.



Just for the record, I noticed something else with this use case:

$ cp /lib64/ld-linux-x86-64.so.2 myld.so
$ ./gdbserver :2346 ./myld.so /home/pedro/gdb/mygit/build/gdb/testsuite/gdb.server/solib-list
Process ./myld.so created; pid = 5567
Listening on port 2346
Remote debugging from host 127.0.0.1

$ ./gdb /home/pedro/gdb/mygit/build/gdb/testsuite/gdb.server/solib-list
(gdb) tar remote :2346
Remote debugging using :2346
Reading symbols from /lib64/ld-linux-x86-64.so.2...Reading symbols from /usr/lib/debug/lib64/ld-2.14.90.so.debug...done.
Loaded symbols for /lib64/ld-linux-x86-64.so.2
0x00005555555556e0 in ?? ()
(gdb) info sharedlibrary
>From                To                  Syms Read   Shared Object Library
0x0000003791800b20  0x000000379181aaaa  Yes         /lib64/ld-linux-x86-64.so.2

GDB fallsback to listing the .interp interpreter, even though that was not the
interpreter in use (and the addresses don't match what was loaded).

What's more, GDBserver/qSymbols does find _r_debug, but only because GDB loaded
the symbols of the wrong interpreter:

(gdb) p _r_debug
Cannot access memory at address 0x3791a23260

But it only does that once:

(gdb) nosharedlibrary
(gdb) info sharedlibrary
No shared libraries loaded at this time.
(gdb)

BTW, on the GDBserver console one sees this:

gdbserver: unexpected r_debug version 0
gdbserver: unexpected r_debug version 0

-- 
Pedro Alves