Okay, I'll look into that. Thanks! Félix
Le 2013-08-22 à 19:00:15, Jason Molenda <[email protected]> a écrit : > 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
