Re: [RFC v3 3/8] Add basic Linux kernel support

[Andreas Arnez <arnez at linux dot vnet dot ibm dot com>]

On Fri, May 19 2017, Yao Qi wrote:

> Philipp Rudo <prudo@linux.vnet.ibm.com> writes:
>
>> * Implement separate thread_lists.
>>   Allow every target to manage its own thread_list.  Heavy impact for you and a
>>   lot work for me...
>
> Hi Philipp,
> before you spend a lot of time implementing this, it is better to start
> an RFC discussion on an appropriate time, so that people can well
> understand why do we need this change.

FYI, I have just started investigating this a bit.

The reason for multiple thread lists has been covered in some of the
discussions already, but let me give my few cents.

In the kernel live debug scenario we conceptually have two different
thread models layered on top of each other:

* LK target: Thread == Linux kernel thread
* Remote target: Thread == CPU

If we represent CPUs and Linux threads in a single thread list, then it
becomes difficult to maintain consistency between the LK target and the
remote target: Who owns which parts of the thread_info?  How to
guarantee unique ptids across the board, etc.?  Not to speak of the
confusing "info threads" output if CPUs and threads are munged
together.

Unfortunately many places in GDB assume that there is just one thread
list, one active target and one current inferior/thread.  In order to
maintain multiple thread lists cleanly, we probably have to lift these
restrictions and get rid of the global variables current_target,
thread_list, inferior_ptid, etc., or most of their uses.  That's my
preliminary conclusion, anyway.  Alternate suggestions are welcome.

--
Andreas