*** src/gdb/config/rs6000/nm-rs6000.h.org	Mon Sep 24 10:17:12 2001
--- src/gdb/config/rs6000/nm-rs6000.h	Mon Sep 24 10:26:37 2001
***************
*** 65,88 ****
     defined and 512 otherwise.  <sys/pthdebug.h> defines PTHDB_INVALID_PTID
     to be 0, so pthread ids appear to range from 1 to 32767.
  
     <limits.h> defines PID_MAX as INT_MAX, so process ids seem capable of
     occupying 32 bits.  However, I've never seen them occupy more than 16 bits.
  
     Given the above, allocate bits 0-15 in composite ids for process ids,
     bits 16-30 for pthread ids, and bit 31 -- aka negative values -- for
!    errors. */
  
  /* Return the process id stored in composite PID. */
! #define PIDGET(pid)		((pid) & 0xffff)
  
  /* Return the thread id stored in composite PID. */
! #define TIDGET(pid)		((pid) >> 16)
  
  /* Construct a composite id from process id PID and thread id TID. */
! #define MERGEPID(pid, tid)	(PIDGET (pid) | (tid) << 16)
  
  /* Return whether composite PID contains a thread id. */
! #define ISTID(pid)		((pid) & 0x7fff0000 && !((pid) & 0x80000000))
  
  /* This is needed to avoid one thread receiving another thread's
     step-past-breakpoint trap.  Maybe disabling SOFTWARE_SINGLE_STEP_P would
--- 65,100 ----
     defined and 512 otherwise.  <sys/pthdebug.h> defines PTHDB_INVALID_PTID
     to be 0, so pthread ids appear to range from 1 to 32767.
  
+  XXXXX : ORIGINAL TEXT (noting a bad assumption):
     <limits.h> defines PID_MAX as INT_MAX, so process ids seem capable of
     occupying 32 bits.  However, I've never seen them occupy more than 16 bits.
  
     Given the above, allocate bits 0-15 in composite ids for process ids,
     bits 16-30 for pthread ids, and bit 31 -- aka negative values -- for
!    errors.
!  XXXXX : END ORIGINAL TEXT
!  **NOTE: The assumption above is bad.  The PID is not very often greater than
!  16 bits, but that doesn't mean it is never greater.  The code is using a
!  single int to be shared between the PID and the TID, though in reality the PID
!  needs a full int of its own.  We can make the situation a "little bit" better 
!  (that is, 2 extra bits), to make the incidence of failure much less.  THIS IS
!  STILL A DESIGN FLAW (BUG), but will at least be a little less frequent.  We
!  now just use two less bits for thread ids, leaving bits 0-17 for PIDs, and
!  18-30 for TIDs.  The real fix is left for someone with greater familiarity
!  with the overall code.
! */
  
  /* Return the process id stored in composite PID. */
! #define PIDGET(pid)		((pid) & 0x3ffff)
  
  /* Return the thread id stored in composite PID. */
! #define TIDGET(pid)		((pid) >> 18)
  
  /* Construct a composite id from process id PID and thread id TID. */
! #define MERGEPID(pid, tid)	(PIDGET (pid) | (tid) << 18)
  
  /* Return whether composite PID contains a thread id. */
! #define ISTID(pid)		((pid) & 0x7ffc0000 && !((pid) & 0x80000000))
  
  /* This is needed to avoid one thread receiving another thread's
     step-past-breakpoint trap.  Maybe disabling SOFTWARE_SINGLE_STEP_P would