public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Tom Tromey <tom@tromey.com>
To: Simon Marchi via Gdb-patches <gdb-patches@sourceware.org>
Subject: Re: [PATCH 0/1] Integrate GNU poke in GDB
Date: Thu, 13 May 2021 11:04:58 -0600	[thread overview]
Message-ID: <87wns24lad.fsf@tromey.com> (raw)
In-Reply-To: <9f1f3ee3-f31e-2941-3f6b-f54552f5c16b@polymtl.ca> (Simon Marchi via Gdb-patches's message of "Mon, 10 May 2021 14:39:08 -0400")

>>>>> "Simon" == Simon Marchi via Gdb-patches <gdb-patches@sourceware.org> writes:

Simon> I don't find this super clear, as we could always see it both
Simon> ways.

One my pet peeves about autoconf is that the --with/--enable distinction
is too subtle to ever remember or care about.  Like, what would it mean
if a program had both --enable-x and --with-x?  I think it would be
better to just declare them as synonyms.

Simon> From target_read_raw_memory's doc:

Simon> /* Like target_read_memory, but specify explicitly that this is a read
Simon>    from the target's raw memory.  That is, this read bypasses the
Simon>    dcache, breakpoint shadowing, etc.  */

Simon> So, it bypasses a cache in GDB (not sure why that's important).

gdb tries to cache some memory to avoid excess requests to the remote.
This matters if you have a slow connection.

>> - How can I demangle C++ identifiers?  And how can I detect when
>> a given type is a C++ one that needs demangling?

Simon> I think that we usually rely on the language of the compilation unit, as
Simon> given by DWARF, to know that a symbol has a C++ mangled name and needs
Simon> demangling.

I can't remember if I mentioned this elsewhere, but type names aren't
normally mangled.  Symbol names for variables or functions can be, but
gdb already does the demangling if you use the correct accessor.

Tom

  parent reply	other threads:[~2021-05-13 17:05 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-10 15:10 Jose E. Marchesi
2021-05-10 15:10 ` [PATCH 1/1] " Jose E. Marchesi
2021-05-10 16:56   ` Eli Zaretskii
2021-05-10 18:49     ` Jose E. Marchesi
2021-05-10 18:52       ` Eli Zaretskii
2021-05-11  7:33   ` Andrew Burgess
2021-05-11 13:07     ` Jose E. Marchesi
2021-05-12  8:52       ` Andrew Burgess
2021-05-12 10:14         ` Jose E. Marchesi
2021-05-13 16:59   ` Tom Tromey
2021-05-10 18:39 ` [PATCH 0/1] " Simon Marchi
2021-05-10 20:07   ` Jose E. Marchesi
2021-05-11  6:25     ` Andrew Burgess
2021-05-13 17:04   ` Tom Tromey [this message]
2021-05-11 18:56 ` Tom Tromey
2021-05-12  8:06   ` Jose E. Marchesi
2021-05-13 15:52     ` Tom Tromey
2021-05-14 20:52       ` Jose E. Marchesi

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=87wns24lad.fsf@tromey.com \
    --to=tom@tromey.com \
    --cc=gdb-patches@sourceware.org \
    /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).