Re: RFC: threads PREPARE_TO_PROCEED patch

[Andrew Cagney <ac131313 at redhat dot com>]

> On Sat, Mar 15, 2003 at 09:39:14PM +0100, Mark Kettenis wrote:
>
> >    Date: Fri, 14 Mar 2003 13:35:29 -0500
> >    From: Daniel Jacobowitz <drow at mvista dot com>
> >
> >    > 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.
> >
> > OK, but generic_prepare_to_proceed() is perfectly usable on a native
> > GNU/Linux GDB too, isn't it?
>
>
> Yes, exactly.

Needing to change one of GDB's architecture methods dependant on a 
target attribute (local or remote) suggests that the method should be in 
the target vector.

> >    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.
> >
> > It seems to be a property of the OS to me.  In its current
> > incarnation, gdbarch does includes details of both the architecture
> > (ISA) and the OS (OS/ABI).  So gdbarch seems to be the correct place
> > for PREPARE_TO_PROCEED to me.  So yes, I think you should add it to
> > all relevant Linux gdbarch init functions.
>
>
> I can do that; I'll put a patch together.
>
> But I must admit that I don't really agree.  It seems to be a property
> of the threads implementation for the target instead. Consider this
> case: if someone wanted to write a remote protocol stub for HP/UX. 
> They wouldn't want the HP/UX version of PREPARE_TO_PROCEED naturally,
> since that's native-only.  They'd want most likely
> generic_prepare_to_proceed.  The default function isn't useful; it
> doesn't support switching threads correctly.
>
> (Incidentally, from reading the HP/UX implementation, I believe that
> using generic_prepare_to_proceed would work there too.  It wouldn't
> work for the Mach 3.0 implementation as-is but I think it could be made
> to work.  I'm not volunteering; are either hppa*-*-osf* or
> mips*-*-mach3* still living?  Perhaps we should deprecate them next
> release.)

Obsoleting hppa*-*-osf* was sent to announce list (no objection so far). 
 Can you formally propose removing mips*mach3 here (and create a bug 
report) that can quickly happen.

If you both really think that PREPARE_TO_PROCEED is wrong, deprecate it 
(details left as an exercise for the reader).

Andrew