Re: gdb displaying only one line of instructions when stepping

On Tue, Dec 21, 2021 at 5:14 PM Andrea Monaco <[email protected]>
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?