Re: gdbserver

[Andrew Cagney <ac131313@ges.redhat.com>]

> On Fri, Aug 30, 2002 at 04:34:39PM -0700, Michael Snyder wrote:
> 
>> Daniel Jacobowitz wrote:
> 
>> > 
>> > [Bart, please try this patch.]
>> > 
>> > List folks,
>> > 
>> > I think the time has come for generic_prepare_to_proceed to actually be
>> > used.  The problem addressed by this patch is that PREPARE_TO_PROCEED
>> > is not a native-only macro (and not part of the target stack).  So
>> > lin_lwp_prepare_to_proceed would be called when using gdbserver, and of
>> > course trap_ptid would be null_ptid or stale.
>> > generic_prepare_to_proceed works correctly for lin-lwp native
>> > debugging, and for remote debugging.  This patch fixes an incorrect
>> > breakpoint hit after manually switching threads; i.e. the same
>> > breakpoint would be hit a second time.  I'll try to write an
>> > independent test case.
>> > 
>> > Patch look OK?
> 
>> 
>> Of course, a simpler and less intrusive fix would be to simply
>> define PREPARE_TO_PROCEED as generic_prepare_to_proceed, and 
>> remove lin_lwp_prepare_to_proceed.  

Yes (well using set_gdbarch_prepare_to_proceed() :-).  Hmm, things to do 
for someone --- add a linux-tdep.c file?

>> I'm not necessarily objecting to this patch -- just pointing
>> out an alternative.  If people think we're ready for this step, 
>> it's fine with me.
> 
> 
> I think we're ready, but let's wait and see.  For any non-threaded
> target generic_prepare_to_proceed won't do any harm, since it checks
> inferior_ptid != resume_ptid; for threaded targets, some version of
> this function must be better than none.

Post branch, the whole lot can probably be ripped out.

Andrew