Commit Graph

3 Commits

Author SHA1 Message Date
Nitesh Jain e9cb0d89c4 [LLDB][MIPS] Fix TestEhFrameUnwind.py for MIPS
Reviewers: clayborg, labath

Subscribers: jaydeep, bhushan, slthakur, lldb-commits

Differential Revision: https://reviews.llvm.org/D24122

llvm-svn: 281031
2016-09-09 10:20:08 +00:00
Kate Stone b9c1b51e45 *** This commit represents a complete reformatting of the LLDB source code
*** 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
2016-09-06 20:57:50 +00:00
Ravitheja Addepally b3b972a5a8 Fix for PrintStackTraces
Summary:
The issue arises due to the wrong unwinder used for the first
stack frame, where the default unwinder returns erroneous frame
whereas the fallback would have given the correct frame had it
been used.
The following fix consists of two parts ->
 1) The first part changes the unwinding strategy, earlier the
    default unwinder was used to get 2 more stack frames and if it
    failed a fallback unwinder was used. Now we try to obtain as many
    frames (max 10) as we can get from default unwinder and also
    fallback unwinder and use the one that gives more number of frames.
    
 2) Normally unwindplans are assosciated with functions and the
    row to be used is obtained from the offset (obtained from the low_pc
    of the function symbol). Sometimes it may occur that the unwindplan
    is assosciated to the complete Elf section in which case the offset
    calculation would be wrong as the debugger uses the same offset originally
    obtained from the function symbol. Hence this offset is recalculated.

Reviewers: tberghammer, lldb-commits, labath, jasonmolenda

Subscribers: jingham

Differential Revision: http://reviews.llvm.org/D21221

llvm-svn: 274750
2016-07-07 13:00:29 +00:00