Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Hannes Domani <ssbssa@yahoo.de>
To: Gdb-patches <gdb-patches@sourceware.org>
Subject: Re: [RFC][PATCH 0/6] Step program considering the source column information
Date: Wed, 27 May 2020 16:04:19 +0000 (UTC)	[thread overview]
Message-ID: <1062200567.878277.1590595459490@mail.yahoo.com> (raw)
In-Reply-To: <56760df2-b642-c112-2a16-89320a2fba0e@suse.de>

 Am Mittwoch, 27. Mai 2020, 17:33:37 MESZ hat Tom de Vries <tdevries@suse.de> Folgendes geschrieben:

> On 16-05-2020 19:26, Hannes Domani via Gdb-patches wrote:
> > Basically, this implements the new commands nextc (nc) and stepc (sc),
> > which allow to step through the program until an instruction is reached,
> > that belongs to another source column (according to the debug information).
> >
> > The current column location is visualized in the frame info, and in the TUI.
> >
> > Also, the column information is added to 'maint info line-table' and the
> > python line table interface.
> >
> > Since the frame info output is different, this certainly breaks the
> > testsuite, so this column indicator needs a parameter to disable, but I
> > wasn't concerned about this yet.
> >
> > With the example code from PR25913, it looks like this:
> >
> > (gdb) start
> > Temporary breakpoint 2 at 0x40162d: file gdb-25911.c, line 4.
> > Starting program: C:\src\tests\gdb-25911.exe
> >
> > Temporary breakpoint 2, main () at gdb-25911.c:4
> > 4        int a = 4;
> >              ^
> > (gdb) nc
> > 6        a = 5; a = 6; a = 7;
> >            ^
> > (gdb) nc
> > 6        a = 5; a = 6; a = 7;
> >                    ^
> > (gdb) nc
> > 6        a = 5; a = 6; a = 7;
> >                          ^
> > (gdb) nc
> > 8        return 0;
> >
> >
> > What do you think of this so far?
> >
>
> Very nice :)
>
> As I've just learned by looking at this (
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95360 ) PR, interesting
> code in relation to this patch series is dwarf_record_line_p.
>
> The function implements filtering of line-table elements, and has as
> related test-case gdb.dwarf2/dw2-single-line-discriminators.exp.
>
> If we disable the filtering (by returning 1 at the end instead of 0), we
> get for test-case gdb.dwarf2/dw2-single-line-discriminators.exp:
> ...
> Temporary breakpoint 2, main () at
> gdb.dwarf2/dw2-single-line-discriminators.c:26
> 26        x = 0;
> (gdb) n
> 28        for (i = 0; i < 10; ++i) continue; /* stepi line */
> (gdb) si
> 28        for (i = 0; i < 10; ++i) continue; /* stepi line */
> ...
>
> That is: no progress is visible after the stepi.  If we re-enable the
> filtering, we have:
> ...
> Temporary breakpoint 1, main () at
> gdb.dwarf2/dw2-single-line-discriminators.c:26
> 26        x = 0;
> (gdb) n
> 28        for (i = 0; i < 10; ++i) continue; /* stepi line */
> (gdb) si
> 0x00000000004004cd      28        for (i = 0; i < 10; ++i) continue; /*
> stepi line */
> ...
>
> So, progress is visible.
>
> If we now use your patch series, and with the filtering enabled, we have:
> ...
> Temporary breakpoint 1, main () at
> gdb.dwarf2/dw2-single-line-discriminators.c:26
> 26        x = 0;
>           ^
> (gdb) n
> 28        for (i = 0; i < 10; ++i) continue; /* stepi line */
>               ^
> (gdb) si
> 0x00000000004004cd      28        for (i = 0; i < 10; ++i) continue; /*
> stepi line */
>                                       ^
> (gdb)
> 0x00000000004004d1      28        for (i = 0; i < 10; ++i) continue; /*
> stepi line */
>                                       ^
> (gdb)
> 0x00000000004004d3      28        for (i = 0; i < 10; ++i) continue; /*
> stepi line */
>                                       ^
> (gdb)
> 0x00000000004004d5      28        for (i = 0; i < 10; ++i) continue; /*
> stepi line */
>                                       ^
> ...
>
> So, we see progress in the insn addresses, but the column does not progress.
>
> OTOH, if we disable filtering:
> ...
> Temporary breakpoint 1, main () at
> gdb.dwarf2/dw2-single-line-discriminators.c:26
> 26        x = 0;
>           ^
> (gdb) n
> 28        for (i = 0; i < 10; ++i) continue; /* stepi line */
>               ^
> (gdb) si
> 28        for (i = 0; i < 10; ++i) continue; /* stepi line */
>               ^
> (gdb) si
> 0x00000000004004d1      28        for (i = 0; i < 10; ++i) continue; /*
> stepi line */
>                                       ^
> (gdb) si
> 28        for (i = 0; i < 10; ++i) continue; /* stepi line */
>                                   ^
> (gdb) si
> 28        for (i = 0; i < 10; ++i) continue; /* stepi line */
>                               ^
> (gdb) si
> 0x00000000004004d8      28        for (i = 0; i < 10; ++i) continue; /*
> stepi line */
>                                                       ^
> ...
> we don't see progress after the first stepi, but eventually we do see
> progress in the column.
>
> Looking at the line-info:
> ...
>   [0x00000147]  Set column to 8
>   [0x00000149]  Special opcode 161: advance Address by 11 to 0x4004c6
> and Line by 2 to 28
>   [0x0000014a]  Extended opcode 4: set Discriminator to 4
>   [0x0000014e]  Special opcode 103: advance Address by 7 to 0x4004cd and
> Line by 0 to 28
> ...
> perhaps we we should collapse entries that have the same column, so
> something like this in dwarf_record_line_p:
> ...
>   if (line != last_line)
>     return 1;
>   if (colum != last_column)
>     return 1;
>
>   return 0;
>
> ...

