From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 51164 invoked by alias); 4 Feb 2019 17:52:19 -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 51155 invoked by uid 89); 4 Feb 2019 17:52:19 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_PASS autolearn=ham version=3.3.2 spammy=H*r:sk:server-, H*r:sk:client-, gotten X-HELO: mx2.freebsd.org Received: from mx2.freebsd.org (HELO mx2.freebsd.org) (8.8.178.116) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 04 Feb 2019 17:52:17 +0000 Received: from mx1.freebsd.org (mx1.freebsd.org [96.47.72.80]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (Client CN "mx1.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx2.freebsd.org (Postfix) with ESMTPS id A7624962F9; Mon, 4 Feb 2019 17:52:15 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id ED74D6A5AC; Mon, 4 Feb 2019 17:52:14 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from John-Baldwins-MacBook-Pro-3.local (ralph.baldwin.cx [66.234.199.215]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id DEE61468B; Mon, 4 Feb 2019 17:52:13 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Subject: Re: [RFC PATCH 0/6] Support for Linux kernel thread aware debug To: Omair Javaid Cc: GDB Patches , Pedro Alves , Philipp Rudo , Andreas Arnez , Peter Griffin , Ulrich Weigand , Kieran Bingham References: <1548738199-9403-1-git-send-email-omair.javaid@linaro.org> <6c29e316-f1cb-ee65-bc0b-844cba5d74ad@FreeBSD.org> From: John Baldwin Openpgp: preference=signencrypt Message-ID: Date: Mon, 04 Feb 2019 17:52:00 -0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: ED74D6A5AC X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-2.96 / 15.00]; local_wl_from(0.00)[FreeBSD.org]; NEURAL_HAM_MEDIUM(-0.99)[-0.989,0]; NEURAL_HAM_SHORT(-0.98)[-0.976,0]; ASN(0.00)[asn:11403, ipnet:96.47.64.0/20, country:US]; NEURAL_HAM_LONG(-1.00)[-0.999,0] X-IsSubscribed: yes X-SW-Source: 2019-02/txt/msg00016.txt.bz2 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. -- John Baldwin                                                                            Â