Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: "Marc Khouzam" <marc.khouzam@ericsson.com>
To: "Pedro Alves" <pedro@codesourcery.com>
Cc: <gdb@sourceware.org>
Subject: RE: Does HEAD support non-stop with 'gdbserver --multi' on Linux?
Date: Tue, 12 May 2009 15:23:00 -0000	[thread overview]
Message-ID: <6D19CA8D71C89C43A057926FE0D4ADAA076CB70C@ecamlmw720.eamcs.ericsson.se> (raw)
In-Reply-To: <6D19CA8D71C89C43A057926FE0D4ADAA075CB54C@ecamlmw720.eamcs.ericsson.se>

 

> -----Original Message-----
> From: gdb-owner@sourceware.org 
> [mailto:gdb-owner@sourceware.org] On Behalf Of Marc Khouzam
> Sent: Friday, May 01, 2009 2:40 PM
> To: Pedro Alves
> Cc: gdb@sourceware.org
> Subject: RE: Does HEAD support non-stop with 'gdbserver 
> --multi' on Linux?
> 
>  
> 
> > -----Original Message-----
> > From: Pedro Alves [mailto:pedro@codesourcery.com] 
> > Sent: Thursday, April 30, 2009 5:45 PM
> > To: Marc Khouzam
> > Cc: gdb@sourceware.org
> > Subject: Re: Does HEAD support non-stop with 'gdbserver 
> > --multi' on Linux?
> > 
> > On Thursday 30 April 2009 21:18:58, Marc Khouzam wrote:
> > 
> > > > What exactly are you seeing?  I just run a few non-stop test
> > > > (mi-nonstop.exp, mi-nsintrall.exp and ns-nsmoribund.exp tests)
> > > > against linux x86-64 gdbserver head, and they passed cleanly for
> > > > me, so *something* is working.  :-)
> > > 
> > > It seems no new thread is listed by GDB.
> > 
> > Hmmm, that should work.  This looks like another manifestation
> > of PR threads/10048.  Does this make a difference?
> 
> Yes, this fixed the problem.
> My Eclipse is still mis-behaving a bit, but that is probably
> my code.  The 'info thread' does show all threads.

I just noticed that after this fix, although the threads are properly
listed, the creation events only happen when the info thread
command is given.

I saw that with non-stop, when doing native linux debugging, there
is a conscious decision to trigger thread events as soon as possible
(from a comment of linux-nat.c:linux_handle_extended_wait()).
However, this does not happen when using gdbserver.

Is this something that is not ready yet, or a bug, or ... ?

Thanks

