Re: [PATCH 28/28] Decouple inferior_ptid/inferior_thread(); dup ptids in thread list (PR/25412)

Pedro Alves
2020-04-17T16:46:27Z

On 4/17/20 3:06 PM, Simon Marchi wrote:
> On 2020-04-17 6:29 a.m., Pedro Alves wrote:
>> On 4/16/20 9:38 PM, Simon Marchi wrote:
>>> On 2020-04-16 4:12 p.m., Pedro Alves via Gdb-patches wrote:
>>
>>>> How are you making sure that iterating the threads walks them in
>>>> creation/insertion order instead of ptid_t order?
>>>
>>> The only spot that I found the order mattered was precisely for "info threads".
>>> There, I gather the list of threads to display, sort them by per_inf_num, and
>>> print them.
>>>
>>> https://github.com/simark/binutils-gdb/commit/25c67729996dc83912d34a5901016404b3638bc1#diff-5479a5443dca2232f8552dfb5b30ac3dR1104
>>>
>>
>> Hmm, OK. I'm not 100% sure that's a good idea; it makes me a bit nervous
>> because I'm not sure if this has an impact on run control. Something to
>> think about. We could instead have the new ptid_t map for ptid_t look ups, but
>> still also maintain the linked list in order to walk the thread list. (That
>> would also be a much simpler patch, I think.)
>
> I also thought about that as a backup solution. However, the testsuite didn't show
> any more regressions, so I stayed with just the map.

Maybe. Though, this is likely to make debugging gdb harder, both
interactive debugging ("p thread->next->next->state" kind of things), and
also infrun logs -- The order which gdb resumes, suspends, etc. threads
will change as threads appear/disappear. Sticking to creation order is
likely to avoid headaches, IMO.

Thanks,
Pedro Alves