[RFA patch] PR18749: epilogue not tracked in dwarf2 unwind-info

[Michael Matz]

Hi Alan,

On Wed, 14 Jun 2006, Alan Modra wrote:

> On Mon, Jun 12, 2006 at 10:07:40PM +0200, Michael Matz wrote:
> > I'm trying to fix PR18749, which is about the fact that dwarf2out.c 
> > doesn't look at epilogues at all, which makes the CFA be wrong during the 
> > epilogue, as no adjustments there (like pops, or additions to the stack 
> > pointer) are tracked.
> 
> You need to have some compelling reason to emit the unwind info,

Being able to generate backtraces in the epilogue is a reason.  If it's
compelling I don't know, but there are some uses for that which are
otherwise difficult to implement, e.g. a sampling profiler which can't
control at which instruction the sampling takes place, hence may be in the
prologue/epilogue and so currently can't generate a backtrace.  I know
that my patch doesn't generate complete unwind info (I detailed that in my
mail, that for doing so much more support in dwarf2out.c would be
necessary, but the patch from
  http://gcc.gnu.org/ml/gcc-patches/2006-02/msg01091.html
does that at a greater complexity in implementation, although their main 
reason also was only to be able to generate backtraces).

That impreciseness also makes the bloat not that much larger, as only 
DWARF statement for handling the CFA need to be generated.  Although you 
are right, they are larger.

So, question is: do we want to pay the prize in .eh_frame size for 
backtraces from the epilogue?  Perhaps with an option (though that would 
make it less usefull)?

> gcc doesn't support asynchronous exceptions, shouldn't generate trapping
> instructions in epilogues, and shouldn't allow trapping instructions
> from the body to migrate into the epilogue.

Yes, I'm not so much interested in complete unwinding from the epilogue, 
because as you say, that never would have a use.  Only in backtraces.

> *) You may have multiple copies of the epilogue.

I believe that's handled by my patch.

> You may have code from the function body being placed after the function
> return.

That's handled definitively.

> It's not just a matter of tracking the cfa adjustment in the
> epilogue;  A proper eh description for unwinding through asynchronous
> exceptions needs to know that saved regs are no longer valid on the
> stack.

Yep.  Even that could be added to the patch fairly easily: whenever the 
CFA is adjusted, through away all registers saved below the new top.  But 
that would enlarge the info even more, without many uses.


Ciao,
Michael.