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

[Philipp Rudo <prudo@linux.vnet.ibm.com>]

On Mon, 19 Jun 2017 10:52:05 +0100
Yao Qi <qiyaoltc@gmail.com> wrote:

> 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?


We cannot use thread_info.priv because the remote target already uses it.  This was the
main reason why Peter abandoned his patch.

> >> > +
> >> > +/* 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.

With respect to Omairs mail I think this is obsolete.

Philipp