[Bug debug/19191] New: No DWARF2 DW_TAG_inlined_subroutine entry generated

[Bug debug/19191] New: No DWARF2 DW_TAG_inlined_subroutine entry generated

[gcc-bugzilla at gcc dot gnu dot org]

The current gcc 4 development compiler does not generate DWARF2
DW_TAG_inlined_subroutine entries for concrete instances of inlined
subroutines.  The correct entries are generated by the compiler
included in Fedora Core 3, which identifies itself as "gcc version
3.4.2 20041017 (Red Hat 3.4.2-6.fc3)".

Environment:
System: Linux toadfish.ninemoons.com 2.6.9-1.681_FC3.stk16 #1 Mon Nov 22 16:44:32 EST 2004 i686 i686 i386 GNU/Linux
Architecture: i686

	
host: i686-pc-linux-gnu
build: i686-pc-linux-gnu
target: i686-pc-linux-gnu
configured with: /src/sourceware/gcc/gcc/configure -v --prefix=/opt/local/sourceware --with-gcc-version-trigger=/src/sourceware/gcc/gcc/gcc/version.c --enable-languages=c,c++

How-To-Repeat:

Given the test case:

  int add2 (int a, int b)
  {
    return (a + b);
  }
  
  inline int add3 (int a, int b, int c)
  {
    return (a + add2 (b , c));
  }
  
  main ()
  {
    printf ("%d\n", add3 (2, 3, 4));
  }
  
Run:

  gcc -g -O2 --save-temps -o t t.c
  readelf --debug-dump t >t.dwarf
  objdump --disassemble t >t.dis

For the Fedora core 3 compiler, there will be some entries in t.dwarf
that look like:

 <2><ec>: Abbrev Number: 13 (DW_TAG_inlined_subroutine)
          DW_AT_abstract_origin: <5f>	
          DW_AT_low_pc      : 0x8048398	
          DW_AT_high_pc     : 0x80483a4	
 <3><f9>: Abbrev Number: 14 (DW_TAG_formal_parameter)
          DW_AT_abstract_origin: <a0>	
 <3><fe>: Abbrev Number: 14 (DW_TAG_formal_parameter)
          DW_AT_abstract_origin: <a8>	
 <3><103>: Abbrev Number: 14 (DW_TAG_formal_parameter)
          DW_AT_abstract_origin: <b0>	

For the inlined code marked with '***' below:

       0804838c <main>:
        804838c:   55                      push   %ebp
        804838d:   89 e5                   mov    %esp,%ebp
        804838f:   83 ec 08                sub    $0x8,%esp
        8048392:   83 e4 f0                and    $0xfffffff0,%esp
        8048395:   83 ec 10                sub    $0x10,%esp
***     8048398:   6a 04                   push   $0x4
***     804839a:   6a 03                   push   $0x3
***     804839c:   e8 c7 ff ff ff          call   8048368 <add2>
***     80483a1:   83 c0 02                add    $0x2,%eax
        80483a4:   50                      push   %eax
        80483a5:   68 94 84 04 08          push   $0x8048494
        80483aa:   e8 01 ff ff ff          call   80482b0 <printf@plt>
        80483af:   c9                      leave  
        80483b0:   c3                      ret    

As a side note, the inlined code generated by the 4.0.0 compiler
is not contiguous, as marked with '***' below:
  
       080483a0 <main>:
        80483a0:   55                      push   %ebp
***     80483a1:   b8 04 00 00 00          mov    $0x4,%eax
        80483a6:   89 e5                   mov    %esp,%ebp
        80483a8:   83 ec 08                sub    $0x8,%esp
        80483ab:   83 e4 f0                and    $0xfffffff0,%esp
        80483ae:   83 ec 10                sub    $0x10,%esp
***     80483b1:   89 44 24 04             mov    %eax,0x4(%esp)
***     80483b5:   c7 04 24 03 00 00 00    movl   $0x3,(%esp)
***     80483bc:   e8 af ff ff ff          call   8048370 <add2>
        80483c1:   c7 04 24 c8 84 04 08    movl   $0x80484c8,(%esp)
