public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
From: Simon Marchi <simon.marchi@polymtl.ca>
To: David Blaikie <dblaikie@gmail.com>
Cc: Tim Newsome <tim@sifive.com>, gdb <gdb@sourceware.org>
Subject: Re: Remote query for structure layout
Date: Sat, 3 Apr 2021 15:39:39 -0400	[thread overview]
Message-ID: <b5691fdb-bd20-0f97-4aea-12c4da6c6fe4@polymtl.ca> (raw)
In-Reply-To: <CAENS6Eteo7ZwOatL8yQ=Zp9fpMmqwNi4d8T9ixoz-zKW=kjMJA@mail.gmail.com>

On 2021-04-02 6:05 p.m., David Blaikie wrote:
> One possibly "cheap" way would be for FreeRTOS to use the structure in
> C code to do the register stashing - rather than or in addition to/in
> some kind of hybrid manner along with the assembly. If that's not
> possible/would make the code harder to understand, then finding some
> other way to pin the data structure into the DWARF would be needed.
> 
> I'd be inclined to avoid adding a new attribute or other feature
> (though I wouldn't be entirely opposed to it - I can certainly think
> of other places where it may be useful to have a "whenever the
> compiler sees this type, ensure it makes it into the resulting DWARF
> no matter what" attribute) if reasonably possible - instead finding
> some lowest-common-denominator/highly reliable signal that compilers
> use to emit type information.
> 
> The simplest such signal is a global variable of the type (not a
> pointer to it, but of the type itself) - though probably has to be
> annotated in some way that ensures the compiler won't optimize the
> variable away even under LTO, etc. I'm not sure sure off-hand if I
> have a great way to do that portably (non-portably I guess there's
> various "exported" attributes that ensure the entity is visible even
> beyond the shared library/executable scope, and thus can't be
> optimized away - maybe such an attribute would be sufficiently
> portable for FreeRTOS's needs (ie: no less portable than the rest of
> the code already)).
> If such a variable would be problematic (taking up space in the image,
> etc) - maybe there's a way to ensure it through an extra nonce
> parameter (if it's C++ code, a parameter with a default argument - so
> the caller never has to think about it) to some core FreeRTOS function
> that won't be optimized away/removed as unused/etc. Again, has a
> runtime impact, though - maybe if it was zero-size (like a class
> template specialization with no members) & with the type as a template
> parameter /maybe/ that would suffice...
> 
> Happy to play around with mechanisms like that if it's of interest.

Ok, good to know that the intent is now clear.  I have no real opinion
on how this is achieved, since I am neither a FreeRTOS, OpenOCD or compiler
developer :).

Tim, Thomas: as for the GDB implementation part, feel free to send a
patch on gdb-patches, even if it's just a prototype.

Simon

  reply	other threads:[~2021-04-03 19:39 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [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 [this message]
2021-03-31 14:06                   ` Tim Newsome
2021-03-28 11:06 Thomas Weißschuh
2021-03-29 16:05 ` Simon Marchi
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

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=b5691fdb-bd20-0f97-4aea-12c4da6c6fe4@polymtl.ca \
    --to=simon.marchi@polymtl.ca \
    --cc=dblaikie@gmail.com \
    --cc=gdb@sourceware.org \
    --cc=tim@sifive.com \
    /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).