Re: [RFC 0/7] Support for Linux kernel debugging

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

On Fri, Feb 03 2017, Yao Qi wrote:

> On 17-01-26 14:12:25, Philipp Rudo wrote:

[...]

>> Andreas and I see the ravenscar-approach as a workaround for
>> limitations in GDB. Thus while discussing it we thought about possible
>> scenarios for the future which would be impossible to implement using
>> this approach. The userspace-on-kernel was just meant to be an example.
>> Other examples would be a Go target where the libthreaddb
>> (POSIX-threads) and Go (goroutines) targets would compete on
>> thread stratum. Or (for switching targets) a program that runs
>> simultaneous on CPU and GPU and needs different targets for both code
>> parts.
>>  
>
> IMO, https://sourceware.org/gdb/wiki/MultiTarget is the right way to
> solve such problem.  We can have one JTAG remote target debugging kernel,
> and one GDBserver debugging user-space app on that machine.

Interesting thought; I haven't looked much into that yet.  This would
only be applicable to live debugging, though, right?

Philipp's and my line of thought was more directed towards an extension
of the current target stack.  We considered the possibility to have a
target stack like this:

  - goroutine (Goroutine)
  - multi-thread (multi-threaded child process.)  <-- linux-thread-db
  - lk-user (User-space task) <-- focuses on one user-space process
  - lk-thread (Linux kernel threads) <-- uses the kernel's task list
  - core (Local core dump file) <-- "threads" are actually CPUs
  - exec (Local exec file)
  - None (None)

I.e., having multiple thread layers stacked one atop another.  In this
scenario the user should be able to specify which layer to focus on,
going up and down in the hierarchy.  When at the lk-thread layer, "info
threads" would show kernel threads; when at the "goroutine" layer, it
would show the Goroutines of a certain user-space process in the given
system dump.  Some of these layers would have their own notion of exec
file, solibs, symbols, etc.

The layers above "core" would generally apply to a running target as
well.

Of course, this is a long-range vision and not something I'd expect to
be implemented as part of the Linux kernel debugging support.  For now
we'd just need the lk-thread layer, where mostly just the thread list
needs to be overridden.  And such a "thread-only" layering
infrastructure would also be usable for a goroutine layer in a usual
user-space debugging scenario.

--
Andreas