The Nexus Player has a mixed abi-list, but native applications are
still x86. Move x86 ahead to prefer it over arm.
Change-Id: I3e2f3dc0da97b94078f7fd5dc3fede711603961a
Also adds the ability to pass arbitrary arguments to lcov, in case the
user needs to override this behavior.
Change-Id: I66b842f92f546fee17a7f1033ef590a3380c14c4
The --clean flag clears ANDROID_PRODUCT_OUT and ANDROID_HOST_OUT of
all coverage files. If a source file that had a coverage notes file
(a .gcno) generated for it is renamed or removed, the build system
will not clean the old file, which means the coverage tool will still
try to find coverage data.
The --prep flag clears just coverage data files. This should be done
before any coverage run, as you don't want old coverage data affecting
your results.
Change-Id: Id68395d19369eba4589daff90461a10cf7aef66d
If you are debugging a native process, SIGSEGV gets ignored by default.
The gdbclient bash function has been modified to only call the art-on
macro when running gdbclient app_processXX.
Also, print a warning in case someone is trying to debug a native
process using app_process.
Bug: 17815162
Change-Id: I0666e6713b0a03ee713be7827c5b671938f2c263
acov is a tool for gathering coverage information from a device and
generating a report from that information. To use:
1. sudo apt-get install lcov
2. Build application/library with coverage information.
3. Push the new binaries to the device.
4. Run tests with the additional environment variables:
* GCOV_PREFIX=/data/local/tmp/gcov
* GCOV_PREFIX_STRIP=`echo $(ANDROID_BUILD_TOP) | grep -o / | wc -l`
5. Run `acov`.
acov will pull all coverage information from the device, push it to the
right directories, run lcov, and display the coverage report (currently
by opening it in your browser).
Bug: 10134489
Change-Id: I604c8ec2e9fa5d23ee9c279b515ff6cfc497dfa7
This adds two commands:
art-on
art-off
To the gdbclient script for debugging ART-based executables in gdb.
The default is 'art-on'
Bug: 17409881
Change-Id: I90a1aed603e50853a40d5f5ec1c9b168dc17ddc7
This is needed by the internal stack decoding website, which
will be pulling symbols from the build servers anyway (so doesn't
need to be correctly lunched).
Bug: 16734486
Change-Id: I9190065148c0d4bb4eacec28bcc062fa95798917
Left the default symbol.ARCH value intact and changed stack_core instead
so that it will assume the ABI is arm until it sees an ABI line. This
allows compatibility for people who are used to pasting portions of a
tombstone instead of the whole thing (assuming said tombstone is arm)
while additionally supporting other architectures if a whole tombstone
is pasted in.
(cherry picked from commit 15142f793a)
Change-Id: Ide73171fc4e513b39bee74e2270252c3b32e23cd
Left the default symbol.ARCH value intact and changed stack_core instead
so that it will assume the ABI is arm until it sees an ABI line. This
allows compatibility for people who are used to pasting portions of a
tombstone instead of the whole thing (assuming said tombstone is arm)
while additionally supporting other architectures if a whole tombstone
is pasted in.
Change-Id: Ib8b5754920d2e2aa5017c29daeca59abcf4b547d
Also take into account the fact that the arm pcsr register is the
fifth entry on its line, so the stack tool previously stripped that
off.
(cherry picked from commit be4de46d09)
Change-Id: I0a937ae1a36071c3aaa5d955f56ee034dfdfe7de
Also take into account the fact that the arm pcsr register is the
fifth entry on its line, so the stack tool previously stripped that
off.
Change-Id: I1dd2d11060e572b4d8ffd8710cf1df4d970671e4
The value corresponds to whether or not the line has matched one of the
detected formats (registers, header, backtrace, etc.) and can be used to
identify what logcat lines don't correspond to one of these formats.
Change-Id: Ibd7bc5a211dcfe86ea2f92d7e7941091afff4fc4
x86 uses the x86_64 toolchain. There's no separate 32-bit toolchain.
I started to refactor so we could add FindToolchain tests, but that doesn't
work because FindToolchain depends on environment variables set up by 'lunch'.
Change-Id: I264b95e1e83a7e795f8cac49bc9e1cf497514029
Every architecture was at least slightly wrong. Rather than try to
tune the heuristics, let's just keep lists of all the registers.
Also start adding some unit tests.
Change-Id: I490dcc9855f7af1e3529734711400f366ffc4e0f
This includes the fairly large change of refactoring stack_core.py into
a class so that its behavior is compatible with adbs. Additionally, if
the ABI line does not come before lines that require it to determine
proper widths (registers, stack), then it will assume that the ABI is
32 bit and not 64.
Change-Id: I6ad84a55337d86d25f7f8197048dc93868b0a01a
This fixes the bug where we can't (currently) find the toolchain
for arm because it's at a different GCC version (4.8) from arm64 (4.9).
Change-Id: I22351af55298255f3ac4adfcae7e20080712fba4
