From: Philipp Rudo <prudo@linux.vnet.ibm.com>
To: Peter Griffin <peter.griffin@linaro.org>
Cc: gdb-patches@sourceware.org, palves@redhat.com,
brobecker@adacore.com, kevinb@redhat.com, cagney@gnu.org,
dje@google.com, drow@false.org, kettenis@gnu.org,
yao.qi@arm.com, stanshebs@google.com,
Ulrich.Weigand@de.ibm.com, elena.zannoni@oracle.com,
eliz@gnu.org, arnez@linux.vnet.ibm.com
Subject: Re: [PATCH] Linux kernel thread runtime support
Date: Wed, 15 Feb 2017 16:45:00 -0000 [thread overview]
Message-ID: <20170215174512.3ee9c6a4@ThinkPad> (raw)
In-Reply-To: <1482427864-4317-1-git-send-email-peter.griffin@linaro.org>
Hi Peter,
while looking into your patch in more detail, I found some problems
with your code. In particular I dislike your general approach using
private_thread_info, since the remote-target already uses this field
inside thread_info. Thus "forcibly" adding your own version of
private_thread_info, like you do, can lead to undefined behavior. For
example remote_stopped_by_sw_breakpoint requires information from
private_tread_info and won't work reliably. Even worse, remote_resume
you call by passing target_resume to the target beneath writes (via
resume_clear_thread_private_info) to the private_thread_info thus
causing a memory corruption.
With your and the remote-target being that interlaced, I don't think
it's possible to separate them cleanly. That's why I see no other way
than allowing each target to manage its own thread list.
Philipp
On Thu, 22 Dec 2016 17:31:03 +0000
Peter Griffin <peter.griffin@linaro.org> wrote:
> Hi GDB maintainers,
>
> The following patch implements a Linux kernel thread runtime stratum
> which can be used when using GDB to debug a Linux kernel. For example
> when connecting to a QEMU GDB stub, or OpenOCD which then communicates
> with the target via JTAG or SWD.
>
> This patch is a refactored version based on the 'Linux kernel
> debugger' GDB plugin written at STMicroelectronics which used to
> be packaged with their JTAG debuggers. There has been some discussion
> previously on the list by myself [1], Kieran [2] and one of the
> original authors at ST Marc Titinger [3].
>
> This patchset I'm hoping is a lot closer to something which can
> be upstreamed to GDB project after some discussion about structure
> with Yao Qi at Linaro Connect, the code has been refactored to be
> structured much more like the existing upstream thread runtimes (such
> as ravenscar-thread.c and sparc-ravenscar-thread etc).
>
> Since the original email [1] various helper commands have also been
> migrated into python and merged into the Linux kernel source tree.
> The GDB python extensions, combined with the linux-kthread GDB
> thread runtime implemented in this patchset provide a powerful
> Linux kernel debug solution, and is a working implementation
> of what Andreas talked about on slide 17 and 18 of his talk at GNU
> Cauldron [4].
>
> I have currently been testing this patchset using mainline GDB
> debugging arm-linux kernels in Qemu and via OpenoCD to real hardware.
> It is straight forward with the current strructure to add new
> architecture support, and I'm looking at adding PowerPC so I can
> easily validate big endian targets.
>
> What I'm really hoping for now is some patch review on the GDB
> mailing list from the GDB maintainers and community with a view to
> getting this functionality which has been talked about for quite a
> few years finally merged to the upstream GDB project.
>
> All patch review feedback greatfully received :)
>
> kind regards,
>
> Peter.
>
> [1] https://cygwin.com/ml/gdb/2015-09/msg00032.html
> [2] https://www.sourceware.org/ml/gdb/2016-01/msg00028.html
> [3]
> https://lists.linaro.org/pipermail/linaro-toolchain/2011-November/001754.html
> [4]
> https://gcc.gnu.org/wiki/cauldron2015?action=AttachFile&do=view&target=Andreas+Arnez_+Debugging+Linux+kernel+dumps+with+GDB.pdf
>
>
>
> Peter Griffin (1):
> Add Linux kernel thread runtime support.
>
> gdb/ChangeLog | 12 +
> gdb/Makefile.in | 8 +-
> gdb/arm-linux-kthread.c | 178 +++++
> gdb/arm-linux-kthread.h | 27 +
> gdb/arm-tdep.c | 4 +
> gdb/configure.tgt | 6 +-
> gdb/gdbarch.c | 23 +
> gdb/gdbarch.h | 5 +
> gdb/gdbarch.sh | 3 +
> gdb/linux-kthread.c | 1828
> +++++++++++++++++++++++++++++++++++++++++++++++
> gdb/linux-kthread.h | 223 ++++++ 11 files changed, 2311
> insertions(+), 6 deletions(-) create mode 100644
> gdb/arm-linux-kthread.c create mode 100644 gdb/arm-linux-kthread.h
> create mode 100644 gdb/linux-kthread.c
> create mode 100644 gdb/linux-kthread.h
>
next prev parent reply other threads:[~2017-02-15 16:45 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-22 17:34 Peter Griffin
2016-12-22 17:34 ` [PATCH] Add " Peter Griffin
[not found] ` <20170111111210.GJ9518@E107787-LIN>
2017-01-20 12:05 ` Peter Griffin
2017-01-03 12:55 ` [PATCH] " Philipp Rudo
2017-01-10 15:56 ` Peter Griffin
2017-01-12 13:02 ` Philipp Rudo
2017-01-25 12:43 ` Peter Griffin
2017-01-26 11:38 ` Philipp Rudo
2017-02-15 16:45 ` Philipp Rudo [this message]
2017-02-20 14:48 ` Peter Griffin
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=20170215174512.3ee9c6a4@ThinkPad \
--to=prudo@linux.vnet.ibm.com \
--cc=Ulrich.Weigand@de.ibm.com \
--cc=arnez@linux.vnet.ibm.com \
--cc=brobecker@adacore.com \
--cc=cagney@gnu.org \
--cc=dje@google.com \
--cc=drow@false.org \
--cc=elena.zannoni@oracle.com \
--cc=eliz@gnu.org \
--cc=gdb-patches@sourceware.org \
--cc=kettenis@gnu.org \
--cc=kevinb@redhat.com \
--cc=palves@redhat.com \
--cc=peter.griffin@linaro.org \
--cc=stanshebs@google.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