Following suggestions in b/194659728, update the python script to work
under python3.
Previous failure:
Traceback (most recent call last):
File "/android3/android/master/development/scripts/lldbclient.py", line 413, in <module>
main()
File "/android3/android/master/development/scripts/lldbclient.py", line 405, in main
do_main()
File "/android3/android/master/development/scripts/lldbclient.py", line 400, in do_main
raw_input("Press enter to shut down lldb-server")
NameError: name 'raw_input' is not defined
Bug: none
Test: "lldbclient.py --setup-forwarding vscode-lldb -r
/data/nativetest64/inputflinger_tests/inputflinger_tests
--gtest_filter=PalmRejectorTest.GenericAxisValue_IsNotSet"
Change-Id: I21d977cbc580894d6e2eb2f2f56dec04c65b0416
... instead of manually parsing soong/cc/config/global.go
Also hard-code clang_base in gdbclient.py to 'prebuilts/clang/host' as
it's unlikely to change in global.go.
Test: acov-llvm.py flush
Test: verify gdbclient.read_toolchain_config() in the interpreter
Change-Id: I28ed4416749edcd5d623598eb65eeb7891b657ae
Add support for using lldb with vscode.
Test: lldbclient.py --setup-forwarding vscode -r dalvikvm
Bug: 176158605
Change-Id: I92a08b3b02a27a14be586582fe57acdd670a9ada
Binaries built from RBE are using a source path under /b/f/w. Also map that to local source path.
Test: lldbclient.py -r /system/bin/ls
Change-Id: I02a90a9c827189a14b2d83485ed2abda68f9e084
ro.product.name can be individual device name and not the lunch target
name.
466e289dc8 removed this check but we
still need this.
Bug: 166071019
Test: gdbclient.py -n vold # on eve
Change-Id: I60fc20e6cc02ca6dd01fef609c7f60e76c580876
1. Sets up source mapping so that people can run from other directories.
2. Removes PYTHONHOME. It is embedded into the binary.
Change-Id: Ic7a7f1483dc645d890b7e0f3dcbb0ebb169794ac
gdb looks for an executable's dynamic linker using the PT_INTERP setting
from the executable. That value can be various things:
- /system/bin/linker[64]
- /system/bin/linker_asan[64]
- /system/bin/bootstrap/linker[64]
Currently, only the bootstrap linker is available in the sysroot/symbols
directory. The ordinary and ASAN linkers are symlinks on the target and
are missing from the sysroot (aka symbols) directory.
Use the executable's PT_INTERP value to find the symbolized linker binary
and add it to the solib search path. If necessary, copy or pull a linker
binary.
Test: gdbclient.py -r ls
"info sharedlib" shows $OUT/symbols/apex/com.android.runtime.debug/bin/linker64
Test: gdbclient.py -r /data/nativetest64/bionic-unit-tests/bionic-unit-tests
"info sharedlib" shows $OUT/symbols/system/bin/bootstrap/linker64
Test: m asan_test
gdbclient.py -r /data/nativetest64/asan_test/asan_test
"info sharedlib" shows /tmp/gdbclient-linker-HunVs9/linker_asan64
Bug: http://b/134183407
Change-Id: I7f79943dcd9ec762d1aaf21178bb6ab3eff40617
This adds a new --setup-forwarding {gdb|vscode} flag that will make
gdbclient.py (1) setup the port forwarding needed to connect to a
remote process and (2) print the commands/configuration needed to use
the frontend of your choice to run the debugger. Currently it supports
gdb and visual-studio code. In order to avoid using up all the ports
the gdbclient.py program will not exit until directed by user input,
holding the ports open until this occurs.
To use:
```
% ./development/scripts/gdbclient.py -n com.android.contacts --setup-forwarding vscode
Redirecting gdbserver output to /tmp/gdbclient.log
{
"miDebuggerPath": "/fast-2/allight/aosp/prebuilts/gdb/linux-x86/bin/gdb",
"program": "/fast-2/allight/aosp/out/target/product/walleye/symbols/system/bin/app_process64",
"setupCommands": [
{
"text": "-enable-pretty-printing",
"description": "Enable pretty-printing for gdb",
"ignoreFailures": true
},
{
"text": "-environment-directory /fast-2/allight/aosp",
"description": "gdb command: dir",
"ignoreFailures": false
},
{
"text": "-gdb-set solib-search-path /fast-2/allight/aosp/out/target/product/walleye/symbols/system/lib64/:/fast-2/allight/aosp/out/target/product/walleye/symbols/system/lib64/hw:/fast-2/allight/aosp/out/target/product/walleye/symbols/system/lib64/ssl/engines:/fast-2/allight/aosp/out/target/product/walleye/symbols/system/lib64/drm:/fast-2/allight/aosp/out/target/product/walleye/symbols/system/lib64/egl:/fast-2/allight/aosp/out/target/product/walleye/symbols/system/lib64/soundfx:/fast-2/allight/aosp/out/target/product/walleye/symbols/vendor/lib64/:/fast-2/allight/aosp/out/target/product/walleye/symbols/vendor/lib64/hw:/fast-2/allight/aosp/out/target/product/walleye/symbols/vendor/lib64/egl",
"description": "gdb command: set solib-search-path",
"ignoreFailures": false
},
{
"text": "-gdb-set solib-absolute-prefix /fast-2/allight/aosp/out/target/product/walleye/symbols",
"description": "gdb command: set solib-absolute-prefix",
"ignoreFailures": false
},
{
"text": "-interpreter-exec console \"source /fast-2/allight/aosp/development/scripts/gdb/dalvik.gdb\"",
"description": "gdb command: source art commands",
"ignoreFailures": false
}
],
"name": "(gdbclient.py) Attach app_process64 (port: 5039)",
"miDebuggerServerAddress": "localhost:5039",
"request": "launch",
"type": "cppdbg",
"cwd": "/fast-2/allight/aosp",
"MIMode": "gdb"
}
Paste the above json into .vscode/launch.json and start the debugger as
normal. Press enter in this terminal once debugging is finished to shutdown
the gdbserver and close all the ports.
Press enter to shutdown gdbserver
```
Or for gdb:
```
% ./development/scripts/gdbclient.py -n com.android.contacts --setup-forwarding gdb
Redirecting gdbserver output to /tmp/gdbclient.log
file '/fast-2/allight/aosp/out/target/product/walleye/symbols/system/bin/app_process64'
directory '/fast-2/allight/aosp'
set solib-absolute-prefix /fast-2/allight/aosp/out/target/product/walleye/symbols
set solib-search-path /fast-2/allight/aosp/out/target/product/walleye/symbols/system/lib64/:/fast-2/allight/aosp/out/target/product/walleye/symbols/system/lib64/hw:/fast-2/allight/aosp/out/target/product/walleye/symbols/system/lib64/ssl/engines:/fast-2/allight/aosp/out/target/product/walleye/symbols/system/lib64/drm:/fast-2/allight/aosp/out/target/product/walleye/symbols/system/lib64/egl:/fast-2/allight/aosp/out/target/product/walleye/symbols/system/lib64/soundfx:/fast-2/allight/aosp/out/target/product/walleye/symbols/vendor/lib64/:/fast-2/allight/aosp/out/target/product/walleye/symbols/vendor/lib64/hw:/fast-2/allight/aosp/out/target/product/walleye/symbols/vendor/lib64/egl
source /fast-2/allight/aosp/development/scripts/gdb/dalvik.gdb
python
def target_remote_with_retry(target, timeout_seconds):
import time
end_time = time.time() + timeout_seconds
while True:
try:
gdb.execute("target extended-remote " + target)
return True
except gdb.error as e:
time_left = end_time - time.time()
if time_left < 0 or time_left > timeout_seconds:
print("Error: unable to connect to device.")
print(e)
return False
time.sleep(min(0.25, time_left))
target_remote_with_retry(':5039', 5)
end
Paste the above gdb commands into the gdb frontend to setup the gdbserver
connection. Press enter in this terminal once debugging is finished to
shutdown the gdbserver and close all the ports.
Press enter to shutdown gdbserver
```
Test: ./development/scripts/gdbclient.py -n com.android.contacts --setup-forwarding vscode
Perform debugging.
Change-Id: Ifa105cfbb100c4ba872b85c1c609d49a4f194d8b
Switching from remote to extended-remote allows the program being
debugged to be restarted like a normal non-remote program.
Test: Used gdbclient debugging ICU things for a while, restarted often
Bug: None
Change-Id: Ia295749b9aa86727479d760d7c743f98a06fa6d4
make dumpvar takes forever (~0.45s per variable on my machine), and the
information we want from it is already available in the environment.
Construct the paths we need ourselves, instead of relying on make to do
it for us, shaving off about a second from a gdbclient.py invocation.
Test: gdbclient.py -r ls
Change-Id: I8c563da726c8f61a23e2eb701f2f272a4c71d713
gdbclient.py -r allows to provide an executable to be run on the target.
Before this patch the absolute path of the executable had to be
provided. This was inconvenient as the user has to first look up for the
exe on the target before debuging it.
With this patch, gdbclient.py will look for the executable on the
target if an absolute path is not provided.
Test: gdbserver -r ls
Change-Id: I610fd0a57b034ba8864874eeb1f7345d4a7daad9
Signed-off-by: Kevin Rocard <krocard@google.com>
Properties can include \n so get_props isn't sound, and it's not obvious how
to fix it (without adding something like cat's -v to getprop, which wouldn't
help the intended use case of working with arbitrary old devices).
Bug: https://issuetracker.google.com/37093233
Test: gdbclient -r /system/bin/date
Change-Id: I96042fd44f1de17974968954fab6c916a9d13b61
Switch from assuming that "root" meant su to an explicit prepended
argument, to allow things like `gdbclient.py --user shell`.
Test: gdbclient.py --user shell -r /system/bin/ls
Change-Id: I9d02eea7c6d79898ed8b13817e009630b0f9536a
Make sure gdb knows where the source files are, even when gdbclient.py
isn't being run from the root directory.
Change-Id: I8f604ba58f4c06b26f2a1f8e917e2a1c1c137ccd
gdbclient.py is always downloading the stripped version of executable
files from the device. This CL first tries to find the unstripped local
file before falling back to the stripped version.
Bug: http://b/24947939
Change-Id: I7a49d0d8b28590ee99ce892d3e3476921f4ae974
Python's subprocess.check_output() cwd argument does not change the PWD
environmental variable, which is what dumpvar.mk uses to turn relative
paths into absolute paths. This led to incorrect symbol paths when
gdbclient was not run from the root directory.
This CL fixes the bug by manually setting PWD before calling the
makefile. It's possible that dumpvar.mk should be using a different
method to get the current directory, but I was scared to change any
core build logic and this approach seems to work just fine.
Change-Id: Ibe3db0bef6694934c512918f7562029313b1deae
gdbclient.py can sometimes attempt to connect to the server before it's
ready, especially when debugging on an emulator. This CL adds
functionality to retry the connection for up to 5 seconds.
Bug: http://b/24671386
Change-Id: I65e77f918c3ea8433f992e67122cd48e3647c67b
