MI commands with --thread (--frame?) do not preserve user selected thread / frame

[Simon Marchi]

On 2019-06-19 12:04 p.m., Jan Vrany wrote:
> On Wed, 2019-06-19 at 11:54 -0400, Simon Marchi wrote:
>> On 2019-06-19 11:10 a.m., Jan Vrany wrote:
>>> On Wed, 2019-06-19 at 11:53 +0100, Jan Vrany wrote:
>>>> Hi, 
>>>>
>>>> I was debugging a multithreaded program and realized that using --thread option to
>>>> verious MI command silently changes user selected thread - here's an example using
>>>> separate UI and CLI chahhel (tested on commit 6f5601c4d0)
>>>>
>>>>
>>> ...
>>>>
>>>> As you can see, there was no `frame`, `thread`, `-select-frame` or `-thread-select` command between
>>>> first and second info thread / frame commands on CLI, yet the selected thread / frame changed (silently).
>>>>
>>>> Is this intended behavior? If so what's the rationale?
>>
>> No, this is indeed a known bug:
>>
>> https://sourceware.org/bugzilla/show_bug.cgi?id=20684
>>
> 
> Ah, I see. 
> 
>>>
>> So it seems to work (at least for a simple case, there might be some edge cases I don't recall).  I
>> think that the CLI and MI events about the thread change should not appear though, since the goal is
>> to make it appear as if there is no user selection changes.
> 
> I agree, the event should not be emitted. This was just a quick hack whether 
> it'd help in my case. If you think this is an acceptable way of "fixing" it,
> I'm happy to improve this patch and submit. 

[Moving this discussion to gdb-patches, since we are getting in implementation details]

That sounds like a reasonable approach.

Can you verify if the frame is correctly saved, if you do:

 thread 1
 frame 2
 -stack-info-depth --thread 3

After these commands, is frame 2 of thread 1 selected?

Simon