From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 101824 invoked by alias); 23 Mar 2017 16:56:52 -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 101798 invoked by uid 89); 23 Mar 2017 16:56:51 -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,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=cents, endeavour, upside, undergone X-HELO: smtpo27.poczta.onet.pl Received: from smtpo27.poczta.onet.pl (HELO smtpo27.poczta.onet.pl) (213.180.142.158) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 23 Mar 2017 16:56:49 +0000 Received: from [192.168.2.253] (83-238-226-97.adsl.inetia.pl [83.238.226.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: freddie_chopin@op.pl) by smtp.poczta.onet.pl (Onet) with ESMTPSA id 3vpt4X1qCrzxyDf2; Thu, 23 Mar 2017 17:56:43 +0100 (CET) Message-ID: <1490288202.1231.9.camel@op.pl> Subject: Re: [OpenOCD-devel] Python API for supplying thread information? From: Freddie Chopin To: Daniel Krebs , openocd-devel@lists.sourceforge.net Cc: gdb Date: Thu, 23 Mar 2017 16:56:00 -0000 In-Reply-To: <220810f4-9843-d898-6947-e7eeeed3a1ed@daniel-krebs.net> References: <1490175792.1242.7.camel@op.pl> <220810f4-9843-d898-6947-e7eeeed3a1ed@daniel-krebs.net> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2017-03/txt/msg00052.txt.bz2 On Wed, 2017-03-22 at 18:51 +0100, Daniel Krebs wrote: > Hi Freddie, > > first of all, I feel the same way as you do. I'm one of those guys > who > have undergone the endeavour to add RTOS support to OpenOCD (in my > case > RIOT OS). All the problems (slow OpenOCD release cycle, hard-coded > offsets/desynchronized information description, messy implementations > in > OpenOCD) you described are true, I only want to add another > perspective. > While trying to add support for RIOT, there was kind of a chicken-egg > problem: without patches being merged in RIOT, you cannot test the > OpenOCD implementation as well as the other way around when merging > OpenOCD patches. Additionally, I've found it quite difficult to find > people reviewing those patches on the OpenOCD side (it is not merged > yet, I lost track of it). However, I totally understand that. Most of > use are doing this in our free-time and so on, so I'd say this > approach > doesn't scale so well anyway. Yes, that would be another issue with implementing such RTOS support. It gets pretty hard when you have to modify both the RTOS and OpenOCD, while _NOT_ being the developer of that RTOS. I forgot about that, as I have the "luxury" of being the developer of my own RTOS ( http://distortos.org/ ), so it's not a problem for me to add any support for such integration with OpenOCD and/or GDB. Especially because I see that as a thing of great importance! > I have some experience with GDB Python scripting (there are also > "new" > OSes on x86), but I ran into the same problem as you did. To my > knowledge (as of Dec 2016), there's no way to tell GDB about thread > structures. That's why I ended up working around that by switching > contexts myself. If it's of any help or interest to you, have a look > at [1]. > > I'm not sure if it's possible for OpenOCD to add such support. It > would > make more sense to do that upstream in GDB IMHO, but it's the right > direction. The upside of such an implemention is definetly that every > project can manage these scripts in-tree and in sync with their > development, with no dependency (as in providing patches) on OpenOCD > anymore. Exactly my thought - in that case the whole problem of "frozen" ABI is just gone! > Sadly, I cannot provide support on that matter at the moment because > I'm > lacking a use-case. Just wanted to add my 2 cents :) Thanks for the input! > Cheers, > Daniel > > > [1] https://github.com/RWTH-OS/HermitCore/tree/devel/usr/gdb Regards, FCh