*** to conform to clang-format’s LLVM style. This kind of mass change has
*** two obvious implications:
Firstly, merging this particular commit into a downstream fork may be a huge
effort. Alternatively, it may be worth merging all changes up to this commit,
performing the same reformatting operation locally, and then discarding the
merge for this particular commit. The commands used to accomplish this
reformatting were as follows (with current working directory as the root of
the repository):
find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} +
find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ;
The version of clang-format used was 3.9.0, and autopep8 was 1.2.4.
Secondly, “blame” style tools will generally point to this commit instead of
a meaningful prior commit. There are alternatives available that will attempt
to look through this change and find the appropriate prior commit. YMMV.
llvm-svn: 280751
as an asynchronous unwind plan source.
Two small fixes to the compact unwind dumper tool for
armv7 encodings.
A change to DWARFCallFrameInfo to strip the 0th bit on
addresses in eh_frame sections when armv7. In the
clang generated examples I have, the 0th bit is set for
thumb functions and that's causing the unwinder to pick
the wrong function for eh_frame info.
llvm-svn: 271970
systems (ios, tvos, watchos). It's a simple format to use now that
I have i386/x86_64 supported already.
The unwind instructions are only valid at call sites -- that is,
when lldb is unwinding a frame in the middle of the stack. It
cannot be used for the currently executing frame; it has no information
about prologues/epilogues/etc.
<rdar://problem/12062336>
llvm-svn: 270658
i386/x86_64 functions. The stack size was being multiplied by the
pointer size incorrectly. The register permutation placeholders
(UNWIND_X86_REG_NONE) were decrementing the stack offset of the
saved registers when it should not have been.
<rdar://problem/19570035>
llvm-svn: 226889
The compact unwind importer is getting the wrong unwind info for one
case that I found. I haven't been able to fix the problem tonight
and I don't want to leave TOT behaving incorrectly, so just ignore
compact unwind until I can get to the bottom of this.
llvm-svn: 224321
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
for x86_64. i386, arm, arm64 aren't handled yet but those are minor
variations on this format.
This commit also adds code to read the symbol table out of the
binary and read the LC_FUNCTION_STARTS to augment the symbol table
with the start addresses of all the functions - and print the
function names when showing the unwind info.
llvm-svn: 222951
UNWIND_X86_64_MODE_STACK_IND mode is almost correct; extra stack
space allocated before the reg saves isn't handled right. Still a
little wobbily on the file addresses of functions. Finally understand
how the 6 registers that may be saved are ordered in just 10 its
of space -- the Lehmer code for the registers is derived and then
the sequence is encoded in a variable base number. Added some
comments with references to what the code is doing so it'll be
easier for others to track down.
llvm-svn: 222884
information from the compact unwind section used on darwin
for exception handling, and dump that information..
The UNWIND_X86_64_MODE_RBP_FRAME and UNWIND_X86_64_MODE_DWARF
entries look to be handled correctly.
UNWIND_X86_64_MODE_STACK_IMMD and UNWIND_X86_64_MODE_STACK_IND
are still a work in progress.
Only x86_64 is supported right now. Given that this is an
experiment in parsing the section contents, I don't expect to
add other architectures; they are trivial variations on this
arch. There exists a real dumper included in the Xcode tools,
unwinddump.
llvm-svn: 222127
Jason Molenda