Re: [patch 2/4] Fix hw watchpoints: reordered / simultaneously hit [fixup #1]

[Joel Brobecker <brobecker at adacore dot com>]

Jan,

> the patch got extended by this incremental change (fixing a regression):
>     
> gdb/
> 	Fix assertion failure with `set debug infrun 1'.
> 	* infrun.c (handle_inferior_event <debug_infrun>): New variable
> 	old_chain.  Temporarily switch INFERIOR_PTID.
> 	* target.h (target_stopped_by_watchpoint): Extend the comment.
> 	(target_stopped_data_address): New comment.  Rename X as ADDR_P.

Can we treat this part independently from the rest? I assume that
this is a latent issue that only gets uncovered by your watchpoint
patch? I think the bug is there regardless, and even if we can't test
it now, it's going to simplify a bit my task if we treat this piece
independently.

I think that your fix is not optimal.  Here is what I suggest instead:
Make the ptid an explicit parameter in the call to
target_stopped_by_watchpoint. There are two parts to this change,
and I think we can find a way of making the change in two steps:

  - First step: Change the profile of target_stopped_by_watchpoint
    to add a ptid (say as the second argument). We're also trying
    to get rid of these target_... macros, so now is the time to
    turn that macro into a function.  We update all the callers
    to pass the ptid (could be either inferior_ptid or ecs-ptid
    in your infrun case).

    We hold off the update of all the to_stopped_data_address
    callbacks in struct target_ops for now.  This means that we need
    to keep the current interface as is, and that we need to temporarily
    change the inferior_ptid before calling the callback.

  - Second step: Change the callbacks interface, and update all
    the callbacks. This is trickier.  For the platforms that we can test,
    I suggest trying to fix the code accordingly.  For the others, do
    the same as before: Start by changing the inferior_ptid during
    the life of the callback.

    This second step might or might not be worth it, as the code
    on which the callbacks depend might not entirely ready.  But
    at least we pushed the mess to the target code.

Since I'm dumping some cleanup work on you, I can take care of the
second part if you are willing to take care of the first one.

-- 
Joel