Re: [PATCH 1/2] mi: Restore original thread/frame when specifying --thread or --thread-group

[Pedro Alves <palves at redhat dot com>]

On 08/03/2016 11:20 PM, Simon Marchi wrote:
> > On 16-08-03 09:41 AM, Pedro Alves wrote:

> I tried to set command_changes_user_selected_thread in normal_stop, but it didn't work
> right away.  That's because a breakpoint hit during an infcall calls error(), and the code
> that discards the cleanup when command_changes_user_selected_thread is true is not executed.
> 
> I solved that by adding a try/catch in mi_cmd_execute that discards the cleanup and rethrows
> the exception.

Yeah.  The approach of extending the previous_inferior_ptid's scope a bit would
avoid this, since it wouldn't need to revert back anything with a cleanup.
Might end up being that once all the spots are identified, switching to
the other approach ends up being a simpler patch.

> 
>> E.g., this user-defined command starts the program and stops in
>> thread 2.1, but MI still reverts back to the "--thread" thread:

...

> I was surprised this wasn't automatically solved with the fix in normal_stop.  That's
> because "start" sets previous_inferior_ptid to the initial thread when it is started
> (in init_wait_for_inferior).  Actually, I think that starting a new inferior is a case
> where we want to change the user selected thread.  Setting command_changes_user_selected_thread
> in init_wait_for_inferior fixes this.

Right.

> Here's an updated patch.  Notes/todo:
> 
>  - I did not test with compile yet.
>  - I thought about that just before sending: I think there's also something to do about
>    "frame X", "up" and "down", e.g.:
> 
>    -interpreter-exec --thread 1 console "up"
> 
>    won't work.

Sounds like it.  And don't we need a similar treatment for --frame ?

Thanks,
Pedro Alves