From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 95065 invoked by alias); 14 May 2019 22:04:44 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 95057 invoked by uid 89); 14 May 2019 22:04:43 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-3.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,TBC autolearn=no version=3.3.1 spammy=informed, vanilla, bringing, gun X-HELO: us-smtp-delivery-195.mimecast.com Received: from us-smtp-delivery-195.mimecast.com (HELO us-smtp-delivery-195.mimecast.com) (63.128.21.195) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 14 May 2019 22:04:40 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=datto.com; s=mimecast20190208; t=1557871478; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:openpgp:autocrypt; bh=TuAlzjmj35rSSrF0EOKpU2h7/OknS2cPzSc8Tm1Sx6Y=; b=GEZoZkK3H1+cgJuvORGa0CGJvXmeLKPA0KZWRUutxTPRIiRQ3pY+ZaozuWaH4ZATMfcui1 V6SgCFYv3kI7h2/4p7roMzrWLkJ/xBuzwTpZhGjuGNV/UYd17HXsDB2EjLWVyGSCAaKGFa HIdoNdHAWu02c4G1JKnbBfa59q2NNs4= Received: from mail-wr1-f70.google.com (mail-wr1-f70.google.com [209.85.221.70]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-258-QEzfXnATO6Oc0Y_wPet86A-1; Tue, 14 May 2019 18:04:37 -0400 Received: by mail-wr1-f70.google.com with SMTP id n9so216558wrq.12 for ; Tue, 14 May 2019 15:04:37 -0700 (PDT) MIME-Version: 1.0 References: <20190514094921.3f08044a@laptop-ibm> In-Reply-To: <20190514094921.3f08044a@laptop-ibm> From: Thomas Caputi Date: Wed, 15 May 2019 13:28:00 -0000 Message-ID: Subject: Re: Linux kernel debugging and other features To: Philipp Rudo Cc: gdb@sourceware.org, Florian Weimer , Dave Anderson X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2019-05/txt/msg00026.txt.bz2 I apologize, but after speaking with some of the people at Delphix I may have made things a little more confusing than they should have been and spoken a bit sooner than I should have. To simplify the current status, we should probably divide this conversation into 2 topics. First is the set of lower-level changes to gdb that allow it to read and understand the linux kernel and kdumps, both of which were largely done by Jeff, although we adapted some of his code to be able to work with live systems via /proc/kcore. In this sub-category, there are 2 main bodies of work. First is the bits of python code that inform gdb how to interpret kernel memory and gather things like threads and per-cpu variables so that it can present them normally. This code works for both live and post-mortem systems. Second is the "kdump" target which consists of (1) some patches to gdb to allow targets to be written in python, (2) libkdumpfile (a separate library for parsing kdump files), and (3) the kdump target itself which creates a python target using libkdumpfile. Since this code is mostly Jeff's work (as far as I am aware) we are going to work with him to see what he would like to do / what his plans are. Second is the set of gdb extensions written in python that allow custom sub-commands to be piped together. These were written completely by the folks at Delphix and should work with vanilla gdb with or without Jeff's work. As for this work I have been informed that they would like a little more time to polish the code, so perhaps we can table this discussion for a bit until the code is ready. So, in short, I think I jumped the gun a little bit in bringing these changes to this mailing list. I think we still have a little more work and polishing to do before we are ready to share everything. At this point I guess we will come back to this discussion when things are more ready. Thanks, Tom On Tue, May 14, 2019 at 10:16 AM Philipp Rudo wrote: > > Hi Tom, > > that really sounds like a great piece of code you are having. A little ba= ck I > worked at a similar project with focus on dump debugging on s390 [1]. > Unfortunately the project never made it beyond the prototype... > > My approach back then was to include everything directly into GDB without > using any python scripts whatsoever. All in all it worked quite well and > allowed walking the task_struct and converting them to gdb threads, > create backtrace of kernel threads and loading kernel modules as 'shared > libraries'. > > However there where also some drawbacks. As it was directly included into= gdb > only elf dumps could be inspected. The virtual address translation was a > little bit shaky as addresses in gdb are represented by simple ulongs wit= hout > any information about the address space. Furthermore I concentrated on > post-mortem dumps, exactly for the problems you describe below... > > Anyway, I'm thrilled to have a look at your code and see how you are solv= ing > those problems. > > I'm not sure if Florian's suggestion to add the code to crash is the prop= er > way. Crash is based on a 7.6 gdb. So it's already quite old and probably > doesn't have all the functionality you need. Nevertheless I CCed Dave > Anderson, the crash maintainer. I guess he's interested in this discussio= n as > well. > > Back when I was working on my project I didn't have the impression that t= here > was any fundamental objections in adding the feature to gdb. It basically > depends on your implementation to solve the problem. So for the next step= , I'd > suggest you simply post your patches to the gdb-patches list and we take = the > discussion from there. > > Thanks > Philipp > > [1] https://sourceware.org/ml/gdb-patches/2018-03/msg00243.html > > On Mon, 13 May 2019 16:19:49 -0400 > Thomas Caputi wrote: > > > Hello gdb, > > > > My name is Tom Caputi and I am a developer for ZFS on Linux. Recently, > > I had the opportunity to work with some members of Delphix (another > > major ZFS on Linux contributor) to build some debugging tools. > > > > When we started working on this project we were surprised to see how > > close gdb was to supporting this kernel debugging natively. For live > > systems, we were able to use the kernel's vmlinux file from the dbgsym > > package (after mucking around for a bit with KASLR offsets) along with > > /proc/kcore as a core file to inspect just about any non-local > > variable on the system. > > > > For inspecting post-mortem kdumps we found that Jeff Mahoney had > > already been working on this > > (https://github.com/jeffmahoney/crash-python). Kdump files are > > compressed and use a different on-disk format from regular core files, > > but he was able to create a new "kdump" target type to support that. > > His work also included code that allowed us to load the symbols for > > kernel modules with their correct offsets. > > > > Jeff also has a python script that was able to parse out Linux's list > > of task_struct structures (which represent all threads on the system > > threads) and hand them to gdb. This allowed us to switch threads and > > view stack traces with function arguments just as we could when using > > gdb to debug a userspace program. > > > > On top of all of this, members of the Delphix team were able to put > > together some code to allow some custom gdb sub-commands (written in > > python) to be piped together comparable to the way commands can be > > piped together in bash. By doing this we were able to put together a > > few relatively simply commands to get some really powerful debugging > > output. > > > > Currently, all of this is still in the proof-of-concept stage, but I > > think both Datto (my company) and Delphix would like to look to the > > next steps to get these improvements integrated upstream and > > stabilized. We think these could be a huge improvement to the current > > situation of debugging any code in the Linux kernel. However, there > > are some sticky bits that we would like to discuss if the gdb > > community is interested in these changes: > > > > 1) The kdumpfile support currently requires a few custom patches added > > to gdb that allow a user to create a custom target in python. The > > kdumpfile target is then implemented as a python module that calls out > > to libkdumpfile (written in c). I'm not sure if this is the desired > > implementation of this feature. If it is not, could we get some > > pointers for how we could add this support to gdb? > > > > 2) The /proc/kcore file *looks* like a core file, but it is constantly > > changing underneath us as the live system changes. When debugging code > > we had issues where values that should be changing were cached and > > appeared to remain static. We were able to reduce the gdb cache size > > to 2 bytes (I think) by running 'set stack-cache off; set code-cache > > off; set dcache size 1; set dcache line-size 2', but this still > > results in (at least) the last variable you inspected being cached > > until you look at something else. Is there a way we can completely > > disable the dcache? > > > > 3) We aren't 100% sure where all of the new code belongs. The > > ZFS-specific debugging commands we can definitely keep in the ZFS > > repository, but the sub-command piping infrastructure could be useful > > to anyone using gdb. We're also not really sure where the scripts that > > parse out kernel structures (for things like threads and per-cpu > > variables) should end up. > > > > Please let us know if you are interested in any of these changes and > > let us know what some good next steps would be. >