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

Simon Marchi simark@simark.ca
Wed Jun 19 17:14:00 GMT 2019


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. 
> 
> Jan

Note to gdb@, the conversion continues here:

https://sourceware.org/ml/gdb-patches/2019-06/msg00392.html

Simon



More information about the Gdb mailing list