public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Omair Javaid <omair.javaid@linaro.org>
To: John Baldwin <jhb@freebsd.org>
Cc: GDB Patches <gdb-patches@sourceware.org>,
	Pedro Alves <palves@redhat.com>,
		Philipp Rudo <prudo@linux.ibm.com>,
	Andreas Arnez <arnez@linux.vnet.ibm.com>,
		Peter Griffin <peter.griffin@linaro.org>,
	Ulrich Weigand <Ulrich.Weigand@de.ibm.com>,
		Kieran Bingham <kieran@linuxembedded.co.uk>
Subject: Re: [RFC PATCH 0/6] Support for Linux kernel thread aware debug
Date: Mon, 04 Feb 2019 09:13:00 -0000	[thread overview]
Message-ID: <CANW4E-3M0YwrNnaujP5DNDD50JR3YLZJTx8pHMOAgbw1DNuXPQ@mail.gmail.com> (raw)
In-Reply-To: <6c29e316-f1cb-ee65-bc0b-844cba5d74ad@FreeBSD.org>

On Tue, 29 Jan 2019 at 22:30, John Baldwin <jhb@freebsd.org> wrote:
>
> On 1/28/19 9:03 PM, Omair Javaid wrote:
> > This patch series implements linux kernel target which allows linux kernel
> > tasks to be viewed as GDB threads. We have had multiple set of patches
> > submitted over last few years aiming to insert add-ons into GDB for debugging
> > Linux kernel. This patch series builds on top of Linux kernel infrastructure
> > submitted by Philipp Rudo in his various sets of patches aiming to debug
> > Linux kernel dumps.
>
> I just have one minor suggestion / comment about file names.  I maintain
> FreeBSD kernel patches for gdb out-of-tree (for various reasons), and those
> patches use some similar things (e.g. a different OSABI).  My comment has
> to do with the filenames.  Other osabi-specific files tend to use more
> verbose names such as 'linux-arm-nat.c'.  I wonder if it makes sense to
> spell out linux here as well.  I have been using 'arm-fbsd-kern.c' as a
> complement to 'arm-fbsd-tdep.c' for the kernel gdbarch.  The architecture
> independent files follow the patter 'fbsd-k*.c' (e.g. fbsd-kld.c for modules
> and fbsd-kthr.c for thread enumeration), but I would be happy to move those
> to something like 'fbsd-kern-ld.c' and 'fbsd-kern-thr.c'.  For your current
> patchset that might mean something like 'linux-kern-tdep.c' instead of
> 'lk-tdep.c'.  I would also be fine with 'arm-linux-kern-tdep.c' instead of
> 'arm-linux-kern.c' perhaps if other folks feel like that is more consistent.

Hi John,

Andreas has aptly described the reason behind choosing the
nomenclature of new linux kernel specific files as it is right now and
i am open to any suggestion that my come up during reviews.

Also I was wondering if you can share details of kernel debugging
features which has implemented in your out of tree FreeBSD patches for
GDB. Also share some insight on ways to test this patchset.

Thanks!

>
> --
> John Baldwin
>
>

  parent reply	other threads:[~2019-02-04  9:13 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-29  5:03 Omair Javaid
2019-01-29  5:03 ` [RFC PATCH 2/6] Add libiberty/concat styled concat_path function Omair Javaid
2019-01-29  5:03 ` [RFC PATCH 3/6] Add scoped_restore_regcache_ptid Omair Javaid
2019-01-29  5:03 ` [RFC PATCH 1/6] Convert substitute_path_component to C++ Omair Javaid
2019-01-29  5:04 ` [RFC PATCH 5/6] Linux kernel thread awareness Arm target support Omair Javaid
2019-01-29  5:04 ` [RFC PATCH 6/6] Linux kernel thread awareness AArch64 " Omair Javaid
2019-01-29  5:04 ` [RFC PATCH 4/6] Linux kernel debug infrastructure and target Linux kernel Omair Javaid
2019-01-29 17:50   ` John Baldwin
2019-01-31 11:43     ` Philipp Rudo
2019-01-31 16:14   ` Philipp Rudo
2019-02-04  9:35     ` Omair Javaid
2019-02-05 14:15       ` Philipp Rudo
2019-02-08  8:53         ` Omair Javaid
2019-01-29 17:30 ` [RFC PATCH 0/6] Support for Linux kernel thread aware debug John Baldwin
2019-01-30 15:02   ` Andreas Arnez
2019-02-04  9:13   ` Omair Javaid [this message]
2019-02-04 17:52     ` John Baldwin
2019-02-08  8:54       ` Omair Javaid
2019-03-07 11:50         ` Omair Javaid

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=CANW4E-3M0YwrNnaujP5DNDD50JR3YLZJTx8pHMOAgbw1DNuXPQ@mail.gmail.com \
    --to=omair.javaid@linaro.org \
    --cc=Ulrich.Weigand@de.ibm.com \
    --cc=arnez@linux.vnet.ibm.com \
    --cc=gdb-patches@sourceware.org \
    --cc=jhb@freebsd.org \
    --cc=kieran@linuxembedded.co.uk \
    --cc=palves@redhat.com \
    --cc=peter.griffin@linaro.org \
    --cc=prudo@linux.ibm.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).