Invalid program counters and unwinding

Florian Weimer fweimer@redhat.com
Tue Jun 26 11:25:00 GMT 2018


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



More information about the Gcc mailing list