http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53927
--- Comment #4 from Tom Tromey <tromey at gcc dot gnu.org> 2013-01-31 19:40:16 UTC --- (In reply to comment #3) > I don't see the problem. On both i686 and x86_64 'p self_call' prints 1, > which > matches the value returned by the function, so debugging seems to be working > fine. You can't go by what gdb says here. gdb currently doesn't look at DW_AT_static_link at all. Instead it just does some guessing. This bug came up because I tried to make it work properly. If you try "print arg" you will see gdb get it wrong: (gdb) print arg $1 = 0 I think the correct answer is 5. > On i686 the DW_AT_static_link points to $eax because that's where the static > chain lives during (part of) the function. > > As Eric says, the value of the static chain pointer is not the same as the > CFA; > it points to a struct in the stack frame of the caller. > > What's the bug? DWARF defines DW_AT_static_link to be the frame base of the appropriate outer invocation: If a subroutine or entry point is nested, it may have a DW_AT_static_link attribute, whose value is a location description that computes the frame base of the relevant instance of the subroutine that immediately encloses the subroutine or entry point. The idea is you can determine which instance by computing the static link, then unwind the stack and look for the corresponding CFA. The test case here is supposed to confound simplistic approaches to this by having multiple instances of 'nestee' on the stack. Note also that if the nested function doesn't refer to any variables from the outer scope, then GCC seems not to emit DW_AT_static_link at all. I guess this is an optimization; but it is a little unfortunate since it makes debugging less obvious.
