From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.polymtl.ca (smtp.polymtl.ca [132.207.4.11]) by sourceware.org (Postfix) with ESMTPS id B74253851C3E for ; Mon, 29 Mar 2021 19:42:44 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org B74253851C3E 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 12TJgdp2008089 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 29 Mar 2021 15:42:43 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp.polymtl.ca 12TJgdp2008089 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) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id E70891E01F; Mon, 29 Mar 2021 15:42:38 -0400 (EDT) Subject: Re: Remote query for structure layout To: =?UTF-8?Q?Thomas_Wei=c3=9fschuh?= Cc: gdb@sourceware.org References: <0e328e95-5035-4de6-9b44-b83ffab38662@t-8ch.de> <51319e86-d463-475c-ad50-b998ac507463@t-8ch.de> From: Simon Marchi Message-ID: <63fba577-8dfd-f04b-2bc4-64645a084328@polymtl.ca> Date: Mon, 29 Mar 2021 15:42:38 -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: <51319e86-d463-475c-ad50-b998ac507463@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 19:42:39 +0000 X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org 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: , X-List-Received-Date: Mon, 29 Mar 2021 19:42:46 -0000 On 2021-03-29 1:33 p.m., Thomas Weißschuh wrote: > Hi! > > On Mo, 2021-03-29T12:05-0400, Simon Marchi wrote: >> 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`. >>> >> 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!". > > Good to know, I'll take a shot at 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. > > Would it not make more sense to report the type of a symbol as part of qSymbol? > Gated behind a qSupported flag "qSymbol:type+" or so? If it can easily be made in a backwards-compatible way (considering all permutations of old gdb / new gdb, old stub / new stub), sure. > What do you think about the dataformat of the qType response? > Should it be a homegrown textformat or XML which would be much easier to > extend. The problem with XML is that it would need to be parsed on the target side. We try to keep things simple on the target, because that may be on a constrained device, you don't want to have to include an XML-parsing library. XML the other way (from stub to GDB) is OK, because it's easy to produce some basic XML using printf, and GDB can link with an XML parsing library. So I would lean towards a home-grown format, but it's more work to ensure it is extensible if we want to include more information in the replies in the future. I don't know all the remote packets by heart, maybe there's one that already uses a scheme that could be re-used here. Otherwise, XML can certainly be used to start prototyping. With the appropriate abstractions in place, it should be relatively easy to swap the encoding for another one. Simon