[rfc] Fix Java regression (Re: [rfc] Consoldiate prologue skipping code - fix expand_line_sal_maybe internal error)

["Ulrich Weigand" <uweigand at de dot ibm dot com>]

> > 	* breakpoint.c (expand_line_sal_maybe): Always call skip_prologue_sal.
> > 	(skip_prologue_sal): Remove local definition.
> > 	(resolve_sal_pc): Remove now unnecessary code.
> > 	* linespec.c (minsym_found): Call skip_prologue_sal.
> > 	* symtab.c (find_function_start_pc): Remove.
> > 	(find_function_start_sal): Extract prologue skipping into ...
> > 	(skip_prologue_sal): ... this new function.  Handle code both
> > 	with and without debug info.  Respect SAL's explicit_pc and
> > 	explicit_line flags.  Inline old find_function_start_pc.
> > 	* symtab.h (find_function_start_pc): Remove.
> > 	(skip_prologue_sal): Add prototype.

Keith Seitz noticed that this patch introduces a regression for Java with
certain versions of GCC 4.4.  It seems the GCC conversion to per-expression
locations in 4.4 was incomplete for Java.  This was fixed for 4.5 here:
http://gcc.gnu.org/ml/gcc-patches/2009-07/msg01831.html

The affected versions of GCC show the symptom that .loc statements indicating
the very beginning of a function (even before the prologue) are completely
missing.  As an example, for the jmisc.java test case, we have two functions:

gdb) disass 0x80488fa
Dump of assembler code for function jmisc.jmisc(void)void:
   0x080488f4 <+0>:     push   %ebp                       
   0x080488f5 <+1>:     mov    %esp,%ebp                  
   0x080488f7 <+3>:     sub    $0x28,%esp                 
   0x080488fa <+6>:     mov    0x8(%ebp),%eax             
   0x080488fd <+9>:     mov    %eax,-0xc(%ebp)            
   0x08048900 <+12>:    mov    -0xc(%ebp),%eax            
   0x08048903 <+15>:    mov    %eax,(%esp)                
   0x08048906 <+18>:    call   0x8048798 <_ZN4java4lang6ObjectC1Ev@plt>
   0x0804890b <+23>:    leave                                          
   0x0804890c <+24>:    ret                                            
End of assembler dump.                                                 
(gdb) disass  0x8048913                                                
Dump of assembler code for function jmisc.main(java.lang.String[])void:
   0x0804890d <+0>:     push   %ebp                                    
   0x0804890e <+1>:     mov    %esp,%ebp                               
   0x08048910 <+3>:     sub    $0x18,%esp                              
   0x08048913 <+6>:     mov    0x8048a38,%eax                          
   0x08048918 <+11>:    mov    %eax,(%esp)                             
   0x0804891b <+14>:    call   0x8048758 <_Jv_InitClass@plt>           
   0x08048920 <+19>:    leave                                          
   0x08048921 <+20>:    ret                                            
End of assembler dump.                                                 

but the debug info only contains three line number records:
  0x08488f4: line 1
  0x0848913: line 5
  0x8048922: end of sequence

In particular, there is no line number record at all at the beginning
of the jmisc.main function.

The new logic in find_function_start_sal now goes:
- jmisc.misc starts at 0x0804890d
- 0x0804890d belongs to line 1 (!!!)
- line 1 starts at 0x080488f4
- prologue skipping from 0x080488f4 yields 0x80488fa

Of course, this is completely wrong ...

The old code seems have to accidentally worked, because it did things
in a slightly different sequence:
- jmisc.misc starts at 0x0804890d
- prologue skipping from 0x0804890d yields 0x0848913
- 0x0848913 belongs to line 5
- line 5 starts at 0x0848913

To work around this issue, the following patch notices when 
find_pc_sect_line fails to find line info for the start address
of a function and falls back to an earlier one.  In this case,
the resulting SAL is simply reset to the function start address.

Keith has confirmed that this fixes the regressions with his
compiler.

Tested on powerpc64-linux with no regressions.

Any thoughts or suggestions for a better workaround?
I'm planning to commit this patch by the end of the week.

Bye,
Ulrich


Index: gdb/symtab.c
===================================================================
RCS file: /cvs/src/src/gdb/symtab.c,v
retrieving revision 1.230
diff -u -p -r1.230 symtab.c
--- gdb/symtab.c	26 Mar 2010 19:41:50 -0000	1.230
+++ gdb/symtab.c	29 Mar 2010 18:49:22 -0000
@@ -2295,6 +2295,18 @@ find_function_start_sal (struct symbol *
   sal = find_pc_sect_line (BLOCK_START (SYMBOL_BLOCK_VALUE (sym)),
 			   SYMBOL_OBJ_SECTION (sym), 0);
 
+  /* We always should have a line for the function start address.
+     If we don't, something is odd.  Create a plain SAL refering
+     just the PC and hope that skip_prologue_sal (if requested)
+     can find a line number for after the prologue.  */
+  if (sal.pc < BLOCK_START (SYMBOL_BLOCK_VALUE (sym)))
+    {
+      init_sal (&sal);
+      sal.pspace = current_program_space;
+      sal.pc = BLOCK_START (SYMBOL_BLOCK_VALUE (sym));
+      sal.section = SYMBOL_OBJ_SECTION (sym);
+    }
+
   if (funfirstline)
     skip_prologue_sal (&sal);
 

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com