Re: [PATCH] Use containing function when reporting breakpoint location.

[Jan Kratochvil <jan dot kratochvil at redhat dot com>]

On Fri, 10 Mar 2017 21:59:13 +0100, Keith Seitz wrote:
> With this patch, print_breakpoint_location now calls a new variation of
> find_pc_sect_function, find_pc_sect_containing_function, which does not
> skip over inlined functions, and the breakpoint location is now reported
> "correctly":

Your patch just exchanges the sets of PASSing and FAILing cases.  Goal of this
patch should be to PASS all cases.

------------------------------------------------------------------------------
volatile int i,j;
void f(void) {
  i=1;
}
int main(void) {
  f();
  return 0;
}
------------------------------------------------------------------------------
$ for i in main f;do ./gdb-clean -batch -data-directory data-directory/ ./4 -ex "b $i" -ex 'info break';done
------------------------------------------------------------------------------
 Breakpoint 1 at 0x4003b0: file 4.c, line 5.
 Num     Type           Disp Enb Address            What
-1       breakpoint     keep y   0x00000000004003b0 in main at 4.c:5
+1       breakpoint     keep y   0x00000000004003b0 in f at 4.c:5
 Breakpoint 1 at 0x4003b0: f. (2 locations)
 Num     Type           Disp Enb Address            What
 1       breakpoint     keep y   <MULTIPLE>         
-1.1                         y     0x00000000004003b0 in main at 4.c:5
+1.1                         y     0x00000000004003b0 in f at 4.c:5
vvv=this line is off-topic for this mail
 1.2                         y     0x00000000004004c0 in f at 4.c:3
^^^=this line is off-topic for this mail
------------------------------------------------------------------------------
- = FSF GDB HEAD
+ = FSF GDB HEAD + this patch

The goal is to display "main" in the first case and "f" in the second case.

I think this would need to store more information into bp_location to know how
its CORE_ADDR address has been found.

In my attached patch-idea (not compilable) from 2015-06 (RHBZ 1228549#c5)
I chose more a quick-hack to reuse 'addr_string', parse it and select only its
SALs that match by its PC the bp_location being processed/displayed.


Although still the behavior will be confusing afterwards as existing debug
info does not provide enough information for sane -O2 -g debugging.
This should be only fixed by future DWARF+GCC feature by Alexandre Oliva:
	https://people.redhat.com/aoliva/papers/sfn/gcc2010.pdf
	https://people.redhat.com/aoliva/papers/sfn/slides.pdf
Internal in RH: Message-ID: <orbmto9cir.fsf@lxoliva.fsfla.org>


Jan

diff --git a/gdb/inline-frame.c b/gdb/inline-frame.c
index e5d7360..d535dcb 100644
--- a/gdb/inline-frame.c
+++ b/gdb/inline-frame.c
@@ -301,13 +301,32 @@ block_starting_point_at (CORE_ADDR pc, const struct block *block)
    user steps into them.  */
 
 void
-skip_inline_frames (ptid_t ptid)
+skip_inline_frames (ptid_t ptid, struct breakpoint *bpt)
 {
   CORE_ADDR this_pc;
   const struct block *frame_block, *cur_block;
   struct symbol *last_sym = NULL;
   int skip_count = 0;
   struct inline_state *state;
+  struct linespec_result canonical;
+
+  
+  if (bpt == NULL)
+    canonical.sals = NULL;
+  else
+    {
+      char *addr_string = bpt->addr_string;
+
+      TRY
+	{
+	  decode_line_full (&addr_string, DECODE_LINE_FUNFIRSTLINE, NULL, 0,
+			    &canonical, multiple_symbols_all, NULL);
+	}
+      CATCH (e, RETURN_MASK_ERROR)
+	{
+	}
+      END_CATCH
+    }
 
   /* This function is called right after reinitializing the frame
      cache.  We try not to do more unwinding than absolutely
@@ -327,6 +346,20 @@ skip_inline_frames (ptid_t ptid)
 	      if (BLOCK_START (cur_block) == this_pc
 		  || block_starting_point_at (this_pc, cur_block))
 		{
+		  int lsal_i;
+		  struct linespec_sals *lsal;
+
+		  for (lsal_i = 0; VEC_iterate (linespec_sals, canonical->sals, lsal_i, lsal); lsal_i++)
+		    {
+		      struct symtabs_and_lines *sals = lsal->sals;
+
+		      for (sals_i = 0; sals_i < sals->nelts; sals_i++)
+			{
+			  struct struct symtab_and_line *sal = *sals->sals[sals_i];
+
+			}
+		    }
+
 		  skip_count++;
 		  last_sym = BLOCK_FUNCTION (cur_block);
 		}