Re: [patch] [gdbserver] Do not crash on file load without inferior

[Pedro Alves <pedro@codesourcery.com>]

On Thursday 24 February 2011 11:40:02, Jan Kratochvil wrote:
> Hi Pedro,
> 
> I always got:
> 
> (gdb) file .../gdb/testsuite/gdb.server/ext-run
> Load new symbol table from ".../gdb/testsuite/gdb.server/ext-run"? (y or n) y
> Reading symbols from .../gdb/testsuite/gdb.server/ext-run...done.
> gdbserver: Current inferior requested, but current_inferior is NULL
> 
> Remote connection closed
> (gdb)
> 
> if one connects to gdbserver --multi before loading the file.  One needs to
> load the file first to be able to place a breakpoint at *_start or main.
> 
> But I face other bugs so I cannot say much more.
> 
> I do not think this patch can ever have a regression.

Thanks.  I that revealed a problem on the GDB side instead.

E.g., if you have two inferiors loaded, and the not-current
inferior is running, but you do "file" on the not-running-yet
inferior, you'll see:

$ ./gdb ./testsuite/gdb.server/ext-run  -ex "tar extended-remote :9999" -ex "set remote exec-file /home/pedro/gdb/baseline/build/gdb/testsuite/gdb.server/ext-run" -ex "start"
...
Reading symbols from /home/pedro/gdb/baseline/build/gdb/testsuite/gdb.server/ext-run...done.
Setting up the environment for debugging gdb.
Remote debugging using :9999
Temporary breakpoint 1 at 0x4004ef: file ../../../src/gdb/testsuite/gdb.server/server.c, line 21.
Starting program: /home/pedro/gdb/baseline/build/gdb/testsuite/gdb.server/ext-run 

Temporary breakpoint 1, main (argc=1, argv=0x7fffffffe068) at ../../../src/gdb/testsuite/gdb.server/server.c:21
21        return 0;
(gdb) add-inferior 
Added inferior 2
(gdb) info inferiors 
  Num  Description       Executable        
  2    <null>                              
* 1    process 15952     /home/pedro/gdb/baseline/build/gdb/testsuite/gdb.server/ext-run 
(gdb) inferior 2
[Switching to inferior 2 [Thread 0.0] (<noexec>)]
(gdb) set debug remote 1
(gdb) file /home/pedro/gdb/baseline/build/gdb/testsuite/gdb.server/ext-run
Reading symbols from /home/pedro/gdb/baseline/build/gdb/testsuite/gdb.server/ext-run...done.
Sending packet: $Hgp0.0#ad...Packet received: OK
                ^^^^^^^
Sending packet: $qSymbol::#5b...Packet received: qSymbol:6764625f6167656e745f6764625f74705f686561705f627566666572
Sending packet: $qSymbol::6764625f6167656e745f6764625f74705f686561705f627566666572#1e...Packet received: qSymbol:6764625f6167656e745f6764625f6a756d705f7061645f627566666572
Sending packet: $qSymbol::6764625f6167656e745f6764625f6a756d705f7061645f627566666572#e1...Packet received: qSymbol:6764625f6167656e745f6764625f6a756d705f7061645f6275666665725f656e64
Sending packet: $qSymbol::6764625f6167656e745f6764625f6a756d705f7061645f6275666665725f656e64#ec...Packet received: qSymbol:6764625f6167656e745f636f6c6c656374696e67


But, Hgp0.0 means select _any_ thread in any process, not _no thread at all_.
Meaning GDBserver's current_inferior ends up set to a thread of the
wrong process, and GDBserver is querying inferior 1's symbols on
inferior 2!  See on GDBserver:

(gdb) p current_inferior->entry.id 
$3 = {pid = 15952, lwp = 15952, tid = 0}

So I think that we shouldn't send qSymbol at all when inferior_ptid is
null_ptid or rather with !target_has_execution (which ends up in
default_child_has_execution and currently resolves the same)?

-- 
Pedro Alves