[Lldb-commits] [PATCH] D63667: Support __kernel_rt_sigreturn in frame initialization

[Jason Molenda via Phabricator via lldb-commits]

jasonmolenda added a comment.

This looks good.  Over in RegisterContextLLDB::GetFullUnwindPlanForFrame there's a behaves_like_zeroth_frame bool with similar setup -- in that case, it's trying to decide what type of UnwindPlan to pick for the frame, either one that is synchronous ("valid only at call sites / throwable locations") or asynchronous ("valid at every instruction").  For a behaves_like_zeroth_frame it needs to pick an asynchronous unwind plan.  You may want to look at that too.

I didn't know about the S augmentation letter in eh_frame.  See DWARFCallFrameInfo::ParseCIE / DWARFCallFrameInfo::FDEToUnwindPlan, that's where those are parsed.  Each function with eh_frame has an FDE, and the FDE will refer to a CIE with basic setup information.  Usually multiple FDE entries point to a single CIE, with the CIE specifying the things that are common among them all (usually things like the initial unwind state on function entry and such). We could add the flag to the UnwindPlan object.  This would basically be telling us the same thing that IsTrapHandlerSymbol() is telling us, right, but I'm not sure the order of operations would make it easy to use - we pick out an unwind plan (which might be eh_frame based) too late, if I remember the codeflow right.  It'd be a good change to capture that information from the eh_frame though, even if we don't see a clear way to use it right now.

We're going to pick up a FuncUnwinders object (an object with all the unwind plans for a given function) pretty early I bet, but we don't want to force a parse of eh_frame when we're creating that object if we can avoid it - parsing the eh_frame section of a binary the first time (and creating an index into it) is relatively slow, so we try to put it off if we can.

fwiw, and I think you've got this figured out already, with asynchronous signals we want to say (1) don't decrement the pc value when doing symbol lookups, (2) all registers can be retrieved (normally only callee-spilled aka non-volatile registers can be retrieved mid-stack), (3) we need to pick an asynchronous unwind plan because we may not be at a throwable / function call location like we normally are mid-stack.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D63667/new/

https://reviews.llvm.org/D63667