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

[Andrew Burgess <aburgess@redhat.com>]

Pedro Alves <pedro@palves.net> writes:

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

Not a problem.  Now pushed.

Thanks,
Andrew