public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Yao Qi <qiyaoltc@gmail.com>
To: Philipp Rudo <prudo@linux.vnet.ibm.com>
Cc: Peter Griffin <peter.griffin@linaro.org>,
	gdb-patches@sourceware.org,	yao.qi@arm.com,
	arnez@linux.vnet.ibm.com
Subject: Re: [RFC 0/7] Support for Linux kernel debugging
Date: Fri, 03 Feb 2017 17:45:00 -0000	[thread overview]
Message-ID: <20170203174521.GC11916@E107787-LIN> (raw)
In-Reply-To: <20170126141225.321a5bf6@ThinkPad>

On 17-01-26 14:12:25, Philipp Rudo wrote:
> > 
> > Live debug of a target is the main use case we are trying to support
> > with the linux-kthread patches. So for us on-going thread
> > synchronisation between GDB and the Linux target is a key feature we
> > need.
> 
> For us live debugging is more a nice-to-have. That's why we
> wanted to delay implementation of on-going synchronisation after the
> basic structure of our code was discussed on the mailing list. So we
> could avoid some work if we needed to rework it. Apparently we need to
> change this plan now ;)
>

Nowadays, when GDB debugs normal application, it has four target layers,

The current target stack is:

  - multi-thread (multi-threaded child process.)
  - native (Native process)
  - exec (Local exec file)
  - None (None)

when it debugs corefile, it becomes

The current target stack is:
  - core (Local core dump file)
  - exec (Local exec file)
  - None (None)

This same can apply to kernel debugging.  GDB can have the right target layer
(Peter's patch) and when GDB debugs kernel dump, GDB has the target layer
from your patch.  We can share something between these two target layers.
I think all code about parsing kernel data structures can be shared.
Even more, we can add a shared target layer for linux kernel debugging,
and live debugging target layer and dump debugging target layer can sit
on top it.  They can use the beneath linux kernel target layer to fetch
registers, get thread names, etc.

> > > Knowing
> > > this weakness i discussed quite long with Andreas how to improve
> > > it. In this context we also discussed the reavenscar-approach Peter
> > > is using. In the end we decided against this approach. In
> > > particular we discussed a scenario when you also stack a userspace
> > > target on top of the kernel target.  
> > 
> > How do you stack a userspace target on top with a coredump?
> 
> You don't. At least with the current code base it is impossible.
> 
> 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.

> > > In this case
> > > you would have three different views on threads (hardware, kernel,
> > > userspace). With the ravenscar-approach this scenario is impossible
> > > to implement as the private_thread_info is already occupied by the
> > > kernel target and the userspace would have no chance to use it.
> > > Furthermore you would like to have the possibility to switch
> > > between different views, i.e. see what the kernel and userspace
> > > view on a given process is.  
> > 
> > Is this a feature you are actively using today with the coredump
> > (stacking userspace)?
> 
> We are not using it, as discussed above. In particular with our dumps
> it is even impossible as we strip it of all userspace memory (a crash
> of our build server created a ~9 GB dump (kdump, kernelspace only)
> imagine adding all of userspace to that ...). But for live debugging or
> smaller systems it could be an interesting scenario to find bugs
> triggered by "buggy" userspace behavior.
> 

With MultiTarget in place, we need to somehow associate a function call
in one target to another function in another different target.  A
user-space program call a syscall and trap into kernel, GDB just associate
the user-space call stack on one target with the right kernel space call
stack in another target.  I remember some one presented something on
GDB show stack traces across over RPC calls in the GNU Cauldron several
years.  This is about live debugging.

-- 
Yao (齐尧)

  reply	other threads:[~2017-02-03 17:45 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-12 11:32 Philipp Rudo
2017-01-12 11:32 ` [RFC 6/7] Add privileged registers for s390x Philipp Rudo
2017-01-12 11:32 ` [RFC 2/7] Add libiberty/concat styled concat_path function Philipp Rudo
2017-01-12 12:00   ` Pedro Alves
2017-01-12 13:33     ` Philipp Rudo
2017-01-12 13:48       ` Pedro Alves
2017-01-12 15:09         ` Philipp Rudo
2017-01-12 15:42           ` Pedro Alves
2017-01-12 11:32 ` [RFC 3/7] Add basic Linux kernel support Philipp Rudo
2017-02-07 10:54   ` Yao Qi
2017-02-07 15:04     ` Philipp Rudo
2017-02-07 17:39       ` Yao Qi
2017-02-09  9:54         ` Philipp Rudo
2017-02-09 13:06     ` Yao Qi
2017-02-09 15:09       ` Philipp Rudo
2017-01-12 11:32 ` [RFC 5/7] Add commands for linux-kernel target Philipp Rudo
2017-01-12 11:32 ` [RFC 1/7] Convert substitute_path_component to C++ Philipp Rudo
2017-01-12 11:32 ` [RFC 7/7] Add S390 support for linux-kernel target Philipp Rudo
2017-01-12 17:09   ` Luis Machado
2017-01-13 11:46     ` Philipp Rudo
2017-02-06 15:52     ` Yao Qi
2017-02-06 18:48       ` Andreas Arnez
2017-01-12 12:56 ` [RFC 0/7] Support for Linux kernel debugging Philipp Rudo
2017-01-12 13:02 ` [RFC 4/7] Add kernel module support for linux-kernel target Philipp Rudo
2017-01-25 18:10 ` [RFC 0/7] Support for Linux kernel debugging Peter Griffin
2017-01-26 13:12   ` Philipp Rudo
2017-02-03 17:45     ` Yao Qi [this message]
2017-02-03 19:46       ` Andreas Arnez

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170203174521.GC11916@E107787-LIN \
    --to=qiyaoltc@gmail.com \
    --cc=arnez@linux.vnet.ibm.com \
    --cc=gdb-patches@sourceware.org \
    --cc=peter.griffin@linaro.org \
    --cc=prudo@linux.vnet.ibm.com \
    --cc=yao.qi@arm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).