From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id 2360NcL6YWCmTAAAWB0awg (envelope-from ) for ; Mon, 29 Mar 2021 12:05:22 -0400 Received: by simark.ca (Postfix, from userid 112) id CECC41E965; Mon, 29 Mar 2021 12:05:22 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-0.7 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,RDNS_DYNAMIC,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (ip-8-43-85-97.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id AF3401E590 for ; Mon, 29 Mar 2021 12:05:21 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 3F2C7385702E; Mon, 29 Mar 2021 16:05:21 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 3F2C7385702E DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1617033921; bh=yQDkTphazoXll3p/MsGypuDyB1nBpvQcfuvHnxsNcRk=; h=Subject:To:References:Date:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To: From; b=YOdmRq0eAI4Vso6f9NMQKnVuwqROCA1AK0aLUmPch3gJVUQ7GU5Om852lPxTS4dbQ gdfp7+o4WO5dO66lrac8Bzr/FKU4YDoBlBen5gSneipeRTmxTklKEMZNDHPGemtcYc q9gcNHK4njlXYvPAXDBEK88RSEKd6AbK7sKgp8EM= Received: from smtp.polymtl.ca (smtp.polymtl.ca [132.207.4.11]) by sourceware.org (Postfix) with ESMTPS id 073B8385702E for ; Mon, 29 Mar 2021 16:05:18 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 073B8385702E Received: from simark.ca (simark.ca [158.69.221.121]) (authenticated bits=0) by smtp.polymtl.ca (8.14.7/8.14.7) with ESMTP id 12TG5D7r023055 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 29 Mar 2021 12:05:17 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp.polymtl.ca 12TG5D7r023055 Received: from [10.0.0.11] (192-222-157-6.qc.cable.ebox.net [192.222.157.6]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id DCFCC1E590; Mon, 29 Mar 2021 12:05:12 -0400 (EDT) Subject: Re: Remote query for structure layout To: =?UTF-8?Q?Thomas_Wei=c3=9fschuh?= , gdb@sourceware.org References: <0e328e95-5035-4de6-9b44-b83ffab38662@t-8ch.de> Message-ID: Date: Mon, 29 Mar 2021 12:05:11 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: <0e328e95-5035-4de6-9b44-b83ffab38662@t-8ch.de> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Poly-FromMTA: (simark.ca [158.69.221.121]) at Mon, 29 Mar 2021 16:05:13 +0000 X-BeenThere: gdb@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Simon Marchi via Gdb Reply-To: Simon Marchi Errors-To: gdb-bounces@sourceware.org Sender: "Gdb" On 2021-03-28 7:06 a.m., Thomas Weißschuh wrote:> Hi everybody, > > I would like to propose a new command for the remote protocol that can be used to > query structure layouts. > Essentially a `qSymbol` equivalent for the output of `ptype`. > > Background: > > The RTOS-support in OpenOCD has to read in-memory datastructures of the debug > target to reconstruct the threading information for GDB. > For example for FreeRTOS this is done by first looking up the scheduler > datastructure via `qSymbol` and then doing hardcoded pointer arithmetic based on > the retrieved symbol addresses. > (https://repo.or.cz/openocd.git/blob/HEAD:/src/rtos/FreeRTOS.c#l60) > > Unfortunately the specific offsets inside the structures can change based on > compilation options of FreeRTOS. > > If GDB could report the information it already has from the debug information > (as shown in `ptype /o`) via its remote protocol then the logic in OpenOCD > could be more robust. > > Ideas: > > While a simple mapping of (structure name, member name) -> (offset) mapping > would be enough for my usecase it would probably be better to report more data. > > * type of a typename (struct, union) > * total size of the type > * all members of the type including their own type and offsets > > Example: > > # request info for type "foo_t" > IN qType:666f6f5f74 > # "foo_t" is a struct of size 32 and members: > # * bar_t bar at offset 0 > # * baz_t baz at offset 16 > OUT qType:666f6f5f74:struct:32:0;6261725f74;626172,16;62617a5f74;62617a > > (Or some XML equivalent) > > Is this something that would fit into gdb? > > Regards, > Thomas Hi, I think that would make sense. We already help the stub look up some things in the debugged process using qSymbol, so it would be a bit silly to say "now you're on your own to interpret it!". If we go there, we could also help the stub make the link between the symbol and its type, so that you don't have to hardcode that symbol "foo" is of type "foo_t". For example, if you could also pass a symbol name (like pxCurrentTCB) to qType, you wouldn't have to hardcode its type name in the openocd source code, it's one less thing that can go wrong. Or it could be another packet that does symbol name to type name, which you then pass to qType. Simon