public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
From: David Blaikie <dblaikie@gmail.com>
To: Andrea Monaco <andrea.monaco@autistici.org>
Cc: gdb <gdb@sourceware.org>
Subject: Re: gdb displaying only one line of instructions when stepping
Date: Tue, 21 Dec 2021 17:54:49 -0500	[thread overview]
Message-ID: <CAENS6EtxY=bUF31z99gnLz_x9sewDPf6pX5HE6GxDZTBSYX5Hw@mail.gmail.com> (raw)
In-Reply-To: <87bl19hagp.fsf@autistici.org>

On Tue, Dec 21, 2021 at 5:14 PM Andrea Monaco <andrea.monaco@autistici.org>
wrote:

>
>   > Though ultimately the DWARF format itself would probably need to be
>   > improved to describe source ranges (maybe even non-contiguous ones)
>   > and a preferred location - then then + operation could be described
>   > as the whole range of "x + y" with a specific location of '+', and
>   > the assignment could be the whole range of "a = x + y" with a
>   > specific location of '='.
>
>
> I looked up DWARF format a bit using the dwarfdump utility.  I see that
> DWARF records the line number of each new instruction.  Changing the
> format would be a lot of work;


^ Yeah, for sure. Would be quite a bit of work.


> but maybe some kind of heuristics might
> do the job.
>

Possibly - that gets into the realm of design judgments that I'm not
qualified to make much of an assessment of, as I don't work on gdb
generally (I mostly work on clang's debug info emission)

When single stepping, gdb could display all lines until the following
> instruction, excluding it, and also excluding blank lines and (perhaps)
> comments immediately before it.
>

Hmm, maybe? Not sure how that'll compare between Clang and GCC's (or other
compiler's) choice of source location for expressions, or how it might
break when macros or other things are involved (where the line may not move
forward in a regular way)..

At least with Clang's debug info, if you did this - it might not ever
trigger, because the next instruction will often be at a previous line (as
in the `a = b + c` example - the next line location after the '+' would be
earlier, at the '=' - I guess a direction agnostic definition could be used
and so in:
1: a
2: =
3: b
4: +
5: c

gdb could show lines 3 and 4 when stopped at '+' and, could show lines 2,
3, 4, and 5 when stopped at '='? That might be a bit
uncomfortable/haphazard to the user.

Not sure what GCC's line table looks like/how it'd appear - I /guess/ if it
always use the start of the subexpression, then it'd show line 2 and 3 for
the '+' (which might be pretty confusing, since that'd include the '='
line, but not include the '+' line) and then include lines 1-5 for the '='.


> As another rule, it might stop immediately (like it does now) when the
> current line is, or includes, the closing bracket of a function.  (I saw
> that gcc records the closing bracket as a separate instruction, even
> when it is on the same line as the last instruction of the function.)
>
>
> This heuristics may give reasonable results in many cases, or be a
> starting point.  What do you think?
>

Might be something that could be done - but I worry it'd be more confusing
than helpful. Maybe changing the default number of lines of source the
debugger shows from 1 to 3 or something, to provide a bit of context rather
than just a single line, would be sufficient?

  reply	other threads:[~2021-12-21 22:55 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-21 22:14 Andrea Monaco
2021-12-21 22:54 ` David Blaikie [this message]
  -- strict thread matches above, loose matches on Subject: below --
2021-12-21 14:15 Andrea Monaco
2021-12-21 14:21 ` David Blaikie

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='CAENS6EtxY=bUF31z99gnLz_x9sewDPf6pX5HE6GxDZTBSYX5Hw@mail.gmail.com' \
    --to=dblaikie@gmail.com \
    --cc=andrea.monaco@autistici.org \
    --cc=gdb@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).