[lldb-dev] Stack unwinding with hand-crafted CFI

[Pavel Labath]

Forgot to add the list.

On 22 April 2015 at 14:54, Pavel Labath <labath at google.com> wrote:
> Hello,
>
> On 21 April 2015 at 18:04, Greg Clayton <gclayton at apple.com> wrote:
>> The main problem is 99% of all the EH frame info is valid only at call sites. Because of this we don't use EH frame in the first frame and we don't use it after async interrupt functions like sigtramp. We have no way of marking EH frame as being valid for every PC in a function. If we try to use an augmentation letter in the CIE, then all consumers (unwind libraries for the operating system, debuggers, etc) of the augmentation letters need to know about the new augmentation letter and if they don't they get really unhappy.
>
> I was not suggesting we add a new augmentation letter (although that
> idea does sound interesting in the *very* long term). I am also aware
> that the EH frame info is not valid for most functions. However, I am
> looking for a solution that would work for that 1% of the functions
> (while leaving the behavior for the other 99% unchanged). One of the
> solutions I can think of goes like this.
>
>
> Currently the logic for choosing the (asynchronous) unwind plan is rougly:
> eh := GetEHFrameUnwindPlan();
> if (I_know_how_to_augment(eh))
>   return Augment(eh)
> return GetAssemblyUnwindPlan();
>
> If we encounter a function which does very strange things in its EH
> plan then I_know_how_to_augment will return false and we will default
> to the assembly profiling plan. However, since the function is doing
> some crazy things, the assembly profiling will produce a completely
> bogus plan. And when we try using this plan, we will fail.
>
> What I suggest is to change the logic to something like this:
> eh := GetEHFrameUnwindPlan();
> if (I_know_how_to_augment(eh))
>   return Augment(eh)
> else if (Plan_is_very_complicated(eh))
>   return eh; // if the EH section contains a complicated plan, then
> our attempts to do instruction profiling will likely fail. Let's just
> stick to the EH plan instead.
> return GetAssemblyUnwindPlan();
>
> Where Plan_is_very_complicated is some heuristic which decides whether
> the assembly profiling unwind plan is able to produce reasonable
> results. One possible implementation of this function could check
> whether the EH plan is using DW_CFA_expression to set the instruction
> or the stack pointer or using DW_CFA_def_cfa_expression to set the
> CFA. The rationale behind this is that "normal" functions don't use
> these instructions and use the simpler forms (DW_CFA_def_cfa,
> DW_CFA_register, DW_CFA_offset, ) instead, as they are more compactly
> encoded. The presence of these instructions indicates that there is
> something more complex going on and that our assembly profiling logic
> will likely not be able to figure out what that is. In this case, I
> would say that it is better to use the EH frame unwind plan (which may
> be incomplete, but it was at least provided by somebody who has a
> chance of knowing what is going on), than the asm profiling plan
> (which is likely to be outright wrong).
>
> What do you think about that?
>
>
> Cheers,
> pavel