section for x86_64 and i386 targets on Darwin systems. Currently only the
compact unwind encoding for normal frame-using functions is supported but it
will be easy handle frameless functions when I have a bit more free time to
test it. The LSDA and personality routines for functions are also retrieved
correctly for functions from the compact unwind section.
This new code is very fresh -- it passes the lldb testsuite and I've done
by-hand inspection of many functions and am getting correct behavior for all
of them. There may need to be some bug fixing over the next couple weeks as
I exercise and test it further. But I think it's fine right now so I'm
committing it.
<rdar://problem/13220837>
llvm-svn: 223625
MSVC warns that not all control paths return a value when a switch
doesn't have a default case handler. Changed explicit value checks
to a default check.
Also, it caught a case where bitwise AND was being used instead of
logical AND. I'm not sure what this fixes, but presumably it is
not covered by any kind of test case.
llvm-svn: 221636
a nop). Fixes an instruction stepping problem when trying to step
over the final instructions of an epilogue.
<rdar://problem/18068877>
llvm-svn: 221241
output style can be customized. Change the built-in default to be
more similar to gdb's disassembly formatting.
The disassembly-format for a gdb-like output is
${addr-file-or-load} <${function.name-without-args}${function.concrete-only-addr-offset-no-padding}>:
The disassembly-format for the lldb style output is
{${function.initial-function}{${module.file.basename}`}{${function.name-without-args}}:\n}{${function.changed}\n{${module.file.basename}`}{${function.name-without-args}}:\n}{${current-pc-arrow} }{${addr-file-or-load}}:
The two backticks in the lldb style formatter triggers the sub-expression evaluation in
CommandInterpreter::PreprocessCommand() so you can't use that one as-is ... changing to
use ' characters instead of ` would work around that.
<rdar://problem/9885398>
llvm-svn: 219544
I wrote this originally as a part of an unwind library that was using
a different coding convention and some of that old style remained after
its integration into lldb.
llvm-svn: 216419
We decided to use assmbly profiler instead of eh_frame for frame 0 because for compiler generated code, eh_frame is usually synchronous(a.k.a. only valid at call site); and we have no way to tell if it's asynchronous or not.
But for x86 & x86_64 compiler generated code:
1. clang & GCC describes all prologue instructions in eh_frame;
2. mid-function stack pointer altering instructions can be easily detected.
So we can grab eh_frame, and use assembly profiler to augment it into asynchronous unwind table.
This change also benefits hand-written assembly; eh_frame for hand-written assembly is often asynchronous,so we have a much better chance to successfully unwind through them.
Change by Tong Shen.
llvm-svn: 216406
to recognize an epilogue that ends with a jmp to
objc_retainAutoreleaseReturnValue instead of a ret instruction.
<rdar://problem/17889928>
llvm-svn: 214783
This change has the practical effect of fixing some backtrace
scenarios that would fail with inferiors running on the Android Art
host-side JVM under Linux x86_64 on Ubuntu 14.04.
See this lldb-commits thread for more details:
http://lists.cs.uiuc.edu/pipermail/lldb-commits/Week-of-Mon-20140721/011988.html
Change by Tong Shen.
Reviewed by Jason Molenda.
Tested:
Ubuntu 14.04 x86_64, clang-3.5-built lldb.
MacOSX 10.10 Preview 4, Xcode 6 Beta 4-built lldb.
llvm-svn: 213914
This is a mechanical change addressing the various sign comparison warnings that
are identified by both clang and gcc. This helps cleanup some of the warning
spew that occurs during builds.
llvm-svn: 205390
the CFA instructions when it was profiling an -fomit-frame-pointer function
and a "volatile" register was saved on the stack (e.g. an argument register).
<rdar://problem/15036546>
llvm-svn: 191267
with prefer_file_cache == false. This is what we want to do when
the user is doing a disassemble command -- show the actual memory
contents in case the memory has been corrupted or something -- but
when we're profiling functions for stepping or unwinding
(ThreadPlanStepRange::GetInstructionsForAddress,
UnwindAssemblyInstEmulation::GetNonCallSiteUnwindP) we can read
__TEXT instructions directly out of the file, if it exists.
<rdar://problem/14397491>
llvm-svn: 190638
list have a shared pointer back to their DisassemblerLLVMC. This checkin force clears the InstructionList
in all the places we use the DisassemblerSP to stop the leaking for now. I'll go back and fix this
for real when I have time to do so.
<rdar://problem/14581918>
llvm-svn: 187473
<rdar://problem/13594769>
Main changes in this patch include:
- cleanup plug-in interface and use ConstStrings for plug-in names
- Modfiied the BSD Archive plug-in to be able to pick out the correct .o file when .a files contain multiple .o files with the same name by using the timestamp
- Modified SymbolFileDWARFDebugMap to properly verify the timestamp on .o files it loads to ensure we don't load updated .o files and cause problems when debugging
The plug-in interface changes:
Modified the lldb_private::PluginInterface class that all plug-ins inherit from:
Changed:
virtual const char * GetPluginName() = 0;
To:
virtual ConstString GetPluginName() = 0;
Removed:
virtual const char * GetShortPluginName() = 0;
- Fixed up all plug-in to adhere to the new interface and to return lldb_private::ConstString values for the plug-in names.
- Fixed all plug-ins to return simple names with no prefixes. Some plug-ins had prefixes and most ones didn't, so now they all don't have prefixed names, just simple names like "linux", "gdb-remote", etc.
llvm-svn: 181631
LLDB is crashing when logging is enabled from lldb-perf-clang. This has to do with the global destructor chain as the process and its threads are being torn down.
All logging channels now make one and only one instance that is kept in a global pointer which is never freed. This guarantees that logging can correctly continue as the process tears itself down.
llvm-svn: 178191
Calculate "can branch" using the MC API's rather than our hand-rolled regex'es.
As extra credit, allow setting the disassembly flavor for x86 based architectures to intel or att.
<rdar://problem/11319574>
<rdar://problem/9329275>
llvm-svn: 176392
- generate-vers.pl has to be called by cmake to generate the version number
- parallel builds not yet supported; dependency on clang must be explicitly specified
Tested on Linux.
- Building on Mac will require code-signing logic to be implemented.
- Building on Windows will require OS-detection logic and some selective directory inclusion
Thanks to Carlo Kok (who originally prepared these CMakefiles for Windows) and Ben Langmuir
who ported them to Linux!
llvm-svn: 175795
The results from Clang name lookups changed to
be ArrayRefs, so I had to change the way we
check for the presence of a result and the way
we iterate across results.
llvm-svn: 170927
Full UnwindPlan is trying to do an impossible unwind; in that case
invalidate the Full UnwindPlan and replace it with the architecture
default unwind plan.
This is a scenario that happens occasionally with arm unwinds in
particular; the instruction analysis based full unwindplan can
mis-parse the functions and the stack walk stops prematurely. Now
we can do a simpleminded frame-chain walk to find the caller frame
and continue the unwind. It's not ideal but given the complicated
nature of analyzing the arm functions, and the lack of eh_frame
information on iOS, it is a distinct improvement and fixes some
long-standing problems with the unwinder on that platform.
This is fixing <rdar://problem/12091421>. I may re-use this
invalidate feature in the future if I can identify other cases where
the full unwindplan's unwind information is clearly incorrect.
This checkin also includes some cleanup for the volatile register
definition in the arm ABI plugin for <rdar://problem/10652166>
although work remains to be done for that bug.
llvm-svn: 166757
the function's prologue instructions so we can re-instate that prologue
if we hit an early return mid-function. Add some additional heuristics
to differentiate between prologue and epilogue instruction sequences.
This fixes the specific problem of correctly unwinding through a function
which has an epilogue one instruction after the last prologue setup
instruction has completed.
<rdar://problem/12091139>
llvm-svn: 166465
to handle an addition class of early-return instructions we find in arm code:
tail-call optimziation returns where we restore the register state from the
function entry and jump directly (not branch & link) to another function --
when that other function returns, it will return to our caller.
Previously this mid-function epilogue sequence was not being correctly detected.
We would not re-instate the prologue setup instructions for the rest of the function
so unwinds would break from that point until the end of the function.
<rdar://problem/12502597>
llvm-svn: 166081
Make breakpoint setting by file and line much more efficient by only looking for inlined breakpoint locations if we are setting a breakpoint in anything but a source implementation file. Implementing this complex for a many reasons. Turns out that parsing compile units lazily had some issues with respect to how we need to do things with DWARF in .o files. So the fixes in the checkin for this makes these changes:
- Add a new setting called "target.inline-breakpoint-strategy" which can be set to "never", "always", or "headers". "never" will never try and set any inlined breakpoints (fastest). "always" always looks for inlined breakpoint locations (slowest, but most accurate). "headers", which is the default setting, will only look for inlined breakpoint locations if the breakpoint is set in what are consudered to be header files, which is realy defined as "not in an implementation source file".
- modify the breakpoint setting by file and line to check the current "target.inline-breakpoint-strategy" setting and act accordingly
- Modify compile units to be able to get their language and other info lazily. This allows us to create compile units from the debug map and not have to fill all of the details in, and then lazily discover this information as we go on debuggging. This is needed to avoid parsing all .o files when setting breakpoints in implementation only files (no inlines). Otherwise we would need to parse the .o file, the object file (mach-o in our case) and the symbol file (DWARF in the object file) just to see what the compile unit was.
- modify the "SymbolFileDWARFDebugMap" to subclass lldb_private::Module so that the virtual "GetObjectFile()" and "GetSymbolVendor()" functions can be intercepted when the .o file contenst are later lazilly needed. Prior to this fix, when we first instantiated the "SymbolFileDWARFDebugMap" class, we would also make modules, object files and symbol files for every .o file in the debug map because we needed to fix up the sections in the .o files with information that is in the executable debug map. Now we lazily do this in the DebugMapModule::GetObjectFile()
Cleaned up header includes a bit as well.
llvm-svn: 162860
return 0x0 as the read value instead of uninitialized
stack data so we get consistent behavior from the
emulator.
<rdar://problem/12058770>
llvm-svn: 161795
the state of the unwind instructions once the prologue has finished. If it hits an
early return epilogue in the middle of the function, re-instate the prologue after that
epilogue has completed so that we can still unwind for cases where the flow of control
goes past that early-return. <rdar://problem/11775059>
Move the UnwindPlan operator== definition into the .cpp file, expand the definition a bit.
Add some casts to a SBCommandInterpreter::HandleCompletion() log statement so it builds without
warning on 64- and 32-bit systems.
llvm-svn: 160337
a shared pointer to ease some memory management issues with a patch
I'm working on.
The main complication with using SPs for these objects is that most
methods that build up an UnwindPlan will construct a Row to a given
instruction point in a function, then add additional regsaves in
the next instruction point to that row and push it again. A little
care is needed to not mutate the previous instruction point's Row
once these are switched to being held behing shared pointers.
llvm-svn: 160214
frame pointer overwritten with the caller's fp value, return to
expressing the CFA in terms of the stack pointer.
<rdar://problem/11855862>
llvm-svn: 160150
a bit -- we're creating the UnwindPlan here, we can set the register set to
whatever is convenient for us, no need to handle different register sets.
A handful of small comment fixes I noticed while reading through the code.
llvm-svn: 159924
these functions will end in the sequence
mov %rbp, %rsp
ret
call __stack_chk_fail
instead of the usual mov, ret. The x86 assembly profiler only looked
for functions ending in 'ret' and added the Unwind row describing how to
set the CFA based on that -- the addition of the call insn (which is jumped
to earlier in the function body) threw off that inspection.
Resolves the need to "step" twice to get out of these functions when doing
source-level stepping.
<rdar://problem/11469705>
llvm-svn: 157454
Fixed the DisassemblerLLVMC disassembler to parse more efficiently instead of parsing opcodes over and over. The InstructionLLVMC class now only reads the opcode in the InstructionLLVMC::Decode function. This can be done very efficiently for ARM and architectures that have fixed opcode sizes. For x64 it still calls the disassembler to get the byte size.
Moved the lldb_private::Instruction::Dump(...) function up into the lldb_private::Instruction class and it now uses the function that gets the mnemonic, operandes and comments so that all disassembly is using the same code.
Added StreamString::FillLastLineToColumn() to allow filling a line up to a column with a character (which is used by the lldb_private::Instruction::Dump(...) function).
Modified the Opcode::GetData() fucntion to "do the right thing" for thumb instructions.
llvm-svn: 156532
objects for the backlink to the lldb_private::Process. The issues we were
running into before was someone was holding onto a shared pointer to a
lldb_private::Thread for too long, and the lldb_private::Process parent object
would get destroyed and the lldb_private::Thread had a "Process &m_process"
member which would just treat whatever memory that used to be a Process as a
valid Process. This was mostly happening for lldb_private::StackFrame objects
that had a member like "Thread &m_thread". So this completes the internal
strong/weak changes.
Documented the ExecutionContext and ExecutionContextRef classes so that our
LLDB developers can understand when and where to use ExecutionContext and
ExecutionContextRef objects.
llvm-svn: 151009
shared pointers.
Changed the ExecutionContext over to use shared pointers for
the target, process, thread and frame since these objects can
easily go away at any time and any object that was holding onto
an ExecutionContext was running the risk of using a bad object.
Now that the shared pointers for target, process, thread and
frame are just a single pointer (they all use the instrusive
shared pointers) the execution context is much safer and still
the same size.
Made the shared pointers in the the ExecutionContext class protected
and made accessors for all of the various ways to get at the pointers,
references, and shared pointers.
llvm-svn: 140298
the arm emulate instruction unwinder so you can leave it
on by default and not be overwhelmed. Set verbose mode to
get the full story on how the unwindplans were created.
llvm-svn: 139897
the appropriate registers for arm and x86_64. The register names for the
arguments that are the size of a pointer or less are all named "arg1", "arg2",
etc. This allows you to read these registers by name:
(lldb) register read arg1 arg2 arg3
...
You can also now specify you want to see alternate register names when executing
the read register command:
(lldb) register read --alternate
(lldb) register read -A
llvm-svn: 131376
Jason Molenda