gdb in non-stop/sync mode connects to gdbserver

gdb in non-stop/sync mode connects to gdbserver

[Yao Qi]

Hello,
When running moribund-step.exp with boardfile 'unix', we'll get two passes,

   PASS: gdb.base/moribund-step.exp: set non-stop on
   PASS: gdb.base/moribund-step.exp: step

However, when running it with boardilfe native-gdbserver, we'll get only 
one pass,

   PASS: gdb.base/moribund-step.exp: set non-stop on

in fact, gdb hang there when connecting to gdbserver.  Supposing gdb is 
in non-stop and sync mode, here is callgraph of functions related to 
'connecting to remote gdbserver'.

remote_start_remote
   1) putpkt ("QNonStop:1");
   2) remote_thread_info
        |
        +-> remote_notice_new_inferior
              |
              +-> notice_new_inferior
              |     |
              |     +-> target_stop and then wait_for_inferior [A]
              +-> attach_command_post_wait
                    |
                    + target_stop (in non-stop mode, and no wait) [B]

  3) putpkt ("?")
  4) init_wait_for_inferior
  5) check packet replied to "?", and handle stop reply if needed.

After step 1), GDBserver knows that "we are in non-stop mode".  In step 
2), gdb calls target_stop in [A], sending 'vCont;t' to stop one thread, 
and expect to get a %Stop notification.  However, when gdbserver 
launches program, the thread has been stopped before gdb connects to 
gdbserver.  So the stop request from gdb is ignored by gdbserver (shown 
by the gdbserver log below),

   getpkt ("vCont;t:p45df.45df");  [no ack sent]
   already stopped LWP 17887 at GDB's request
   Need step over [LWP 17887]? Ignoring, should remain stopped
   Resuming, no pending status or step over needed
   putpkt ("$OK#9a"); [noack mode]

and no %Stop notification is sent back to gdb.  Then, gdb hang there.

The problem is that gdb wants to get a certain thread stopped, but 
doesn't know its state, so has to blindly force to stop it, and expect a 
%Stop notification to come.  Then, I am wondering if gdbserver can sends 
the state of threads, if known, to gdb when gdb connects, and gdb don't 
have to stop threads if they are already stopped.  Is it a good way to 
go?  We can achieve this by add new attribute 'state' in the xml 
returned to qxfer:threads:read.  My experiments show it works, but not 
sure if I miss something important.

Doing this is not enough to fix the problem I mentioned at the 
beginning.  There is another problem in the following steps.  Supposing 
gdb doesn't call target_stop in [A], gdb will call target_stop in [B],

       GDB            GDBserver
[B]   'vCont;t'  ->
                  <- 'OK'
3)    '?'        ->
                  <- 'T0505:xxxxx'
4)
5) process stop reply and send 'vStopped'
      'vStopped'  ->
                  <- 'OK'

This process requires that there is no packet sent in step 4), because 
gdb is expecting to get a stop reply.  Unfortunately, 
breakpoint_init_inferior, called by init_wait_for_inferior, has to 
access inferior memory, so 'm' packet is sent out.  Looks like the fix 
to this problem is to move all functions which cause sending packets in 
step 4) after step 5).  Does it sound a good idea?

I've got a patch to fix the two problems, but I am not sure it is on a 
right direction.  If it is correct, I'll polish the patch, and post it.

-- 
Yao (齐尧)

Re: gdb in non-stop/sync mode connects to gdbserver

[Pedro Alves]

On 11/22/2012 04:09 PM, Yao Qi wrote:
> Hello,
> When running moribund-step.exp with boardfile 'unix', we'll get two passes,
> 
>   PASS: gdb.base/moribund-step.exp: set non-stop on
>   PASS: gdb.base/moribund-step.exp: step
> 
> However, when running it with boardilfe native-gdbserver, we'll get only one pass,
> 
>   PASS: gdb.base/moribund-step.exp: set non-stop on
> 
> in fact, gdb hang there when connecting to gdbserver.  Supposing gdb is in non-stop and sync mode, here is callgraph of functions related to 'connecting to remote gdbserver'.

"non-stop and sync mode" is really not supported.  non-stop is defined to
work only with async on.  There are many such assumptions in the code.  That the
test works in sync mode on native is just an accident.

-- 
Pedro Alves

Re: gdb in non-stop/sync mode connects to gdbserver

[Yao Qi]

On 11/23/2012 02:16 AM, Pedro Alves wrote:
> "non-stop and sync mode" is really not supported.  non-stop is defined to
> work only with async on.  There are many such assumptions in the code.  That the
> test works in sync mode on native is just an accident.

I had a vague impression that "non-stop" works on top of async mode 
before.  However, I was misled by the code that 'target_can_async_p' is 
checked on 'non-stop' path, and accordingly think "non-stop may work on 
sync mode".  Anyway, thanks for confirming this.

-- 
Yao (齐尧)