From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 38824 invoked by alias); 26 Mar 2017 13:58:45 -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 38806 invoked by uid 89); 26 Mar 2017 13:58:44 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.2 required=5.0 tests=AWL,BAYES_20,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=Steven, steven, importance, Freddie X-HELO: smtpo59.poczta.onet.pl Received: from smtpo59.poczta.onet.pl (HELO smtpo59.poczta.onet.pl) (213.180.142.190) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sun, 26 Mar 2017 13:58:41 +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 3vrdzZ6bNvzljxY5; Sun, 26 Mar 2017 15:58:34 +0200 (CEST) Message-ID: <1490536713.1290.4.camel@op.pl> Subject: Re: [OpenOCD-devel] Python API for supplying thread information? From: Freddie Chopin To: Steven Stallion Cc: Daniel Krebs , OpenOCD ML , gdb Date: Sun, 26 Mar 2017 13:58:00 -0000 In-Reply-To: References: <1490175792.1242.7.camel@op.pl> <220810f4-9843-d898-6947-e7eeeed3a1ed@daniel-krebs.net> <1490288202.1231.9.camel@op.pl> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2017-03/txt/msg00059.txt.bz2 On Thu, 2017-03-23 at 12:38 -0500, Steven Stallion wrote: > > On Thu, Mar 23, 2017 at 11:56 AM, Freddie Chopin l> wrote: > > 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! > > > > Why do you need to modify your RTOS? If this is a case where you need > additional information at runtime, take a look under contrib at the > RTOS helpers for FreeRTOS and uC/OS-III. This should give you an idea > of how you can supplement the image under test with information you > need for transient information like struct offsets. You have > unfettered access to memory, so there's nothing holding you back or > requires you to alter the RTOS source code. It's not that I "need" to. I was just referring to the chicken-egg problem mentioned earlier - if you are a "third party" (not OpenOCD developer, not the developer of the RTOS in question), then just adding these structures with RTOS mapping to the RTOS repository may pose a problem. I know that these can be put into contrib/ folder of OpenOCD, but I'm pretty certain that it's much better if such structs are part of the main RTOS repository, which allows them to be maintained and "in sync". Regards, FCh