Re: [PATCH 3/3] gdb: don't use the global thread-id in the saved breakpoints file

[Pedro Alves <pedro@palves.net>]

On 2023-03-16 5:06 p.m., Andrew Burgess wrote:
> Andrew Burgess <aburgess@redhat.com> writes:
> 
>> Pedro Alves <pedro@palves.net> writes:
>>>
>>> On 2023-02-10 7:22 p.m., Andrew Burgess wrote:
>>>> Pedro Alves <pedro@palves.net> writes:

>>> My thinking is that internally, the thread is really inferior-qualified.
>>> It is just a presentation detail in the CLI that we don't print the
>>> inferior when there's only one inferior, for backwards compatibility.
>>> That may even change in the future.  An MI frontend / GUI may be presenting
>>> the qualified ID, for instance.
>>>
>>> It seems to be that there are two valid approaches:
>>>
>>> #1 - we consider what the user typed when the breakpoint was created as canonical,
>>>      and thus we save the breakpoint using the same breakpoint spec string that
>>>      user typed originally, meaning, if the user typed:
>>>
>>>        "break foo thread 1"
>>>
>>>      then that's what we'd save, even if the user added a second
>>>      inferior after creating the breakpoint.
>>>
>>>      Of course, it follows then that if the breakpoint is created with
>>>
>>>        "break foo thread 1.1"
>>>
>>>      then that's what we save.  So the user would have the option.
>>>
>>>      I'm really not sure whether this is an option that we should be giving
>>>      users, though.  What if the breakpoint was created via Python, or via the
>>>      MI with --thread ?  Then the concept of original "thread" may not even exists,
>>>      even though we save such a breakpoint too.
>>>
>>> #2 - we consider that the thread that the breakpoint ended up bound to is what
>>>      is canonical and thus we always print the qualified id to the file.
>>>
>>> The approach in your patch is neither of the above -- it prints the qualified
>>> or non-qualified thread id depending on a CLI presentation detail, which seems
>>> brittle to me.
>>>
>>> Option #2 seems the simplest to explain, document, and implement, to me,
>>> but I could be convinced to go with #1 too.
>>
>> Thanks for the explanation.  I've implemented #2 in the patch below,
>> what are your thoughts?

Sorry for the delay.  (I simply forgot to reply.)  It looks good to me.

> 
> I'm planning to push this patch some time next week unless someone
> objects.
>