Interesting.
I'm just wondering, if dwarf_record_line_p merges all entries of the same line,
why does my column-based stepping even work at all?

Is it because of line_has_non_zero_discriminator?
If yes, what is the discriminator?


Hannes


  reply	other threads:[~2020-05-27 16:04 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20200516172632.4803-1-ssbssa.ref@yahoo.de>
2020-05-16 17:26 ` Hannes Domani
2020-05-16 17:26   ` [PATCH 1/6] Add column information of dwarf to the symbol information Hannes Domani
2020-05-18 16:17     ` Tom Tromey
2020-05-19 12:23       ` Luis Machado
2020-05-16 17:26   ` [PATCH 2/6][PR gdb/25913] Implement nextc and stepc commands Hannes Domani
2020-05-16 17:26   ` [PATCH 3/6] Add column information to maint info line-table Hannes Domani
2020-05-16 17:26   ` [PATCH 4/6] Add LineTableEntry.column to python line table interface Hannes Domani
2020-05-27 13:50     ` Tom de Vries
2020-05-27 14:36       ` Tom Tromey
2020-05-16 17:26   ` [PATCH 5/6][PR gdb/25911] Show column of current execution point in frame info Hannes Domani
2020-05-18 16:20     ` Tom Tromey
2020-05-18 16:37       ` Hannes Domani
2020-05-19 14:51         ` Tom Tromey
2020-05-16 17:26   ` [PATCH 6/6] Show column of current execution point in TUI Hannes Domani
2020-05-16 18:45   ` [RFC][PATCH 0/6] Step program considering the source column information Pedro Alves
2020-05-17  0:08     ` Hannes Domani
2020-05-18 16:21   ` Tom Tromey
2020-05-18 16:28     ` Hannes Domani
2020-05-19 12:27   ` Luis Machado
2020-05-19 16:02     ` Hannes Domani
2020-05-27 15:33   ` Tom de Vries
2020-05-27 16:04     ` Hannes Domani [this message]
2020-06-02  9:08       ` Tom de Vries

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=1062200567.878277.1590595459490@mail.yahoo.com \
    --to=ssbssa@yahoo.de \
    --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