This is the mail archive of the
mailing list for the GDB project.
Re: [RFC v3 3/8] Add basic Linux kernel support
- From: Andreas Arnez <arnez at linux dot vnet dot ibm dot com>
- To: Yao Qi <qiyaoltc at gmail dot com>
- Cc: Philipp Rudo <prudo at linux dot vnet dot ibm dot com>, Omair Javaid <omair dot javaid at linaro dot org>, "gdb-patches\@sourceware.org" <gdb-patches at sourceware dot org>, Yao Qi <yao dot qi at linaro dot org>, Peter Griffin <peter dot griffin at linaro dot org>
- Date: Fri, 19 May 2017 17:24:09 +0200
- Subject: Re: [RFC v3 3/8] Add basic Linux kernel support
- Authentication-results: sourceware.org; auth=none
- References: <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <20170503173626.15e61941@ThinkPad> <CANW4E-1RsgLsVdpNo5Sjrrua5PFHBJ5+EiwjGAiZi075cq7RSQ@mail.gmail.com> <20170508132204.7a733dc2@ThinkPad> <email@example.com>
On Fri, May 19 2017, Yao Qi wrote:
> Philipp Rudo <firstname.lastname@example.org> 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
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.