Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Michael Snyder <msnyder@redhat.com>
To: gdb-patches@sources.redhat.com
Cc: drow@mvista.com, kettenis@chello.nl, jimb@redhat.com, kevinb@redhat.com
Subject: [RFC] lin-lwp.c prelim changes for new thread model
Date: Mon, 06 Jan 2003 23:44:00 -0000	[thread overview]
Message-ID: <3E1A14C5.77F6C2DF@redhat.com> (raw)

[-- Attachment #1: Type: text/plain, Size: 1380 bytes --]

Hi folks, 

The up and coming kernel (2.4.20, I believe?) and the next glibc (2.3.1)
both bring some drastic changes to linux threads.  The current gdb thread
debugging code will not handle them as is.

This is a smallish change that I propose as a preliminary step;
it'll get things partly working in the new world, without breaking
them in the old.

Here's the rationalle.

In the old/current model, when one thread gets a signal (such as TRAP), 
we (gdb) have to call kill (SIGSTOP, pid) for every other thread
(excepting the event thread), and then do a waitpid on each of them.

In the new model, when one thread gets a signal, we only have to 
send kill(SIGSTOP, pid) to _one_ thread, and the kernel will then
propagate the signal to all of them (_including_ the one that has
already stopped with eg. SIGTRAP).  We must still do a waitpid on
each and every thread -- however, that now _includes_ the one that
stopped in the first place (and which we've already done one waitpid on).

I know, you're thinking "wasn't this supposed to get simpler?"

The minimal change I propose below is as follows:
When we send kill(SIGSTOP) to all the threads, we now include
the event thread, where previously we had made him a special case.
That way, whether in the new model or the old one, we can now do
a waitpid on every thread including the event thread.

What do you think?

Michael

[-- Attachment #2: kill.diff --]
[-- Type: text/plain, Size: 2371 bytes --]

2003-01-06  Michael Snyder  <msnyder@redhat.com>

	* lin-lwp.c (lin_lwp_wait): Allow the event thread to receive
	kill (SIGSTOP) along with everyone else, and do a corresponding
	waitpid on the event thread.  This will help us adapt gdb to 
	work with the new kernel and its different thread model.

Index: lin-lwp.c
===================================================================
RCS file: /cvs/src/src/gdb/lin-lwp.c,v
retrieving revision 1.40
diff -p -r1.40 lin-lwp.c
*** lin-lwp.c	6 Jan 2003 23:12:29 -0000	1.40
--- lin-lwp.c	6 Jan 2003 23:14:44 -0000
*************** lin_lwp_wait (ptid_t ptid, struct target
*** 1358,1377 ****
  	}
      }
  
!   /* This LWP is stopped now.  */
!   lp->stopped = 1;
  
!   if (debug_lin_lwp)
!     fprintf_unfiltered (gdb_stdlog, "LLW: Candidate event %s in %s.\n",
! 			status_to_str (status), 
! 			target_pid_to_str (lp->ptid));
  
!   /* Now stop all other LWP's ...  */
!   iterate_over_lwps (stop_callback, NULL);
  
!   /* ... and wait until all of them have reported back that they're no
!      longer running.  */
!   iterate_over_lwps (stop_wait_callback, &flush_mask);
  
    /* If we're not waiting for a specific LWP, choose an event LWP from
       among those that have had events.  Giving equal priority to all
--- 1358,1388 ----
  	}
      }
  
!   /* Stop all other LWPs, if any.  */
!   if (!WIFEXITED (status))	/* Can't stop it if it's exited...  */
!     {
!       if (debug_lin_lwp)
! 	fprintf_unfiltered (gdb_stdlog, "LLW: Candidate event %s in %s.\n",
! 			    status_to_str (status), 
! 			    target_pid_to_str (lp->ptid));
  
!       /* Now stop all other LWP's ...  */
!       iterate_over_lwps (stop_callback, NULL);
  
!       /* The event thread must now be continued, before it can be
! 	 waited again.  */
!       errno = 0;
!       ptrace (PTRACE_CONT, GET_LWP (lp->ptid), 0, 0);
!       if (debug_lin_lwp)
! 	fprintf_unfiltered (gdb_stdlog, 
! 			    "LLW: PTRACE_CONT %s, 0, 0 (%s)\n",
! 			    target_pid_to_str (lp->ptid),
! 			    errno ? safe_strerror (errno) : "OK");
  
!       /* ... and wait until all of them have reported back that they're no
! 	 longer running.  */
!       iterate_over_lwps (stop_wait_callback, &flush_mask);
!     }
  
    /* If we're not waiting for a specific LWP, choose an event LWP from
       among those that have had events.  Giving equal priority to all

             reply	other threads:[~2003-01-06 23:44 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-01-06 23:44 Michael Snyder [this message]
2003-01-07  3:31 ` Daniel Jacobowitz
2003-01-07 20:39   ` Michael Snyder
2003-01-08  0:34   ` Andrew Cagney

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=3E1A14C5.77F6C2DF@redhat.com \
    --to=msnyder@redhat.com \
    --cc=drow@mvista.com \
    --cc=gdb-patches@sources.redhat.com \
    --cc=jimb@redhat.com \
    --cc=kettenis@chello.nl \
    --cc=kevinb@redhat.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