Forgot to add the list. On 22 April 2015 at 14:54, Pavel Labath <lab...@google.com> wrote: > Hello, > > On 21 April 2015 at 18:04, Greg Clayton <gclay...@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
_______________________________________________ lldb-dev mailing list lldb-dev@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
