Re: Invalid program counters and unwinding

[Florian Weimer <fweimer at redhat dot com>]

On 06/26/2018 01:15 PM, Nathan Sidwell wrote:
> On 06/26/2018 07:01 AM, Florian Weimer wrote:
> > On 06/26/2018 12:56 PM, Nathan Sidwell wrote:
> > > On 06/26/2018 05:26 AM, Florian Weimer wrote:
> > >
> > > > So it looks to me that the caller of _Unwind_Find_FDE needs to 
> > > > ensure that the PC is a valid element of the call stack.  Is this a 
> > > > correct assumption?
> > >
> > > I thought this was an (implicit?) requirement. You're unwinding a 
> > > stack to deliver an exception up it.  Are there use cases where that 
> > > is not the case?
> >
> > We have something approaching this scenario.
> >
> > pthread_cancel in glibc unwinds the stack using DWARF information 
> > until encounters a frame without unwind information, when it switches 
> > to longjmp to get past that obstacle.
>
> This is a long jump to the originating pthread function at the end of 
> the stack, right?  We not only get past the obstacle, but any and all 
> DWARF frames on top of it.  (just for my understanding)

Essentially yes.  It can also be an intermediate jump buffer, used to to 
support compilation in -fno-exceptions mode.  In that case, unwinding 
tries to proceed from there, again with a valid PC.

> That sounds right.  It's a PC that you could return to if you weren't trying to unwind the stack. 

GCC doesn't do this AFAIK, but it's theoretically possible not to 
preserve the return address for a noreturn function.  But that would be 
very bad for exception handling, so let's hope compilers don't do this.

Florian