Re: [PATCHv2 2/2] gdb: Add support for tracking the DWARF line table is-stmt field

[Andrew Burgess <andrew.burgess@embecosm.com>]

* Tom Tromey <tom@tromey.com> [2020-03-17 12:23:49 -0600]:

> Tom> Actually, when I back out the hunk, I get:
> Tom>     Breakpoint 1 at 0x80000042: file r.h, line 6.
> Tom> However, in the past it appears this mentioned the function name.
> 
> I think I'm mistaken about this, so IMO we can just drop this part and
> focus on whether we should remove that buildsym.c hunk.

The hunk in question is only an optimisation because we now see lots
of duplicate entries toggling between is-stmt true and is-stmt false.
I don't believe that keeping the duplicates around would cause any
problems.

I would be quite happy if you wanted to remove the hunk.  We might
also consider something like this totally untested patch:

## START ##

diff --git a/gdb/buildsym.c b/gdb/buildsym.c
index 7155db34b08..b0d0bc53eb5 100644
--- a/gdb/buildsym.c
+++ b/gdb/buildsym.c
@@ -683,16 +683,12 @@ buildsym_compunit::record_line (struct subfile *subfile, int line,
 
   if (subfile->line_vector->nitems > 0)
     {
-      /* If we have a duplicate for the previous entry then ignore the new
-        entry, except, if the new entry is setting the is_stmt flag, then
-        ensure the previous entry respects the new setting.  */
+      /* If the previous entry is for the same line, at the same pc, and
+        is marked as a statement, while we are trying to add a
+        non-statement, then lets just drop this new non-statement.  */
       e = subfile->line_vector->item + subfile->line_vector->nitems - 1;
-      if (e->line == line && e->pc == pc)
-       {
-         if (is_stmt && !e->is_stmt)
-           e->is_stmt = 1;
-         return;
-       }
+      if (e->line == line && e->pc == pc && e->is_stmt && !is_stmt)
+       return
     }
 
   if (subfile->line_vector->nitems + 1 >= subfile->line_vector_length)

## END ##

This will remove fewer duplicates, but should keep around the ones we
care about I hope.

I'll test that patch at this end, but do let me know if it solves the
regression you're seeing.

Thanks,
Andrew