Re: [RFC v4 3/9] Add basic Linux kernel support

Yao Qi
2017-06-19T09:52:08Z

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 (齐尧)