Re: [PATCH 02/11] gdb: introduce intrusive_list, make thread_info use it

[Simon Marchi via Gdb-patches <gdb-patches@sourceware.org>]

On 2021-07-06 5:02 p.m., Pedro Alves wrote:
> On 2021-07-06 8:38 p.m., Simon Marchi wrote:
>> On 2021-07-05 11:44 a.m., Pedro Alves wrote:
>>>>>  $1 = intrusive list of thread_info = {
>>>    {id = 1.1, ptid = 1000.1000.0, state = THREAD_RUNNING}, 
>>>    {id = 1.3, ptid = 1000.1002.0, state = THREAD_STOPPED},
>>>    {id = 1.5, ptid = 1000.3672.0, state = THREAD_STOPPED}
>>>  }
>>
>> How would you accomplish this, with a struct thread_info
>> pretty-printer?  This means that printing a single thread like this:
>>
>>   (gdb) print *tp
>>
>> would also produce the short output, I don't think we want that.  When
>> we print a single thread_info structure, I think it's good to have all
>> the fields shown.
> 
> I don't have a great answer.  It feels to me like the pretty printer code
> should ask the container if it has a custom printer for the element, and only
> if it doesn't would it look up the printer for the element's type.

That would be a new feature that doesn't exist today, I think: a
different printer for a type when it's printed as a container element
than when it's printed standalone.

> Maybe having a printer for thread_info all the time isn't that bad.  printing
> thread_info structures does dump a lot of stuff and isn't that easy to parse.
> If you want to see the whole thing, there's always "print /r" to disable the
> printer.
> 
>>
>> Perhaps by defining a more specialized pretty-printer for
>> intrusive_list<thread_info>?  But then I'm not sure what kind of value
>> the children method would return.
> 
> I guess it could return a typedef for "thread_info *" like e.g., "thread_info_p" instead
> of the raw pointer, and then we'd register a printer for only the typedef.  I
> think that means that indexing via thread_list[1] etc. would also return the typedef,
> and thus give you the short print..

I think these are all good ideas for improvements, but I'd rather keep
them for later (if someone wants to implement them, I'm not sure I
will).  We could bike-shed for a while on how to display a thread_info,
what to include / what to exclude, etc.  I think that my original
proposal is strictly better than what we have today, in the sense that
today you just can't print the whole list of threads, so we don't lose
anything.

Simon