Commit Graph

2 Commits

Author SHA1 Message Date
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
Todd Fiala 5bc56a4b34 android: add a command script to help display mixed Java/native backtraces.
This script supports displaying developer-focused backtraces when working
with mixed Java and C/C++ stack frames within lldb.  On Android, this represents
just about every app, since all apps start in Java code.

The script currently supports the Art JVM when run on host-side x86_64 and x86,
but does require a patch not yet accepted in AOSP:
AOSP patch: https://android-review.googlesource.com/#/c/106523/

The backtraces will hide Art VM machinery for interpreted and AOT code
and display the Java file/line numbers for Java code, while displaying
native backtrace info for native frames.  Effectively the developer will
get an app-centric view of the call stack.

This script is not yet tested on device-side Art nor is it tested on
any architecture other than x86_64 or x86 32-bit.  Several changes were
needed on the AOSP side to enable it to work properly for x86_64 and x86, 
so it is quite likely we'll need to do something similar for other cpu
architectures as well.

Change by Tong Shen

llvm-svn: 218315
2014-09-23 16:28:01 +00:00