Re: [RFC v3 3/8] Add basic Linux kernel support

[Andreas Arnez <arnez at linux dot vnet dot ibm dot com>]

On Fri, May 19 2017, John Baldwin wrote:

> On Friday, May 19, 2017 07:05:47 PM Andreas Arnez wrote:
>> On Fri, May 19 2017, John Baldwin wrote:
>> 
>> > FreeBSD's kernel GDB bits (which I maintain) have a similar issue, though for
>> > now we only export kernel threads as threads in GDB and don't support CPUs as
>> > a GDB-visible thing.  In some ways the model I would personally like would be
>> > to have conceptual "layers" that you can bounce up and down between kind of
>> > like a stack, but in this case a stack of thread targets, so that I could do
>> > a kind of 'thread_down' and now 'info threads' would only show me CPUs, allow
>> > me to select CPUs, etc. but then have a 'thread_up' to pop back up to the
>> > kernel thread layer.
>> 
>> Exactly!  Note that GDB already has a stack of "layers" -- the target
>> stack.  Thus I'm considering commands like "target up/down" for this
>> purpose.  Of course this requires per-target thread lists.
>
> Yes, a target up/down might work.  Right now you can push/pop targets so in
> theory you can do this today with "target push kthread" and then "target pop".
> I hadn't played with this enough to know if that would be sufficient or not
> or if we wanted the targets to be more persistent to avoid having to recreate
> the thread list during each push.  One thing I wanted to look at in more
> detail is how this interaction worked for the older M:N threading targets.
> FreeBSD used to use M:N threading in userland but abandoned that a while ago.
> The old thread target for that used libthread_db and you only had the one
> thread list, never a way to pop back down to the LWP view.

Right, it might be interesting how that interaction worked.  If you gain
any insight, please share.  From a quick glance at these targets I had
the impression that they didn't work at all with the remote target
beneath them.

--
Andreas