From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 122209 invoked by alias); 7 Mar 2019 11:50:27 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 122200 invoked by uid 89); 7 Mar 2019 11:50:27 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy=pcb, examine, spell, jhb X-HELO: mail-qk1-f193.google.com Received: from mail-qk1-f193.google.com (HELO mail-qk1-f193.google.com) (209.85.222.193) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 07 Mar 2019 11:50:25 +0000 Received: by mail-qk1-f193.google.com with SMTP id m9so8789573qkl.4 for ; Thu, 07 Mar 2019 03:50:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=LJmUnUzRPcphmc0TVpgfy5KGi0Rgdrwx/cp9t6+zZg0=; b=Arm1QYBKi2TaAYVaATpy7yKDqj3CS6SAsnTtnxV9zchajIZN34Z4k2iePlcqL0T+cx eBbz/qCMwiVMiAtSePutWqfQKU3kgya4O1TTUf2yuqFwQf2wtE1NCpr5sY06fsJHwla4 Hb641XeVVlalLKpVfyYwBsJ295XPwt+nLTUnZwG93SEbsy0CBuDsuSqzGdChkEY3a5ke 0NVVRt6J51pn2oG+u77adRSbYEQkVFK05qeVSdrleP6EoOGhU+hF4Ma93ZmtuIoKJ48o E+pk2hlLT/NfXVD2TlGj0lTyJ/Bp6Ogs5WcsRAw4EPqwELSIAUa/j1k9It/nvyIXNlHe L93Q== MIME-Version: 1.0 References: <1548738199-9403-1-git-send-email-omair.javaid@linaro.org> <6c29e316-f1cb-ee65-bc0b-844cba5d74ad@FreeBSD.org> In-Reply-To: From: Omair Javaid Date: Thu, 07 Mar 2019 11:50:00 -0000 Message-ID: Subject: Re: [RFC PATCH 0/6] Support for Linux kernel thread aware debug To: John Baldwin Cc: GDB Patches , Pedro Alves , Philipp Rudo , Andreas Arnez , Peter Griffin , Ulrich Weigand , Kieran Bingham Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2019-03/txt/msg00140.txt.bz2 On Fri, 8 Feb 2019 at 13:54, Omair Javaid wrote: > > On Mon, 4 Feb 2019 at 22:52, John Baldwin wrote: > > > > On 2/4/19 1:12 AM, Omair Javaid wrote: > > > On Tue, 29 Jan 2019 at 22:30, John Baldwin 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. > > > > Ok. I'm not firmly tied to a specific naming scheme, and I'll defer to > > whatever the global maintainers prefer. > > > > > 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. > > > > So I don't have any formalized testing. :-/ For testing cross-debug of > > crash dumps I modified the libkvm library in FreeBSD's base system to > > support reading the kernel crash dump format of other architectures and > > can then generate a crash dump in a VM / qemu instance and copy it to a > > 64-bit x86 host to examine against a sysroot. However, most of my testing > > is just by using the kernel target as most of my work is FreeBSD kernel > > and userland stuff, so I exercise it that way. I do have various gdb scripts > > (still written in the ancient gdb script language from gdb 6.x rather than > > python) at github.com/bsdjhb/kdbg/tree/master/gdb They aren't generally > > useful on other kernels though and are specific to FreeBSD. > > > > In terms of features, the current FreeBSD patches support most FreeBSD > > architectures (sparc64 is untested and I haven't gotten stack traces on > > ppc to work right, though I think I can reuse what I just did for risc-v > > to fix ppc at some point). A few years ago I reworked the libkvm library > > in FreeBSD to support cross-debugging of crashdumps, so you can generally > > cross-debug crashdumps on FreeBSD. Currently this only works on a FreeBSD > > host because I haven't pulled out a portable version of libkvm that could > > be compiled on a non-FreeBSD host yet. It does support kernel modules by > > reusing the shared library interface. This is implemented by having a > > custom set of solib_ops that get attached to the kernel-specific gdbarch > > during that OSABI's init handler. It has some custom commands that are > > wrappers around 'thread N' that let you switch to a thread by process ID > > or kernel thread ID. The main things it requires of each architecture are > > a method for populating a regcache from a kernel thread register state > > ('struct pcb' on FreeBSD), and custom frame unwinders to walk across > > exception frames on the stack. Currently these are marked as signal frames > > so that GDB will unwind across them ok when you have a page fault in the > > kernel due to a NULL function pointer (other frame unwinders stop unwinding > > when they see a NULL pc, but signal frames can keep unwinding past those). > > > > I gave a talk a couple of years ago at a BSD conference about GDB that > > includes some kgdb slides. You can see the slides at > > https://people.freebsd.org/~jhb/papers/bsdcan/2016/slides.pdf if that is > > helpful. > > Thanks John. This is helpful. > > > > > -- > > John Baldwin > > > > Ping! I am going to be reworking the current patch-set accommodating the suggestions and comments I have received so far. Kindly post your comments in next week or so if there are any further other ideas/suggestions. Thanks!