Re: RFC: threads PREPARE_TO_PROCEED patch

[Daniel Jacobowitz <drow@mvista.com>]

On Fri, Mar 14, 2003 at 06:20:45PM +0100, Mark Kettenis wrote:
> Daniel Jacobowitz <drow@mvista.com> writes:
> 
> > This patch aims to avoid problems when using a native GNU/Linux debugger
> > (which supports threads) with a remote protocol stub that supports threads. 
> > lin_lwp_prepare_to_proceed gets called anyway, but it doesn't function,
> > because the trap_ptid is (unsurprisingly) not set; since it's internal
> > accounting for lin-lwp.  This patch makes us use generic_prepare_to_proceed
> > instead of the old default_prepare_to_proceed or lin_lwp_prepare_to_proceed;
> > it can get everything it needs from infrun.  If I recall correctly, it also,
> > as per the FIXME, supports switching threads better than the lin_lwp version
> > did.  But I haven't tested that in a long time.
> > 
> > This is a patch from last year, just before 5.3 was branched.  At the time
> > it was decided to be generally right, but too risky for 5.3.  Well, now I've
> > gone and sat on it for too long, and we're coming up on 5.4.  But I've been
> > using this patch since August without any problems.  Depending on consensus
> > I'd like to check it in either before or after we branch for release.
> > 
> > Thoughts, thread maintainers?
> 
> I'm not quite sure whether changing the gdbarch default is a good
> idea, but replacing lin_lwp_prepare_to_proceed with
> generic_prepare_to_proceed has been the intention all along.

Well, let me describe the problem I'm trying to solve; I'd like your
opinion on how to approach it.  When using gdbserver, we need to have
generic_prepare_to_proceed.  Not the lin_lwp version, and not the
"default" one from arch-utils.  The former won't work and the latter
doesn't do enough.  So cross debuggers need to pick this up.

Note that this is a property of the target.  Not of the architecture. 
I'm not sure PREPARE_TO_PROCEED belongs in gdbarch at all.  It's only
defined by Mach3, HP/UX, and Linux; it's undefined for x86-64-linux
(why???).  I could set it in all the Linux gdbarch init functions that
I care about, but that doesn't seem like much of a solution.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer