public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
From: Simon Marchi <simon.marchi@polymtl.ca>
To: "Thomas Weißschuh" <thomas@t-8ch.de>, gdb@sourceware.org
Subject: Re: Remote query for structure layout
Date: Mon, 29 Mar 2021 12:05:11 -0400	[thread overview]
Message-ID: <c920fa93-ffc9-25db-e678-e7367e961b20@polymtl.ca> (raw)
In-Reply-To: <0e328e95-5035-4de6-9b44-b83ffab38662@t-8ch.de>

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

  reply	other threads:[~2021-03-29 16:05 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-28 11:06 Thomas Weißschuh
2021-03-29 16:05 ` Simon Marchi [this message]
2021-03-29 17:33   ` Thomas Weißschuh
2021-03-29 19:42     ` Simon Marchi
2021-03-29 20:02       ` Philippe Waroquiers
2021-03-29 20:10         ` Simon Marchi
2021-03-29 20:20           ` Philippe Waroquiers
     [not found] <mailman.6.1616932808.1485743.gdb@sourceware.org>
2021-03-30 20:35 ` Tim Newsome
2021-03-30 21:33   ` Simon Marchi
2021-03-30 21:41     ` David Blaikie
2021-03-30 21:49       ` Simon Marchi
2021-03-30 22:03         ` David Blaikie
2021-03-30 22:38           ` Simon Marchi
2021-03-30 22:44             ` David Blaikie
2021-03-31  0:16               ` Simon Marchi
2021-03-31  3:27                 ` David Blaikie
2021-03-31 13:00                   ` Simon Marchi
2021-04-02 22:05                     ` David Blaikie
2021-04-03 19:39                       ` Simon Marchi
2021-03-31 14:06                   ` Tim Newsome

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=c920fa93-ffc9-25db-e678-e7367e961b20@polymtl.ca \
    --to=simon.marchi@polymtl.ca \
    --cc=gdb@sourceware.org \
    --cc=thomas@t-8ch.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).