[Bug debug/14022] New: asm() should start a new line table entry

["gcc-bugzilla at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>]

Gcc is not causing a dwarf line table entry break at an asm(), which
causes the contents of an asm() outside a function to be subsumed into
the previous function, at least as far as the line table information
is concerned.

Environment:
System: Linux fred.ninemoons.com 2.4.22-1.2149.nptl #1 Wed Jan 7 12:57:33 EST 2004 i686 athlon i386 GNU/Linux
Architecture: i686

	
host: i686-pc-linux-gnu
build: i686-pc-linux-gnu
target: sh-unknown-elf
configured with: /src/sourceware/gcc/gcc/configure -v --prefix=/usr/local/sourceware --with-newlib --with-gnu-as --with-gnu-ld --target=sh-elf --enable-languages=c,c++

How-To-Repeat:

Given the following test case:

    void sub (void);

    main()
    {
            sub();
    }
	
    asm(".text\n _sub:\n rts\n");

sh-elf-gcc is emitting line number info that makes the asm() appear to be
part of main().  Here is the relevant output of "readelf --debug-dump" on
the object file:

    Line Number Statements:
     Extended opcode 2: set Address to 0x0
     Special opcode 8: advance Address by 0 to 0x0 and Line by 3 to 4
     Special opcode 48: advance Address by 6 to 0x6 and Line by 1 to 5
     Special opcode 48: advance Address by 6 to 0xc and Line by 1 to 6
     Advance PC by 18 to 1e
     Extended opcode 1: End of Sequence
  
As an alternate view of the line table, this is what dwarfdump generates:

    line number info
    <source>	[row,column]	<pc>	//<new statement or basic block
    b2.c:	[  4,-1]	0	// new statement
    b2.c:	[  5,-1]	0x6	// new statement
    b2.c:	[  6,-1]	0xc	// new statement
    b2.c:	[  6,-1]	0x1e	// new statement	// end of text sequence

Here is a disassembly of the generated object file with "--- comment ---"
lines to show the start of where gcc assigns each line, assuming I'm
interpreting the table correctly:

    b2.o:     file format elf32-sh
    
    Disassembly of section .text:
    
    00000000 <_main>:
-- start line 4 ---
       0:	2f e6       	mov.l	r14,@-r15
       2:	4f 22       	sts.l	pr,@-r15
       4:	6e f3       	mov	r15,r14
-- start line 5 --
       6:	d1 04       	mov.l	18 <_main+0x18>,r1	! 0x1c
       8:	41 0b       	jsr	@r1
       a:	00 09       	nop	
-- start line 6 --
       c:	6f e3       	mov	r14,r15
       e:	4f 26       	lds.l	@r15+,pr
      10:	6e f6       	mov.l	@r15+,r14
      12:	00 0b       	rts	
      14:	00 09       	nop	
      16:	00 09       	nop	
      18:	00 00       	.word 0x0000
      1a:	00 1c       	mov.b	@(r0,r1),r0
    
    0000001c <_sub>:
      1c:	00 0b       	rts	
-- end line 6 --
      1e:	00 09       	nop	

Encountering the end of a function should probably force a new line number
entry when any code is found after the last instruction in the function.
I.E.  something like:

    line number info
    <source>	[row,column]	<pc>	//<new statement or basic block
    b2.c:	[  4,-1]	0	// new statement
    b2.c:	[  5,-1]	0x6	// new statement
    b2.c:	[  6,-1]	0xc	// new statement
    b2.c:	[  8,-1]	0x1c	// new statement
    b2.c:	[  8,-1]	0x1e	// new statement	// end of text sequence

This is the cause of the current gdb failure for the gdb test "gdb1291.exp".

-- 
           Summary: asm() should start a new line table entry
           Product: gcc
           Version: 3.5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: debug
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: fnf at redhat dot com
                CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: sh-unknown-elf


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14022