You may want to just bootstrap up with the super-simplistic UnwindMacOSXFrameBackchain() -- but it looks like you'll need to do a little cleanup to get it working again. I would not plan on living on UnwindMacOSXFrameBackchain() for long, it is a very simple way of doing backtraces and it will get many complicated things wrong.
On Aug 22, 2013, at 3:50 PM, Jason Molenda <[email protected]> wrote: > You'll want to use UnwindLLDB. > > Your ABI plugin may need to define the following methods (used by UnwindLLDB, > RegisterContextLLDB): > > CallFrameAddressIsValid > CodeAddressIsValid > StackUsesFrames > FixCodeAddress > CreateDefaultUnwindPlan (*) > FunctionCallsChangeCFA > CreateFunctionEntryUnwindPlan (*) > RegisterIsVolatile (*) > > > The (*) ones are important for unwinding. > > For CreateDefaultUnwindPlan, the "default unwind plan" is how lldb will > unwind a stack frame by default. e.g. on architectures where there is a > frame pointer, dereferencing the frame pointer address often gives you the > calling frame's frame pointer, and one word off of that you'll find the > caller's saved pc value. > > For CreateFunctionEntryUnwindPlan, this is the unwind plan which tells lldb > how to find the caller function when it is sitting on the first instruction > of a function. e.g. it was single-instruction-stepping along, it stepped > into a new function, and it needs to find the caller. > > RegisterIsVolatile tells lldb whether a register is callee-saved or not. > Whether it is preserved or not. Whether it is spilled or not. Whether it is > volatile or not. Different people use different terms. Your ABI doc will > specify which registers are volatile or not. NB: on architectures that use > registers for argument passing, the argument registers are "volatile" because > they are assumed to be reused/overwritten on any function call. > > > Both x86 and arm have UnwindAssembly implementations (e.g. > source/Plugins/UnwindAssembly/x86/UnwindAssembly-x86.cpp) - the > UnwindAssembly class looks at the assembly instructions of a function and > creates an UnwindPlan based on them. It is done statically so flow control > is ignored. It's not ideal but the unwind instructions in the eh_frame > section are not necessary valid at non-call sites in a program, and we found > that we can get more accurate debugger behavior by inspecting the > instructions manually than by following eh_frame. > > The UnwindAssembly-generated UnwindPlan is used when unwinding the current > frame (frame 0) in a program. > > Above frame 0, we are guaranteed to be at a call site and so we will prefer > to use eh_frame instructions if they are available. > > > For you, starting with the CreateDefaultUnwindPlan and > CreateFunctionEntryUnwindPlan should be enough to bootstrap. If your > environment has eh_frame, using that would be a good idea. Implementing a > UnwindAssembly for ppc may be some real work - I would not take that on > initially. > > > > > On Aug 22, 2013, at 3:35 PM, Félix Cloutier <[email protected]> wrote: > >> I'm making a stub for an emulator that executes PPC code. >> >> Félix >> >> Le 2013-08-22 à 18:30:09, Jason Molenda <[email protected]> a écrit : >> >>> >>> On Aug 22, 2013, at 3:27 PM, Jason Molenda <[email protected]> wrote: >>> >>>> >>>> On Aug 22, 2013, at 1:26 PM, Félix Cloutier <[email protected]> wrote: >>>> >>>>> #5 lldb_private::Mutex::Locker::Locker(lldb_private::Mutex&) at >>>>> lldb/source/Host/common/Mutex.cpp:113 >>>>> #6 lldb_private::Unwind::GetFrameCount() at >>>>> lldb/include/lldb/Target/Unwind.h:51 >>>>> #7 UnwindMacOSXFrameBackchain::DoGetFrameInfoAtIndex(unsigned int, >>>>> unsigned long long&, unsigned long long&) at >>>>> lldb/source/Plugins/Process/Utility/UnwindMacOSXFrameBackchain.cpp:59 >>>>> #8 lldb_private::Unwind::GetFrameInfoAtIndex(unsigned int, >>>>> unsigned long long&, unsigned long long&) at >>>>> lldb/include/lldb/Target/Unwind.h:78 >>>>> #9 lldb_private::StackFrameList::GetFramesUpTo(unsigned int) at >>>>> lldb/source/Target/StackFrameList.cpp:304 >>>> >>>> >>>> I'll look at this a bit. >>>> >>>> The fact that you're picking up the UnwindMacOSXFrameBackchain is probably >>>> the source of the problem. This was an early unwinder written by Greg >>>> back before we had UnwindLLDB and RegisterContextLLDB - it hasn't been >>>> modified in a couple of years except for mechanical changes made across >>>> the source base. >>> >>> What architecture are you debugging? Thread::GetUnwinder() should use >>> UnwindLLDB for x86_64, i386, arm and thumb. It will use >>> UnwindMacOSXFrameBackchain for any other architectures .... but it should >>> probably just fail instead. >> > _______________________________________________ lldb-dev mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
