From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 121429 invoked by alias); 23 Mar 2017 11:34:36 -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 121400 invoked by uid 89); 23 Mar 2017 11:34:34 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=providers, awareness, deeply, D*pl X-HELO: mail-pg0-f53.google.com Received: from mail-pg0-f53.google.com (HELO mail-pg0-f53.google.com) (74.125.83.53) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 23 Mar 2017 11:34:32 +0000 Received: by mail-pg0-f53.google.com with SMTP id t143so56501066pgb.2 for ; Thu, 23 Mar 2017 04:34:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=sQb4Kru/WXyKDxDjrmj8yU9+fE2ezrnKrCRNBlanDgE=; b=Dhbqrr5XdfzVVfAey/oKCoD6HVz4e6eDJ9syGtR6OieKu/5NRL37Gleg+Yd2e5zN1T SVTUDQOmWqDbg3cQ1mknzkOulb/E7b9fTib1X6wYuBfFQN4UqYucB/kJXgWxT8Q4A8Ks fhihnkAUSFoHwfcb6Ge12halAnPQlh/tWzTwc3zjkRIjt9A3SmhBJTVi2bmAd2uigGh+ 9N9OVo8mAlYbKvhupj0Gov65RBr9F2SHb1h87/1W7Ln0UACdzdqS+Y4YrUfEnsZ0Z0eA GmxwWzO9iHk/iQufXuttNTQsVCB/Qz7xtsYtHV1WLA0ak2WLcjsd0jRRq0f5XkKJ2m4y Ev+Q== X-Gm-Message-State: AFeK/H2Ej4mJzseP/pjziMmbfb8w1YAIcfArte3ZiDt2Yiuc3TU/7CGNyh0HFiF3PWdvEA== X-Received: by 10.99.163.72 with SMTP id v8mr2281031pgn.115.1490268872423; Thu, 23 Mar 2017 04:34:32 -0700 (PDT) Received: from E107787-LIN (gcc114.osuosl.org. [140.211.9.72]) by smtp.gmail.com with ESMTPSA id v26sm9808988pfl.16.2017.03.23.04.34.30 (version=TLS1_2 cipher=AES128-SHA bits=128/128); Thu, 23 Mar 2017 04:34:31 -0700 (PDT) From: Yao Qi To: Freddie Chopin Cc: Phil Muldoon , gdb@sourceware.org, openocd-devel@lists.sourceforge.net Subject: Re: Python API for supplying thread information? References: <1490175792.1242.7.camel@op.pl> <4b310e40-3f39-feed-6134-d2cfe68c4423@redhat.com> <1490199596.1410.3.camel@op.pl> Date: Thu, 23 Mar 2017 11:34:00 -0000 In-Reply-To: <1490199596.1410.3.camel@op.pl> (Freddie Chopin's message of "Wed, 22 Mar 2017 17:19:56 +0100") Message-ID: <86mvccuszh.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2017-03/txt/msg00047.txt.bz2 Freddie Chopin writes: >> Is it possible? Sure. But without looking at it in any real depth it >> would be a major undertaking. GDB does not have the concept of >> "Providers", it assembles state from many different sources: kernel, >> glibc, libthread_db etc. > > Please note that for deeply embedded target these concepts don't apply > - there's no standard "kernel" (usually there's also no separation > between application and kernel), glibc is too huge and none of the > "standard" facilities. From what I've seen=20 > The differences between "deeply embedded target" and PC doesn't matter here. As Phil said, GDB has to assemble state from different sources, including OpenOCD and others. >> This state is internally structured and >> relevant to GDB and is not really structured to receive arbitrary >> input from an API at the moment. It could, but I think it would >> require major surgery. > > Well, the info OpenOCD provides to GDB is structured quite nice. > Basically OpenOCD just returns a list of tuples consisting of: thread > name (string), thread extra info (string, in most implementation it's > the info about state) and the thread ID (opaque value). Then it also > informs GDB which of these is currently active. GDB may also request > the list of thread registers, from what I understand by providing > "thread ID" and expecting a string with registers as hex. > > All of that is done with GDB packets like "qThreadExtraInfo", > "qfThreadInfo", "qC" and some more. > > In this case it would be enough to just get all that data with the > Python script instead of querying GDB server (OpenOCD). OpenOCD can provide thread information because it embedded the RTOS internal knowledge into it, as you mentioned in challenge #2 in your first mail. IMO, it is a pain. In order to get rid of this pain completely, python script is needed to *provide* thread information to GDB by parsing some RTOS's data structures, so that OpenOCD don't need these C code to get OS-specific thread information at all. Providing thread info isn't just printing thread name and state in "info threads". GDB internally needs thread information too. > >> Currently the Scripting API is almost entirely focused with providing >> information and not really designed to take information. You have >> information providers APIs and data decorators APIs. > > I might got something wrong, but wouldn't this be an example of > "information provider API"? I agree with Phil. Some python APIs are needed to provide thread information to GDB, but they are missing in GDB now. Note that we are working Linux kernel awareness debugging in GDB, in which we get Linux specific information, for example, kernel threads, via C code. We thought about doing it in python two years ago, but decide to implement it C first, and then, add needed python interfaces in GDB and move the code to python if possible. --=20 Yao (=E9=BD=90=E5=B0=A7)