GCC Bugzilla Bug 16439

For the following test case in the gdb testsuite: jmain.java

public class jmain
{
  public static void main (String[] args)
    {
        return;
    }
}

The breakpoint for main ends up being line 4 (the open brace) instead of line 5.
 This does not match the C/C++ behavior which is to point to the first statement
of the member function.  Gdb gets the line number info from the compiler which
is the following tailed output from readelf -wl

 Line Number Statements:
  Extended opcode 2: set Address to 0x8048868
  Special opcode 8: advance Address by 0 to 0x8048868 and Line by 3 to 4
  Special opcode 89: advance Address by 6 to 0x804886e and Line by 0 to 4
  Special opcode 175: advance Address by 12 to 0x804887a and Line by 2 to 6
  Special opcode 28: advance Address by 2 to 0x804887c and Line by -5 to 1
  Special opcode 89: advance Address by 6 to 0x8048882 and Line by 0 to 1
  Advance PC by 14 to 8048890
  Extended opcode 1: End of Sequence

Created an attachment (id=6712) [edit]
jmain.java

This occurs for "static" and maybe "synchronized" methods. What happens is gcj
inserts some prologue code to check the class initialization status (in the case
of a static method), or in the case of a synchronized method, to aquire the
lock. The line number it uses for the inserted prologue code is that of the
current parser context when starting the method, which points to the method's
opening brace ("{").

It could be changed to instead look for the first non-synthetic code in the
method and use the line number from that.

Reconfirm (it is a little easlier to see with the tree dumps):
jmain.main(java.lang.String[]) (args)
{
  [jmain.java : 4] _Jv_InitClass (&jmain.class);
  [jmain.java : 4] {
    [jmain.java : 5] return;
  }
}