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

Omair Javaid omair.javaid@linaro.org
Mon Jun 19 13:35:00 GMT 2017


On 19 June 2017 at 14:52, 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?
>
>>> > +
>>> > +/* 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.

Hi Phillip,

I have sent you my changes where I have also changed lk_ptid_map to a
c++ map data type.

Please have a look at those before making any further changes to your patches.

Thanks!


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



More information about the Gdb-patches mailing list