***     80483c8:   83 c0 02                add    $0x2,%eax
        80483cb:   89 44 24 04             mov    %eax,0x4(%esp)
        80483cf:   e8 dc fe ff ff          call   80482b0 <printf@plt>
        80483d4:   c9                      leave  
        80483d5:   c3                      ret    

The DWARF2 spec says this about subroutines:

  Note that for the low and high pc attributes to have meaning, DWARF
  makes the assumption that the code for a single subroutine is
  allocated in a single contiguous block of memory.

However the draft DWARF3 spec, which has new support for
non-contiguous address ranges, says this:

  The presence of low and high PC attributes for an entity implies that
  the code generated for the entity is contiguous and exists totally
  within the boundaries specified by those two attributes. If that is
  not the case, no low and high PC attributes should be produced.

In DWARF3, you are supposed to use the DW_AT_ranges attribute to
describe a non-contiguous range of addresses.  From looking at
dwarf2out.c in the compiler sources, it appears that there is some
support for the DW_AT_ranges attribute already in gcc.

-- 
           Summary: No DWARF2 DW_TAG_inlined_subroutine entry generated
           Product: gcc
           Version: 4.0.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: debug
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: fnf at specifixinc 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: i686-pc-linux-gnu


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

[Bug debug/19191] [4.0 Regression] No DWARF2 DW_TAG_inlined_subroutine entry generated

[pinskia at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |wrong-debug
            Summary|No DWARF2                   |[4.0 Regression] No DWARF2
                   |DW_TAG_inlined_subroutine   |DW_TAG_inlined_subroutine
                   |entry generated             |entry generated
   Target Milestone|---                         |4.0.0


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

[Bug debug/19191] [4.0 Regression] No DWARF2 DW_TAG_inlined_subroutine entry generated

[dberlin at gcc dot gnu dot org]

------- Additional Comments From dberlin at gcc dot gnu dot org  2004-12-29 20:17 -------
The lexical block that contains the arguments (and the subblocks for the other
inlined parameters) is marked as asm_written but not *used* in 4.0, so we ignore it.
block 0x4009b784 asm_written
    vars <var_decl 0x40098f30 c
...

the same block in 3.4 is marked as both asm_written and used.

 <block 0x40008cd0 asm_written used
    vars <var_decl 0x400c606c a

I believe i know why this is.



Forcing the block to be marked used in 4.0 fixes the problem
I will ask the approriate people 

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |dberlin at gcc dot gnu dot
                   |dot org                     |org
             Status|UNCONFIRMED                 |ASSIGNED
     Ever Confirmed|                            |1
   Last reconfirmed|0000-00-00 00:00:00         |2004-12-29 20:17:17
               date|                            |


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

[Bug debug/19191] [4.0 Regression] No DWARF2 DW_TAG_inlined_subroutine entry generated

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-29 20:54 -------
Patch here: <http://gcc.gnu.org/ml/gcc-patches/2004-12/msg02075.html>.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |patch


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

[Bug debug/19191] [4.0 Regression] No DWARF2 DW_TAG_inlined_subroutine entry generated

[fnf at specifixinc dot com]

------- Additional Comments From fnf at specifixinc dot com  2004-12-30 16:14 -------
I tried the patch and it does generate a entry:

  <2><cd>: Abbrev Number: 10 (DW_TAG_inlined_subroutine)
     DW_AT_abstract_origin: <5f>
     DW_AT_low_pc      : 0x80483a1
     DW_AT_high_pc     : 0x80483a6

Note though that this only covers the first instruction of the inlined
subroutine, the mov instr at 80483a1:

 080483a0 <main>:
  80483a0:       55                      push   %ebp
  80483a1:       b8 04 00 00 00          mov    $0x4,%eax
  80483a6:       89 e5                   mov    %esp,%ebp

I believe what needs to happen is for the DWARF2 DW_TAG_inlined_subroutine
entry to use the DW_AT_ranges attribute to indentify the discontiguous
address ranges of the inlined subroutine, instead of using DW_AT_low_pc and 
DW_AT_high_pc.

-- 


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

[Bug debug/19191] [4.0 Regression] No DWARF2 DW_TAG_inlined_subroutine entry generated

[dberlin at dberlin dot org]

------- Additional Comments From dberlin at gcc dot gnu dot org  2004-12-30 16:42 -------
Subject: Re:  [4.0 Regression] No DWARF2
	DW_TAG_inlined_subroutine entry generated

On Thu, 2004-12-30 at 16:14 +0000, fnf at specifixinc dot com wrote:
> ------- Additional Comments From fnf at specifixinc dot com  2004-12-30 16:14 -------
> I tried the patch and it does generate a entry:
> 
>   <2><cd>: Abbrev Number: 10 (DW_TAG_inlined_subroutine)
>      DW_AT_abstract_origin: <5f>
>      DW_AT_low_pc      : 0x80483a1
>      DW_AT_high_pc     : 0x80483a6
> 
> Note though that this only covers the first instruction of the inlined
> subroutine, the mov instr at 80483a1:
> 
>  080483a0 <main>:
>   80483a0:       55                      push   %ebp
>   80483a1:       b8 04 00 00 00          mov    $0x4,%eax
>   80483a6:       89 e5                   mov    %esp,%ebp
> 
> I believe what needs to happen is for the DWARF2 DW_TAG_inlined_subroutine
> entry to use the DW_AT_ranges attribute to indentify the discontiguous
> address ranges of the inlined subroutine, instead of using DW_AT_low_pc and 
> DW_AT_high_pc.
> 

Yup.
One problem at a time though.
:)





