On Fri, Dec 07, 2018 at 08:58:42AM -0800, Cary Coutant via Dwarf-Discuss wrote: > And that's another reason why on PA-RISC and Itanium we have the rule > that the unwind info for the PC of the instruction following the call > must be accurate. With that rule, we do not have to anticipate or > compensate for the consumer. One hack always begets another hack. (Of > course, if some debuggers were to subtract 1 despite that rule, we > would have to either compensate or declare them buggy.) > > Jakub complains that "the compiler would need to emit a nop after > every call, which an optimizing compiler is not willing to do." We're > not talking about *every* call, just the rare case of a no-return > call.
They aren't that rare, and even if they would, that is still not enough. For proper debug info one needs to differentiate between the context inside of the call and the context right after the call, while in the %eax case that has been discussed it makes no difference, in others it does. Consider: void bar (void); void baz (int); int foo (void) { int a = 6; bar (); { long a = 5; baz (10); } return 10; } If you don't subtract one during unwinding and during the bar call look at foo's frame, then it would appear as if you are already at the baz call with the inner a variable in scope, but that shouldn't be in scope yet, and if user asks for value of a, he should see that 6 and its type should be int, not long. Jakub _______________________________________________ Dwarf-Discuss mailing list Dwarf-Discuss@lists.dwarfstd.org http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org