From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 118689 invoked by alias); 31 Mar 2017 10:55:51 -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 118669 invoked by uid 89); 31 Mar 2017 10:55:49 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=guy, Hx-languages-length:2825, freddie, basically X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 31 Mar 2017 10:55:47 +0000 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id C7003437F4F; Fri, 31 Mar 2017 10:55:47 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com C7003437F4F Authentication-Results: ext-mx05.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx05.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=gbenson@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com C7003437F4F Received: from blade.nx (unknown [10.33.36.30]) by smtp.corp.redhat.com (Postfix) with ESMTP id 5F29B71D63; Fri, 31 Mar 2017 10:55:47 +0000 (UTC) Received: by blade.nx (Postfix, from userid 1000) id BF094816CC34; Fri, 31 Mar 2017 11:55:45 +0100 (BST) Date: Fri, 31 Mar 2017 10:55:00 -0000 From: Gary Benson To: Freddie Chopin Cc: Pierre-Marie de Rodat , Liviu Ionescu , gdb@sourceware.org, openocd-devel Subject: Re: [OpenOCD-devel] Python API for supplying thread information? Message-ID: <20170331105545.GA26820@blade.nx> References: <1490175792.1242.7.camel@op.pl> <8FB0BA0B-F013-48A6-965B-AEF4B69610EC@livius.net> <6b759808-b486-64c1-6624-c622cad8a46e@adacore.com> <1490205142.1410.5.camel@op.pl> <1490287804.1231.7.camel@op.pl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1490287804.1231.7.camel@op.pl> X-IsSubscribed: yes X-SW-Source: 2017-03/txt/msg00063.txt.bz2 Hi, I'm the guy who did the Infinity talk at Cauldron... Freddie Chopin wrote: > On Thu, 2017-03-23 at 10:23 +0100, Pierre-Marie de Rodat wrote: > > What makes you think that? My understanding of the design is that > > it's centered on adding new metadata sections to ELF binaries and > > make the debugger use this metedata. This looks quite > > embedded-friendly to me. > > Maybe I got the wrong impression, sorry. But the problem is that > this project doesn't seem very active... Generally fragmenting the > effort (yet another library with yet another standard and so on...) > doesn't seem like a very good idea to me, that's why in my opinion a > solution implemented completely in GDB would be better suited and > would have a higher chance of "survival" and "adoption". But I might > got the wrong impression again. > > However me and Liviu had a discussion about describing RTOS > structure in a generic way and I'm still pretty certain that this is > generally not possible in a generic and agnostic way. In the end it > would become either extremely complex or you'd have to implement > some kind of scripting/code to actually deal with that. Infinity is active, but it's just me, and I've had some distractions that've kept me from making progress of late. I think it could do what you're asking. I'm not super-familiar with embedded systems but I assume you're using GDB talking to something via the remote protocol? Here's how I see it working: * There's some information you need from the remote. I'll use the example that you have a numeric thread ID and you want that thread's priority, which is also a number. * You write an Infinity function, called thread::priority_for_ID or something. That function gets compiled by the Infinity note compiler and lives in the executable. Possibly in your case it would be stripped from the binary the embedded system sees, but present in the binary GDB sees. [Note this is future work: Infinity functions are always unstripped at present.] The function you wrote is basically things like "read this register, add this other thing to it, read this memory". * GDB loads the binary, it has the Infinity functions. * Your pretty printer is able to get the information it requires by calling the Infinity function you wrote via a Python API in GDB. [Note again, this part is future work, there's no such API at present.] * GDB executes the Infinity function you wrote, deferring to the remote for register and memory reads using existing remote protocol features. This can all be done without adding extra features to the remote--the Infinity function is executed by GDB. It's not something that's weeks away from release, but if you want to lend a hand? ;) Cheers, Gary -- https://gbenson.net/