gdb: only update m_last_subfile after writing a line table entry

While working on another patch which changes how we parse the line
DWARF line tables I noticed what I think is a minor bug in how we
process the line tables.

What I noticed is that my new line table parser was adding more END
markers into the parsed table than GDB's current approach.  This
difference was observed when processing the debug information for
libstdc++.

Here is the line table from the new test, this is a reasonable
reproduction of the problem case that I observed in the actual debug
line table:

  Contents of the .debug_line section:

  dw2-skipped-line-entries-1.c:
  File name                        Line number    Starting address    View    Stmt
  dw2-skipped-line-entries-1.c             101            0x40110a               x

  /tmp/dw2-skipped-line-entries-2.c:
  dw2-skipped-line-entries-2.c             201            0x401114               x

  /tmp/dw2-skipped-line-entries-3.c:
  dw2-skipped-line-entries-3.c             301            0x40111e               x

  /tmp/dw2-skipped-line-entries-1.c:
  dw2-skipped-line-entries-1.c             102            0x401128               x
  dw2-skipped-line-entries-1.c             103            0x401128               x
  dw2-skipped-line-entries-1.c             104            0x401128               x

  /tmp/dw2-skipped-line-entries-2.c:
  dw2-skipped-line-entries-2.c             211            0x401128

  /tmp/dw2-skipped-line-entries-3.c:
  dw2-skipped-line-entries-3.c             311            0x401132

  /tmp/dw2-skipped-line-entries-1.c:
  dw2-skipped-line-entries-1.c             104            0x40113c
  dw2-skipped-line-entries-1.c             105            0x401146               x
  dw2-skipped-line-entries-1.c               -            0x401150

The problem is caused by the entry for line 211.  Notice that this
entry is at the same address as the previous entries.  Further, the
entry for 211 is a non-statement entry, while the previous entries are
statement entries.

As the entry for line 211 is a non-statement entry, and the previous
entries at that address are statement entries in a different symtab,
it is thought that it is better to prefer the earlier entries (in
dw2-skipped-line-entries-1.c), and so the entry for line 211 will be
discarded.

As GDB parses the line table it switches between the 3 symtabs (based
on source filename) adding the relevant entries to each symtab.
Additionally, as GDB switches symtabs, it adds an END entry to the
previous symtab.

The problem then is that, for the line 211 entry, this is the only
entry in dw2-skipped-line-entries-2.c before we switch symtab again.
But the line 211 entry is discarded.  This means that GDB switches
from dw2-skipped-line-entries-1.c to dw2-skipped-line-entries-2.c, and
then on to dw2-skipped-line-entries-3.c without ever adding an entry
to dw2-skipped-line-entries-2.c.

And here then is the bug.  GDB updates its idea of the previous symtab
not when an entry is written into a symtab, but every time we change
symtab.

In this case, when we switch to dw2-skipped-line-entries-3.c we add
the END marker to dw2-skipped-line-entries-2.c, even though no entries
were written to dw2-skipped-line-entries-2.c.  At the same time, no
END marker is ever written into dw2-skipped-line-entries-1.c as the
dw2-skipped-line-entries-2.c entry (for line 211) was discarded.

Here is the 'maint info line-table' for dw2-skipped-line-entries-1.c
before this patch:

  INDEX  LINE   REL-ADDRESS        UNREL-ADDRESS      IS-STMT PROLOGUE-END EPILOGUE-BEGIN
  0      101    0x000000000040110a 0x000000000040110a Y
  1      END    0x0000000000401114 0x0000000000401114 Y
  2      102    0x0000000000401128 0x0000000000401128 Y
  3      103    0x0000000000401128 0x0000000000401128 Y
  4      104    0x0000000000401128 0x0000000000401128 Y
  5      104    0x000000000040113c 0x000000000040113c
  6      105    0x0000000000401146 0x0000000000401146 Y
  7      END    0x0000000000401150 0x0000000000401150 Y

And after this patch:

  INDEX  LINE   REL-ADDRESS        UNREL-ADDRESS      IS-STMT PROLOGUE-END EPILOGUE-BEGIN
  0      101    0x000000000040110a 0x000000000040110a Y
  1      END    0x0000000000401114 0x0000000000401114 Y
  2      102    0x0000000000401128 0x0000000000401128 Y
  3      103    0x0000000000401128 0x0000000000401128 Y
  4      104    0x0000000000401128 0x0000000000401128 Y
  5      END    0x0000000000401132 0x0000000000401132 Y
  6      104    0x000000000040113c 0x000000000040113c
  7      105    0x0000000000401146 0x0000000000401146 Y
  8      END    0x0000000000401150 0x0000000000401150 Y

Notice that we gained an extra entry, the END marker that was added at
position #5 in the table.

Now, does this matter?  I cannot find any bugs that trigger because of
this behaviour.

So why fix it?  First, the current behaviour is inconsistent, as we
switch symtabs, we usually get an END marker in the previous symtab.
But occasionally we don't.  I don't like things that are inconsistent
for no good reason.  And second, as I said, I want to change the line
table parsing.  To do this I want to check that my new parser creates
an identical table to the current parser.  But my new parser naturally
"fixes" this inconsistency, so I have two choices, do extra work to
make my new parser bug-compatible with the current one, or fix the
current one.  I'd prefer to just fix the current line table parser.

There's a test that includes the above example and checks that the END
markers are put in the correct place.  But as I said, I've not been
able to trigger any negative behaviour from the current solution, so
there's no test that exposes any broken behaviour.

Approved-By: Tom Tromey <tom@tromey.com>

0 files changed, 0 insertions, 0 deletions