From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 124032 invoked by alias); 2 Oct 2015 10:56:15 -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 124019 invoked by uid 89); 2 Oct 2015 10:56:14 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,T_RP_MATCHES_RCVD autolearn=no version=3.3.2 X-HELO: e06smtp11.uk.ibm.com Received: from e06smtp11.uk.ibm.com (HELO e06smtp11.uk.ibm.com) (195.75.94.107) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (CAMELLIA256-SHA encrypted) ESMTPS; Fri, 02 Oct 2015 10:56:14 +0000 Received: from /spool/local by e06smtp11.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 2 Oct 2015 11:56:10 +0100 Received: from d06dlp03.portsmouth.uk.ibm.com (9.149.20.15) by e06smtp11.uk.ibm.com (192.168.101.141) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Fri, 2 Oct 2015 11:56:08 +0100 X-MailFrom: arnez@linux.vnet.ibm.com X-RcptTo: gdb@sourceware.org Received: from b06cxnps3074.portsmouth.uk.ibm.com (d06relay09.portsmouth.uk.ibm.com [9.149.109.194]) by d06dlp03.portsmouth.uk.ibm.com (Postfix) with ESMTP id BEB971B08072 for ; Fri, 2 Oct 2015 11:57:55 +0100 (BST) Received: from d06av09.portsmouth.uk.ibm.com (d06av09.portsmouth.uk.ibm.com [9.149.37.250]) by b06cxnps3074.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id t92Au7Vq30605384 for ; Fri, 2 Oct 2015 10:56:07 GMT Received: from d06av09.portsmouth.uk.ibm.com (localhost [127.0.0.1]) by d06av09.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id t92Au7oD008346 for ; Fri, 2 Oct 2015 04:56:07 -0600 Received: from oc1027705133.ibm.com (dyn-9-152-212-195.boeblingen.de.ibm.com [9.152.212.195]) by d06av09.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id t92Au7Sd008306 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 2 Oct 2015 04:56:07 -0600 From: Andreas Arnez To: Peter Griffin Cc: gdb@sourceware.org, lee.jones@linaro.org Subject: Re: RFC GDB Linux Awareness analysis References: <20150603142858.GA19370@griffinp-ThinkPad-X1-Carbon-2nd> <20150930132729.GB26183@griffinp-ThinkPad-X1-Carbon-2nd> Date: Fri, 02 Oct 2015 10:56:00 -0000 In-Reply-To: <20150930132729.GB26183@griffinp-ThinkPad-X1-Carbon-2nd> (Peter Griffin's message of "Wed, 30 Sep 2015 14:27:29 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 15100210-0041-0000-0000-000005FC5619 X-IsSubscribed: yes X-SW-Source: 2015-10/txt/msg00006.txt.bz2 On Wed, Sep 30 2015, Peter Griffin wrote: > Hi Andreas, > > On Thu, 20 Aug 2015, Andreas Arnez wrote: > > [...] >> So I believe posting the patches to get more feedback would be >> worth-while. > > Ok, so the existing LKD code is on quite an old GDB version > (7.6). Also the whole LKD patchset is currently quite large (15k > LoC). So my plan was to try and reduce this as much as possible by > removing parts of LKD that can (or already have) python > implementations e.g. dmesg. > > Essentially the aim would be to try and reduce the LKD patchset as > much as possible to the "core features" which I consider to be task > awareness and loadable module support. At this point we could look at > what might need adding to the GDB python API to migrate even more > parts into python. > > Posting the whole patchset currently would involve porting to the > latest GDB version and before doing that I'd like to get a better idea > of what parts are likely to need re-writing or at least only ports the > necessary parts. I suggest to start with a small patch set that can be reviewed easily -- and changed, if necessary. Such as loadable modules support, or whatever else you deem best suited for laying the foundations for this project. And then see how it goes. >[...] > > Does anyone have experience / thoughts on how often the existing threading > implementations that are already inside GDB break? Presumably these are also > tightly coupled to parsing out of tree data structures (or the libraries which > GDB relies on to do this). > > I'm trying to get a feel for what the current maintenance burden is like having > these implementations in C. A user-space runtime usually has some sort of "debug interface" which gives certain guarantees about reliable breakpoint targets and data structure layouts. Such a convention allows the GDB support to stay pretty stable. Ideally the Linux kernel runtime provides a similar interface. For instance, see the description of do_init_module() in module.c: /* * This is where the real work happens. * * Keep it uninlined to provide a reliable breakpoint target, e.g. for the gdb * helper command 'lx-symbols'. */ One thing we haven't addressed so far is testing. Usually a new GDB feature should come with a regression test case, such that it's less likely to break after unrelated changes. Maybe we can put various vmlinux- and associated crash dump binaries into the test suite, along with a test case that loads/analyzes those. However, such binaries can grow fairly large (many Giga- or even Terabytes), so I'm not sure whether this is a viable option. Maybe remove everything from the binaries that is irrelevant to the test case? Other ideas for testing? -- Andreas