This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFC v4 3/9] Add basic Linux kernel support
- From: Yao Qi <qiyaoltc at gmail dot com>
- To: Philipp Rudo <prudo at linux dot vnet dot ibm dot com>
- Cc: gdb-patches at sourceware dot org, omair dot javaid at linaro dot org, yao dot qi at linaro dot org, peter dot griffin at linaro dot org, arnez at linux dot vnet dot ibm dot com
- Date: Mon, 19 Jun 2017 10:52:05 +0100
- Subject: Re: [RFC v4 3/9] Add basic Linux kernel support
- Authentication-results: sourceware.org; auth=none
- References: <20170612170836.25174-1-prudo@linux.vnet.ibm.com> <20170612170836.25174-4-prudo@linux.vnet.ibm.com> <86vanxtguc.fsf@gmail.com> <20170616121026.024f664b@ThinkPad>
Philipp Rudo <prudo@linux.vnet.ibm.com> writes:
>> Sorry, I don't understand this design. Can you elaborate?
>
> The target beneath reports us a "pid" it thinks is right. For example in a core
> file the register sections are usually named
>
> .reg/XXX
>
> where XXX names the thread these registers belong to. In user space this is
> typically the pid of the thread but for kernel dumps it usually is a cpu-id
> (this needn't be the logical cpu-id used in the kernel). Because of that the
> kernel ptid, we generate from task_struct, usually has a different lwp than the
> same thread reported from the target beneath. Nevertheless we need the target
> beneath to give us information for running tasks. That's why we need to
> introduce a mapping between the ptid of the target beneath and the kernel ptid.
>
> In short, this represents two different thread views (hardware vs. software
> threads).
>
> Did that answer your question? Or did you mean something different?
>
Can we use thread_info.priv to store these information rather than using
ptid_t?
>> > +
>> > +/* Private data struct to map between our and the target beneath PTID. */
>> > +
>> > +struct lk_ptid_map
>> > +{
>> > + struct lk_ptid_map *next;
>>
>> Can you use C++ stl list instead?
>
> As I already wrote Omair, my ptid_map was only meant to "somehow work" but
> never to be permanent. Managing the ptid map will be the main task for live
> debugging. That's why I think it is best when Omair changes this bit to
> whatever he needs.
The lk_ptid_map is a list, and this patch still iterates it. We need to
use C++ stl list, rather than leave it to someone else who does the
related work later.
--
Yao (齐尧)