> On Apr 22, 2015, at 6:56 AM, Pavel Labath <lab...@google.com> wrote: > > 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.
Small clarification on Greg's summary here. Since last summer, we've started using eh_frame for the currently-executing frame. Both gcc and clang were generating eh_frame which described the function prologues. And modern gcc's emit eh_frame which describes the epilogue. So Tong Shen, an intern at Google, added code to add epilogue instructions if it looked like the eh_frame was missing them. There's no guarantee that eh_frame unwind instructions will describe the prologue/epilogue, or that it will describe any important changes in the middle of the function except at places where the func can throw, or a callee can throw, but in practice the prologue at least is present. So we decided to try living off eh_frame for the currently executing frame, and it seems to be working OK. >> >> 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. This sounds like a good idea. The augmentation detection code in UnwindAssembly-x86.cpp is kind of hacky (and it's done at two different layers in different ways) -- my main concern here was modifying a correct set of unwind instructions from eh_frame by adding incorrect garbage to it. So it goes out of its way to limit the augmentation to functions that look "straightforward". I had a similar problem with the objective c runtime on macosx. It has several hand-written assembly functions that the assembly instruction profiler cannot handle correctly. The maintainer of that solib added hand-written -- I added the DynamicLoader::AlwaysRelyOnEHUnwindInfo method for this case. The unwinder will call the DynamicLoader and say "should I trust the eh_frame for this solib?" and the MacOSX DynamicLoader plugin will say yes for libobjc functions. (this was back when we never used eh_frame instructions for the currently-executing frame) That would be another way to handle this -- to whitelist the libc solib on Linux. But I think your idea of flagging eh_frame which looks hand-written/complicated is a good one too. J _______________________________________________ lldb-dev mailing list lldb-dev@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
