[Bug debug/43828] New: Emit debug info allowing inlined functions to show in stack traces

[Bug debug/43828] New: Emit debug info allowing inlined functions to show in stack traces

[scovich at gmail dot com]

It would be very nice if gcc emitted debug information that allowed profilers
and debuggers the option to extract a stack trace which included calls to
inlined functions. This would allow developers much greater insight into the
behavior of optimized code. 

C++ programs would benefit disproportionately, especially those which use the
STL heavily -- disabling inlining produces a very different executable which
makes profiling worse than useless and can mask heisenbugs.

Profiling would become significantly more accurate because it could determine
how much of a function's overheads remain even after inlining, which is pretty
much impossible right now. It would also allow profilers to generate
"functional" call graphs which show all uses of a function, inlined or not. 

Debugging would also improve because the user would be able to navigate a stack
trace which corresponds to the code they're trying to debug, even if the actual
calls were optimized away. Questions like "which of this function's 10 calls to
std::vector::begin seg faulted?" would suddenly be *much* easier to answer, and
in an intuitive way. With some work it would probably even be possible to
maintain mappings for local vars/params (assuming they exist at the time). 

All this "virtual stack trace" functionality would need to remain separate (and
probably not the default) so as to not confuse (impede) folks who are used to
(prefer) the current behavior. 

NOTE: I realize that full support for this would require changes to other
projects like gdb and gprof, but gcc could solve the chicken-and-egg problem by
emitting appropriate debug info as a first step; perhaps the new debug info
changes introduced with 4.5.0 already do (some of) this?


-- 
           Summary: Emit debug info allowing inlined functions to show in
                    stack traces
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: P3
         Component: debug
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: scovich at gmail dot com


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

[Bug debug/43828] Emit debug info allowing inlined functions to show in stack traces

[scovich at gmail dot com]

------- Comment #1 from scovich at gmail dot com  2010-04-21 09:29 -------
(In reply to comment #0)
One more way debugging would improve: it would become possible to set
breakpoints in inlined functions


-- 


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

[Bug debug/43828] Emit debug info allowing inlined functions to show in stack traces

[jakub at gcc dot gnu dot org]

------- Comment #2 from jakub at gcc dot gnu dot org  2010-04-21 10:03 -------
GCC already emits that (and emits that for quite some time already).


-- 

jakub at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |WORKSFORME


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

[Bug debug/43828] Emit debug info allowing inlined functions to show in stack traces

[wilson at codesourcery dot com]

------- Comment #3 from wilson at codesourcery dot com  2010-04-23 22:40 -------
Subject: Re:   New: Emit debug info allowing inlined functions
 to show in stack traces

On 04/21/2010 02:26 AM, scovich at gmail dot com wrote:
> It would be very nice if gcc emitted debug information that allowed profilers
> and debuggers the option to extract a stack trace which included calls to
> inlined functions. This would allow developers much greater insight into the
> behavior of optimized code.

Try the -i option of addr2line.

Jim


-- 


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

[Bug debug/43828] Emit debug info allowing inlined functions to show in stack traces

[scovich at gmail dot com]

------- Comment #4 from scovich at gmail dot com  2010-04-23 23:29 -------
> Try the -i option of addr2line.

Ah, very nice. It turns out I was using a 4.0-series gcc, which according to
gdb's docs doesn't output quite enough debug information to reconstruct inlined
stack traces; 4.1 and later do. Time for an upgrade!

Thanks!


-- 


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

[Bug debug/43828] Emit debug info allowing inlined functions to show in stack traces

[scovich at gmail dot com]

------- Comment #5 from scovich at gmail dot com  2010-05-07 20:12 -------
Belated follow-up: I just tried to use sparc-sun-solaris2.10-gcc-4.4.0 (built
from sources) and it does not emit the DW_AT_call_* debug attributes which gdb
expects in order to unwind inlined functions. 

I have searched both the gdb and gcc docs and cannot find any mention of
(modern) machines/systems/situations where this is not supported; given that
the required attributes are missing it seems like a gcc problem (feeding the .s
file to gas doesn't help, so I doubt it's the sun assembler/linker, either)

gcc -v
Using built-in specs.
Target: sparc-sun-solaris2.10
Configured with: ../gcc-4.4.0/configure
--prefix=/export/home/ryanjohn/apps/gcc-4.4.0
--with-gmp=/export/home/ryanjohn/apps --with-mpfr=/export/home/ryanjohn/apps
--without-gnu-ld --without-gnu-as
Thread model: posix
gcc version 4.4.0 (GCC) 


-- 

scovich at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |UNCONFIRMED
   GCC host triplet|                            |sparc-sun-solaris2.10
      Known to fail|                            |4.4.0
         Resolution|WORKSFORME                  |


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

[Bug debug/43828] Emit debug info allowing inlined functions to show in stack traces

[scovich at gmail dot com]

------- Comment #6 from scovich at gmail dot com  2010-05-07 21:20 -------
Aha! The problem is not that gcc fails to emit the proper debug info, it's that
it doesn't always track well which instructions came from which function. 

For example, if we compile this toy program:

int  volatile global;
int foo(int a) {
    return a + global;
}
int bar(int a) {
    return global + foo(a);
}
int baz(int a) {
    return global + bar(a);
}
int main(int argc, char const* argv[]) {
    return global + baz(argc);
}

Running it in gdb will seem to begin execution at exit from bar:
Dump of assembler code for function main:
   0x000106cc <+0>:     sethi  %hi(0x20800), %g1
   0x000106d0 <+4>:     ld  [ %g1 + 0x124 ], %g4        ! 0x20924 <global>
=> 0x000106d4 <+8>:     ld  [ %g1 + 0x124 ], %g3
   0x000106d8 <+12>:    ld  [ %g1 + 0x124 ], %g2
   0x000106dc <+16>:    ld  [ %g1 + 0x124 ], %g1
   0x000106e0 <+20>:    add  %g4, %g1, %g1
   0x000106e4 <+24>:    add  %g1, %g3, %g1
   0x000106e8 <+28>:    add  %g1, %g2, %g1
   0x000106ec <+32>:    retl
   0x000106f0 <+36>:    add  %g1, %o0, %o0
End of assembler dump.

Apparently someone made the reasonable judgment call that it was better to only
"enter" inlined functions once rather than jumping around, and even then only
if code from later in the containing function hasn't already run. Putting a
printf in foo() gave the expected result. 


-- 

scovich at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |WORKSFORME


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