private_thread_info thread-db.c and lin-lwp.c

private_thread_info thread-db.c and lin-lwp.c

[Andrew Cagney]

Hello,

I was looking to make ``struct thread_info'' opaque again but, noticed this:

thread-db.c contains:
	struct private_thread_info
	{
	  /* Cached LWP id.  Must come first, see lin-lwp.c.  */
	  lwpid_t lwpid;
	};
	....
	  tp = add_thread (ptid);
	  tp->private = xmalloc (sizeof (struct private_thread_info));
	  tp->private->lwpid = ti_p->ti_lid;
but no obvious reference to ->private.

Meanwhile, lin-lwp.c contains:
	struct private_thread_info
	{
	  int lwpid;
	};
	....
	  if (tp->private->lwpid == GET_LWP (lp->ptid))
but no obvious initialization of ->private when adding threads.

It turns out that the main thing keeping this working is that the 
lin-lwp.c code is in an unreachable function (find_lwp_callback()).

	Andrew

Re: private_thread_info thread-db.c and lin-lwp.c

[Mark Kettenis]

Andrew Cagney <ac131313@cygnus.com> writes:

> Hello,
> 
> I was looking to make ``struct thread_info'' opaque again but, noticed this:
> 
> thread-db.c contains:
> 	struct private_thread_info
> 	{
> 	  /* Cached LWP id.  Must come first, see lin-lwp.c.  */
> 	  lwpid_t lwpid;
> 	};
> 	....
> 	  tp = add_thread (ptid);
> 	  tp->private = xmalloc (sizeof (struct private_thread_info));
> 	  tp->private->lwpid = ti_p->ti_lid;
> but no obvious reference to ->private.
> 
> Meanwhile, lin-lwp.c contains:
> 	struct private_thread_info
> 	{
> 	  int lwpid;
> 	};
> 	....
> 	  if (tp->private->lwpid == GET_LWP (lp->ptid))
> but no obvious initialization of ->private when adding threads.

Those bits were supposed to interact closely.  Under normal
circumstances the code in lin-lwp.c shouldn't be adding threads to
GDB's list.

> It turns out that the main thing keeping this working is that the 
> lin-lwp.c code is in an unreachable function (find_lwp_callback()).

Well, that bit of code was used until recently.  I put it in to work
around bug in some of the GDB core code.  Michael Snyder believes he's
fixed that bug, and disabled the bit of code.  Things seem to work
right now, so I think we can rip this bit of code out.

Mark

Re: private_thread_info thread-db.c and lin-lwp.c

[Kevin Buettner]

On Jul 25, 11:03pm, Mark Kettenis wrote:

> Well, that bit of code was used until recently.  I put it in to work
> around bug in some of the GDB core code.  Michael Snyder believes he's
> fixed that bug, and disabled the bit of code.  Things seem to work
> right now, so I think we can rip this bit of code out.

But keep in mind that the ``private'' member is still used by the
Unixware threads implementation.

Re: private_thread_info thread-db.c and lin-lwp.c

[Andrew Cagney]

> On Jul 25, 11:03pm, Mark Kettenis wrote:
> 
> 
>> Well, that bit of code was used until recently.  I put it in to work
>> around bug in some of the GDB core code.  Michael Snyder believes he's
>> fixed that bug, and disabled the bit of code.  Things seem to work
>> right now, so I think we can rip this bit of code out.
> 
> 
> But keep in mind that the ``private'' member is still used by the
> Unixware threads implementation.


Yep.  There isn't anything wrong with the private member.  I'd just like 
to be sure I've got 100% control over it before I start adding things 
like the architecture, target, frames, regcache, ....

	Andrew