Marc



 
> Thanks!
> 
> > 
> > -- 
> > Pedro Alves
> > 
> > 2009-04-30  Pedro Alves  <pedro@codesourcery.com>
> > 
> > 	* linux-low.c (must_set_ptrace_flags): Delete.
> > 	(linux_create_inferior): Set 
> > `lwp->must_set_ptrace_flags' instead
> > 	of the global.
> > 	(linux_attach_lwp_1): Don't set PTRACE_SETOPTIONS here.  Set
> > 	`lwp->must_set_ptrace_flags' instead.
> > 	(linux_wait_for_event_1): Set ptrace options here.
> > 	(linux_wait_1): ... not here.
> > 
> > ---
> >  gdb/gdbserver/linux-low.c |   27 ++++++++++++++-------------
> >  gdb/gdbserver/linux-low.h |    4 ++++
> >  2 files changed, 18 insertions(+), 13 deletions(-)
> > 
> > Index: src/gdb/gdbserver/linux-low.c
> > ===================================================================
> > --- src.orig/gdb/gdbserver/linux-low.c	2009-04-12 
> > 22:44:01.000000000 +0100
> > +++ src/gdb/gdbserver/linux-low.c	2009-04-30 
> > 22:38:20.000000000 +0100
> > @@ -109,8 +109,6 @@ int stopping_threads;
> >  /* FIXME make into a target method?  */
> >  int using_threads = 1;
> >  
> > -static int must_set_ptrace_flags;
> > -
> >  /* This flag is true iff we've just created or attached to 
> our first
> >     inferior but it has not stopped yet.  As soon as it 
> does, we need
> >     to call the low target's arch_setup callback.  Doing 
> this only on
> > @@ -309,7 +307,7 @@ add_lwp (ptid_t ptid)
> >  static int
> >  linux_create_inferior (char *program, char **allargs)
> >  {
> > -  void *new_lwp;
> > +  struct lwp_info *new_lwp;
> >    int pid;
> >    ptid_t ptid;
> >  
> > @@ -344,7 +342,7 @@ linux_create_inferior (char *program, ch
> >    ptid = ptid_build (pid, pid, 0);
> >    new_lwp = add_lwp (ptid);
> >    add_thread (ptid, new_lwp);
> > -  must_set_ptrace_flags = 1;
> > +  new_lwp->must_set_ptrace_flags = 1;
> >  
> >    return pid;
> >  }
> > @@ -373,10 +371,6 @@ linux_attach_lwp_1 (unsigned long lwpid,
> >  	       strerror (errno), errno);
> >      }
> >  
> > -  /* FIXME: This intermittently fails.
> > -     We need to wait for SIGSTOP first.  */
> > -  ptrace (PTRACE_SETOPTIONS, lwpid, 0, PTRACE_O_TRACECLONE);
> > -
> >    if (initial)
> >      /* NOTE/FIXME: This lwp might have not been the tgid.  */
> >      ptid = ptid_build (lwpid, lwpid, 0);
> > @@ -392,6 +386,11 @@ linux_attach_lwp_1 (unsigned long lwpid,
> >    new_lwp = (struct lwp_info *) add_lwp (ptid);
> >    add_thread (ptid, new_lwp);
> >  
> > +
> > +  /* We need to wait for SIGSTOP before being able to make the next
> > +     ptrace call on this LWP.  */
> > +  new_lwp->must_set_ptrace_flags = 1;
> > +
> >    /* The next time we wait for this LWP we'll see a SIGSTOP 
> > as PTRACE_ATTACH
> >       brings it to a halt.
> >  
> > @@ -986,6 +985,13 @@ linux_wait_for_event_1 (ptid_t ptid, int
> >  	  continue;
> >  	}
> >  
> > +      if (event_child->must_set_ptrace_flags)
> > +	{
> > +	  ptrace (PTRACE_SETOPTIONS, lwpid_of (event_child),
> > +		  0, PTRACE_O_TRACECLONE);
> > +	  event_child->must_set_ptrace_flags = 0;
> > +	}
> > +
> >        if (WIFSTOPPED (*wstat)
> >  	  && WSTOPSIG (*wstat) == SIGSTOP
> >  	  && event_child->stop_expected)
> > @@ -1248,11 +1254,6 @@ retry:
> >  
> >    lwp = get_thread_lwp (current_inferior);
> >  
> > -  if (must_set_ptrace_flags)
> > -    {
> > -      ptrace (PTRACE_SETOPTIONS, lwpid_of (lwp), 0, 
> > PTRACE_O_TRACECLONE);
> > -      must_set_ptrace_flags = 0;
> > -    }
> >    /* If we are waiting for a particular child, and it exited,
> >       linux_wait_for_event will return its exit status.  
> Similarly if
> >       the last child exited.  If this is not the last 
> child, however,
> > Index: src/gdb/gdbserver/linux-low.h
> > ===================================================================
> > --- src.orig/gdb/gdbserver/linux-low.h	2009-04-12 
> > 22:44:01.000000000 +0100
> > +++ src/gdb/gdbserver/linux-low.h	2009-04-30 
> > 22:33:09.000000000 +0100
> > @@ -146,6 +146,10 @@ struct lwp_info
> >       was a single-step.  */
> >    int stepping;
> >  
> > +  /* If this flag is set, we need to set the event request 
> flags the
> > +     next time we see this LWP stop.  */
> > +  int must_set_ptrace_flags;
> > +
> >    /* If this is non-zero, it points to a chain of signals 
> > which need to
> >       be delivered to this process.  */
> >    struct pending_signals *pending_signals;
> > 
> > 
> 


  reply	other threads:[~2009-05-12 15:23 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-04-30 19:49 Marc Khouzam
2009-04-30 20:20 ` Pedro Alves
2009-04-30 20:55   ` Marc Khouzam
     [not found]     ` <200904302245.11843.pedro@codesourcery.com>
2009-05-01 18:40       ` Marc Khouzam
2009-05-12 15:23         ` Marc Khouzam [this message]
2009-05-12 15:58           ` Pedro Alves
2009-05-12 16:23             ` Marc Khouzam

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=6D19CA8D71C89C43A057926FE0D4ADAA076CB70C@ecamlmw720.eamcs.ericsson.se \
    --to=marc.khouzam@ericsson.com \
    --cc=gdb@sourceware.org \
    --cc=pedro@codesourcery.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox