Re: [RFC PATCH 0/4] GDB Linux Kernel Thread Awareness

[Kieran Bingham <kieran.bingham@linaro.org>]

On 25/02/16 20:03, Jeff Mahoney wrote:
> On 2/25/16 2:15 PM, Kieran Bingham wrote:
>> I've wanted to get some actual code out for a while and as such I have
>> tried to strip down the implementation of LKD to the bare essentials for
>> implementing thread awareness. I hope to get some feedback on the best ways of
>> upstreaming this functionality.
>>
>> This functionality implements the 'possible improvements' Related to Execution
>> Contexts as mentioned in Andreas' slides on slide 18 [1] and allows a user
>> to perform 'info threads' and see the currently running and sleeping tasks.
>> Switching to a specific task, then functions as expected with 'thread NN', and
>> 'bt' to produce a back trace of that thread.
>>
>> Indeed this patch set hopes to satisfy Andreas' request in [2] to submit a
>> small patchset of the initial features. In this case, the thread awareness.
>>
>> Now that I have separated out the LKD code from the ST's internal STMC code,
>> it could also be possible to publish the larger project if it is of relevance,
>> though that will be heavier reading than this reduced patch.
>>
>> This implementation is in C and heavily derived from the implementation
>> created by ST, as the aim of the upstreaming project is to reuse as much
>> of the ST implementation as is reasonable.
>>
>> The python-ic version of this that I've been working on (gdb.Target) hits a
>> few problems, in guarding against infinite recursion as many of the python
>> API's end up calling back into the target layer, and exceptions in that layer
>> tend to make GDB crash in very un-user-friendly ways.
> 
> FWIW, I've continued to use your Python implementation and have extended
> it to meet our needs.  I haven't encountered the recursion you describe,
> but it may be that I haven't pushed it hard enough yet.  I think you're
> probably more focused on active targets while we're mostly working on dumps.

Yes, I believe it is due to the difference in target. You have the
(wonderful) luxury of parsing the task list once and then leaving it so :)

I have been able to provide an ARM register set up function, which then
allows me to update the thread list at the first instance, and examine
the backtraces of each thread, in the same fashion as yours - but I need
to be able to make it more dynamic.

I will need to be able to update the list after a target continues, and
hence have been trying to use the to_update_thread_list hook.

If a python implementation tries to check the GDB thread list from
within this hook (perhaps not an unreasonable thing to do given the
request) GDB tries to update the thread-list and ... well I'm sure you
see where that goes.

It seems similar with the register reads too. I have added in a static
variable to make sure the functions aren't re-enterered, but this is
seeming to upset GDB internally, if the Python then causes GDB to try to
request the registers, and they aren't yet available - we can end up
with GDB not having access to a thread PC and failing to unwind. It
feels a bit fragile when it can upset GDB so much, and so a viable
python interface would need to be able to protect against actions that
can be done in external python scripts.

If anyone from @gdb has ideas on how this protection could be done - I'd
love to hear them! (You guys know the internals much better than me of
course)


Hopefully not insurmountable problems of course - but ones that will
take time, and thought - which for this project has to be weighed up
against the existing solution (this patch set)

--
Regards

Kieran



> 
> -Jeff
>