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

[Marc Khouzam <marc.khouzam@ericsson.com>]

 

> -----Original Message-----
> From: gdb-patches-owner@sourceware.org 
> [mailto:gdb-patches-owner@sourceware.org] On Behalf Of Pedro Alves
> Sent: Thursday, February 24, 2011 7:43 AM
> To: gdb-patches@sourceware.org
> Cc: Jan Kratochvil
> Subject: Re: [patch] [gdbserver] Do not crash on file load 
> without inferior
> 
> 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-ru
> n" -ex "start"
> ...
> Reading symbols from 
> /home/pedro/gdb/baseline/build/gdb/testsuite/gdb.server/ext-ru
> n...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-ru
> n...done.
> Sending packet: $Hgp0.0#ad...Packet received: OK
>                 ^^^^^^^
> Sending packet: $qSymbol::#5b...Packet received: 
> qSymbol:6764625f6167656e745f6764625f74705f686561705f627566666572
> Sending packet: 
> $qSymbol::6764625f6167656e745f6764625f74705f686561705f62756666
> 6572#1e...Packet received: 
> qSymbol:6764625f6167656e745f6764625f6a756d705f7061645f627566666572
> Sending packet: 
> $qSymbol::6764625f6167656e745f6764625f6a756d705f7061645f627566
> 666572#e1...Packet received: 
> qSymbol:6764625f6167656e745f6764625f6a756d705f7061645f62756666
> 65725f656e64
> Sending packet: 
> $qSymbol::6764625f6167656e745f6764625f6a756d705f7061645f627566
> 6665725f656e64#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}

That sounds pretty bad.

Any chance of getting a fix for this in the 7_2 branch?
Which I gather would fix the problem Jan originally reported.
Having to specify the 'file' before connecting to the target
is a regression from previous versions of GDB and I was hoping
not to have to special-case it in Eclipse :-)

Thanks

Marc


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