From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 82521 invoked by alias); 23 Mar 2017 16:50:12 -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 82480 invoked by uid 89); 23 Mar 2017 16:50:12 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: =?ISO-8859-1?Q?No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=survival, the=c2, adoption, impression?= 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; Thu, 23 Mar 2017 16:50:10 +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 3vpsws3Vv0z1JV87M; Thu, 23 Mar 2017 17:50:04 +0100 (CET) Message-ID: <1490287804.1231.7.camel@op.pl> Subject: Re: [OpenOCD-devel] Python API for supplying thread information? From: Freddie Chopin To: Pierre-Marie de Rodat , Liviu Ionescu Cc: gdb@sourceware.org, openocd-devel Date: Thu, 23 Mar 2017 16:50:00 -0000 In-Reply-To: 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> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2017-03/txt/msg00051.txt.bz2 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. Regards, FCh