gdb: Add support for tracking the DWARF line table is-stmt field

This commit brings support for the DWARF line table is_stmt field to
GDB.  The is_stmt field is used by the compiler when a single source
line is split into multiple assembler instructions, especially if the
assembler instructions are interleaved with instruction from other
source lines.

The compiler will set the is_stmt flag false from some instructions
from the source lines, these instructions are not a good place to
insert a breakpoint in order to stop at the source line.
Instructions which are marked with the is_stmt flag true are a good
place to insert a breakpoint for that source line.

Currently GDB ignores all instructions for which is_stmt is false.
This is fine in a lot of cases, however, there are some cases where
this means the debug experience is not as good as it could be.

Consider stopping at a random instruction, currently this instruction
will be attributed to the last line table entry before this point for
which is_stmt was true - as these are the only line table entries that
GDB tracks.  This can easily be incorrect in code with even a low
level of optimisation.

With is_stmt tracking in place, when stopping at a random instruction
we now attribute the instruction back to the real source line, even
when is_stmt is false for that instruction in the line table.

When inserting breakpoints we still select line table entries for
which is_stmt is true, so the breakpoint placing behaviour should not
change.

When stepping though code (at the line level, not the instruction
level) we will still stop at instruction where is_stmt is true, I
think this is more likely to be the desired behaviour.

Instruction stepping is, of course, unchanged, stepping one
instruction at a time, but we should now report more accurate line
table information with each instruction step.

The original motivation for this work was a patch posted by Bernd
here:
  https://sourceware.org/ml/gdb-patches/2019-11/msg00792.html

As part of that thread it was suggested that many issues would be
resolved if GDB supported line table views, this isn't something I've
attempted in this patch, though reading the spec, it seems like this
would be a useful feature to support in GDB in the future.  The spec
is here:
  http://dwarfstd.org/ShowIssue.php?issue=170427.1

And Bernd gives a brief description of the benefits here:
  https://sourceware.org/ml/gdb-patches/2020-01/msg00147.html

With that all said, I think that there is benefit to having proper
is_stmt support regardless of whether we have views support, so I
think we should consider getting this in first, and then building view
support on top of this.

The gdb.cp/step-and-next-inline.exp test is based off a test proposed
by Bernd Edlinger in this message:
  https://sourceware.org/ml/gdb-patches/2019-12/msg00842.html

gdb/ChangeLog:

	* buildsym-legacy.c (record_line): Pass extra parameter to
	record_line.
	* buildsym.c (buildsym_compunit::record_line): Take an extra
	parameter, reduce duplication in the line table, and record the
	is_stmt flag in the line table.
	* buildsym.h (buildsym_compunit::record_line): Add extra
	parameter.
	* disasm.c (do_mixed_source_and_assembly_deprecated): Ignore
	non-statement lines.
	* dwarf2/read.c (dwarf_record_line_1): Add extra parameter, pass
	this to the symtab builder.
	(dwarf_finish_line): Pass extra parameter to dwarf_record_line_1.
	(lnp_state_machine::record_line): Pass a suitable is_stmt flag
	through to dwarf_record_line_1.
	* infrun.c (process_event_stop_test): When stepping, don't stop at
	a non-statement instruction, and only refresh the step info when
	we land in the middle of a line's range.  Also add an extra
	comment.
	* jit.c (jit_symtab_line_mapping_add_impl): Initialise is_stmt
	field.
	* record-btrace.c (btrace_find_line_range): Only record lines
	marked as is-statement.
	* stack.c (frame_show_address): Show the frame address if we are
	in a non-statement sal.
	* symmisc.c (dump_symtab_1): Print the is_stmt flag.
	(maintenance_print_one_line_table): Print a header for the is_stmt
	column, and include is_stmt information in the output.
	* symtab.c (find_pc_sect_line): Find lines marked as statements in
	preference to non-statements.
	(find_pcs_for_symtab_line): Prefer is-statement entries.
	(find_line_common): Likewise.
	* symtab.h (struct linetable_entry): Add is_stmt field.
	(struct symtab_and_line): Likewise.
	* xcoffread.c (arrange_linetable): Initialise is_stmt field when
	arranging the line table.

gdb/testsuite/ChangeLog:

	* gdb.cp/step-and-next-inline.cc: New file.
	* gdb.cp/step-and-next-inline.exp: New file.
	* gdb.cp/step-and-next-inline.h: New file.
	* gdb.dwarf2/dw2-is-stmt.c: New file.
	* gdb.dwarf2/dw2-is-stmt.exp: New file.
	* gdb.dwarf2/dw2-is-stmt-2.c: New file.
	* gdb.dwarf2/dw2-is-stmt-2.exp: New file.
	* gdb.dwarf2/dw2-ranges-base.exp: Update line table pattern.

1 files changed, 10 insertions, 0 deletions

diff --git a/gdb/symtab.h b/gdb/symtab.h
index 5fa067b..771b5ec 100644
--- a/gdb/symtab.h
+++ b/gdb/symtab.h
@@ -1277,7 +1277,13 @@ struct rust_vtable_symbol : public symbol
 
 struct linetable_entry
 {
+  /* The line number for this entry.  */
   int line;
+
+  /* True if this PC is a good location to place a breakpoint for LINE.  */
+  unsigned is_stmt : 1;
+
+  /* The address for this entry.  */
   CORE_ADDR pc;
 };
 
@@ -1853,6 +1859,10 @@ struct symtab_and_line
   bool explicit_pc = false;
   bool explicit_line = false;
 
+  /* If the line number information is valid, then this indicates if this
+     line table entry had the is-stmt flag set or not.  */
+  bool is_stmt = false;
+
   /* The probe associated with this symtab_and_line.  */
   probe *prob = NULL;
   /* If PROBE is not NULL, then this is the objfile in which the probe