Re: gdbserver

Andrew Cagney
2002-09-03T01:47:42Z

> 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