-- 


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

[Bug debug/19191] [4.0 Regression] No DWARF2 DW_TAG_inlined_subroutine entry generated

[dberlin at gcc dot gnu dot org]

------- Additional Comments From dberlin at gcc dot gnu dot org  2004-12-31 22:25 -------
This is really a duplicate of 17924

*** This bug has been marked as a duplicate of 17924 ***

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |DUPLICATE


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

[Bug debug/19191] [4.0 Regression] No DWARF2 DW_TAG_inlined_subroutine entry generated

[cvs-commit at gcc dot gnu dot org]

------- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-01-04 01:54 -------
Subject: Bug 19191

CVSROOT:	/cvs/gcc
Module name:	gcc
Changes by:	dberlin@gcc.gnu.org	2005-01-04 01:54:29

Modified files:
	gcc            : ChangeLog Makefile.in dwarf2out.c gimple-low.c 
	                 tree-inline.c tree-optimize.c tree-pass.h 

Log message:
	2005-01-03  Daniel Berlin  <dberlin@dberlin.org>
	
	Fix PR debug/17924
	Fix PR debug/19191
	* dwarf2out.c (block_ultimate_origin): Follow decl origin if origin
	is a decl.
	* gimple-low.c (mark_blocks_with_used_vars): New function.
	(mark_blocks_with_used_subblocks): Ditto.
	(mark_used_blocks): Ditto.
	(pass_mark_used_blocks): New pass.
	* tree-inline.c: Include debug.h.
	(expand_call_inline): Call outlining_inline_function here.
	* tree-optimize.c (init_tree_optimization_passes): Add
	pass_mark_used_blocks.
	* tree-pass.h (pass_mark_used_blocks): New.
	* Makefile.in (tree-inline.o): Add debug.h dependency.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.7012&r2=2.7013
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/Makefile.in.diff?cvsroot=gcc&r1=1.1437&r2=1.1438
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/dwarf2out.c.diff?cvsroot=gcc&r1=1.564&r2=1.565
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/gimple-low.c.diff?cvsroot=gcc&r1=2.14&r2=2.15
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-inline.c.diff?cvsroot=gcc&r1=1.161&r2=1.162
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-optimize.c.diff?cvsroot=gcc&r1=2.66&r2=2.67
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-pass.h.diff?cvsroot=gcc&r1=2.22&r2=2.23



-- 


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