public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Simon Farre <simon.farre.cx@gmail.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: gdb-patches@sourceware.org
Subject: Re: [PATCH v1] [gdb/infcmd]: Add next-expression command
Date: Wed, 24 May 2023 10:18:33 +0200	[thread overview]
Message-ID: <c5c8f8d1-5a49-7d41-c686-23b85d149f10@gmail.com> (raw)
In-Reply-To: <83v8gpvp0j.fsf@gnu.org>

[-- Attachment #1: Type: text/plain, Size: 2094 bytes --]


>   The "source-level" part is clear, but what about "stepping to
> columns"?  The command steps by expressions, not by columns.

Well, the column metadata is essentially emitted for expressions and 
statements (or "logical breakpoint locations"), but the actual meta data 
that is recorded is by column (and a statement flag), so we can't really 
be _entirely_ sure that what we're stepping to is an expression or 
statement, even though that is what it's /intended/ to represent. Which 
is why I used column and expression interchangeably.

Perhaps further explanation is required here, or possibly even renaming 
the feature to `next-column` and `step-column` for the two variants that 
I've implemented; where the `step` variant behaves similarly to what the 
normal step/next counterparts do; i.e. if there's an inline frame on the 
same source file (like a lambda or callback) then step will step into 
it, whereas next will step over it. The 2 variants will be in the 
upcoming v3.

> There's no need for too much detail, if this is an old feature.  Just
> say something like
>
>    The support for expressions was added to DWARF2 30 years ago, so any
>    compiler which emits DWARF2 debug info should nowadays produce the
>    information required by this command.  E.g., GCC supports this since
>    version <put here the version of GCC>.
>
> (Assuming it is true that every compiler released reasonably recently
> will produce this as part of DWARF debug info.)
Right, I've only tested with the latest, but I'm pretty sure that the 
last 4-5 years of compilers at least emit column meta data. I've tested 
gcc-12, clang-14 and the latest rustc compiler (I know rustc has emitted 
it for at _least_ 5 years). I'm building gcc-8 (5+ years) as I write 
this and will test that. Where in the manual would you like me to put 
the above paragraph? Together with the documentation of the command or 
somewhere else? And the same question goes for
> We need to explain in the manual that the "columns" actually are (or
> are likely to be) byte offsets from the beginning of the source line.

  reply	other threads:[~2023-05-24  8:18 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-16  9:47 Simon Farre
2023-05-16 15:18 ` Eli Zaretskii
2023-05-18 11:12   ` Simon Farre
2023-05-18 11:48     ` Eli Zaretskii
2023-05-24  8:18       ` Simon Farre [this message]
2023-05-24 11:14         ` Eli Zaretskii
2023-05-24 16:01           ` Simon Farre

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=c5c8f8d1-5a49-7d41-c686-23b85d149f10@gmail.com \
    --to=simon.farre.cx@gmail.com \
    --cc=eliz@gnu.org \
    --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).