1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
|
- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ----
- LLDB for Renderscript Test Suite
-
- 16/03/2016
- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ----
Overview:
The LLDB for Renderscript test suite is written in python and relies on
LLDB's python bindings. The test suite will push several test app's onto
a target device, and makes coordinated use of LLDB and ADB to run automated
debug sessions.
Set up the test suite:
Check out the AOSP and build it for your target. Navigate to
/frameworks/rs/test/lldb and type mm. This should successfully build the
binaries that the testsuite uses. They will be placed in
<path to out folder>/target/product/<product code name>/data/app, system/lib
and system/bin.
Prerequisite:
An lldb-server executable must be present on your device/emulator.
LLDB must be compiled on your host machine along with its python interface.
lldb-server and lldb should be built from the same source revisions.
Running the test suite:
The test suite can be run via the following command:
> python run_tests.py [-h]
[--config path]
[--device DEVICE]
[--test path]
[--install-only]
[--no-install]
[--no-uninstall]
[--print-to-stdout]
[--verbose]
[--wimpy]
[--run-emu]
[--adb-path ADB_PATH]
[--aosp-product-path AOSP_PRODUCT_PATH]
[--blocklist BLOCKLIST [BLOCKLIST ...]]
[--device-port DEVICE_PORT]
[--emu-cmd EMU_CMD]
[--host-port HOST_PORT]
[--lldb-path LLDB_PATH]
[--lldb-server-path-device LLDB_SERVER_PATH_DEVICE]
[--lldb-server-path-host LLDB_SERVER_PATH_HOST]
[--log-file-path LOG_FILE_PATH]
[--results-file-path RESULTS_FILE_PATH]
[--timeout TIMEOUT]
optional arguments:
-h, --help show this help message and exit
--config path, -c path
Path to a custom config file.
--device DEVICE, -d DEVICE
Specify the device id of the device to test on.
--test path, -t path Specify a specific test to run.
--install-only It only runs the pre-run stage of the test suite. It
installs the required APKs but does not execute the
tests.
--no-install, -n Stop the test suite installing apks to device.
--no-uninstall Stop the test suite uninstalling apks after
completion.
--print-to-stdout Print all logging information to standard out.
--verbose, -v Store extra info in the log.
--wimpy, -w Test only a core subset of features.
--run-emu Spawn an emulator and run the test suite on that.
Specify the emulator command line in the config file
or with -emu-cmd.
--adb-path ADB_PATH Path to android debug bridge on the host.
--aosp-product-path AOSP_PRODUCT_PATH
The path to the "out" folder of the AOSP repository.
--blocklist BLOCKLIST [BLOCKLIST ...]
Provide a test blocklist for skipping specific tests.
To specify the blocklist from the command line the
following can be used: --blocklist test1.py test2.py
...
--device-port DEVICE_PORT
Specify the port number that lldb-server (on the
device) listens on. When lldb-server is spawned on the
device it will listen on this port. Each successive
test will increment onwards from this port.
--emu-cmd EMU_CMD The command line for the emulator (if using -run-emu).
--host-port HOST_PORT
Specify host port which lldb-server will be forwarded
to. Specify the starting host port number that lldb-
server (on the target) will be forwarded to on the
host. Each successive test will increment onwards from
this initial port.
--lldb-path LLDB_PATH
The path to lldb executable on the host.
--lldb-server-path-device LLDB_SERVER_PATH_DEVICE
Path to the lldb-server executable on the device.
--lldb-server-path-host LLDB_SERVER_PATH_HOST
Path to the lldb-server executable on host (if using
-run-emu).
--log-file-path LOG_FILE_PATH
The path to the file where the log will be written.
--results-file-path RESULTS_FILE_PATH
The path to the file where junit results.xml will be
written.
--timeout TIMEOUT Timeout period for a single command, expressed in
seconds
An optional config file can be passed to the test suite which will provide
details of your specific environment. The user file should define a custom
class inheriting from Config in config.py. The class Config presents the
default set of options, available to be overridden.
All options in the config file can also be specified on the command line.
If your config and command line do not specify a path to the host lldb,
the PYTHONPATH environment variable must be set. The appropriate value to
set this to can be obtained by running the following command:
> lldb -P
This will print out a path to the lldb python bindings on your local machine.
Build Requirements:
The following revisions are from the llvm git mirror:
llvm : 5786b73
clang: b6d0b32
lldb : 98712eb
lldb has the following dependencies:
Python2.7.6
swig2.0
lldb-server
Building LLDB python bindings:
Linux:
Build instructions for Linux lldb can be found on the official lldb web
page:
http://lldb.llvm.org/build.html
The following CMake variables should be enabled when generating:
LLDB_ENABLE_PYTHON_SCRIPTS_SWIG_API_GENERATION = True
As a post build step, swig will generate the python bindings for lldb.
Windows:
Prerequisites:
Visual Studio 2015
Custom x64 Python2.7.10 package:
http://p-nand-q.com/python/2015.08.07-Python2710-x64-vs2015.7z
Swig Version 3.0.5 (Added to the $PATH)
Cmake 3.4.0 (So we can generate Visual Studio 2015 solutions)
Build Python for Windows:
http://p-nand-q.com/python/building-python-27-with-vs2010.html
The important thing here is that the above python distribution
contains debug versions of the libraries and is built with the same
Visual Studio version we are using so the runtimes do not conflict.
Build LLDB on Windows:
Select the Cmake generator "Microsoft Visual Studio 2015 Win64".
The following CMake variables should be enabled when generating:
LLDB_DISABLE_PYTHON=False
LLDB_RELOCATABLE_PYTHON=False
PYTHON_HOME=<path to the above python release>
Using cmake-gui is a good idea and lets you make sure that swig has
been correctly detected.
In the CMake configure step, you should see something similar to the
following:
-- Found Python version 2.7.9
-- LLDB Found PythonExecutable: E:/Python27/python.exe and
E:/Python27/python_d.exe
-- LLDB Found PythonLibs: E:/Python27/libs/python27.lib and
E:/Python27/libs/python27_d.lib
-- LLDB Found PythonDLL: E:/Python27/python27.dll and
E:/Python27/python27_d.dll
-- LLDB Found PythonIncludeDirs: E:/Python27/Include
LLDB version: 3.8.0
Could NOT find Doxygen (missing: DOXYGEN_EXECUTABLE)
Found PythonInterp:
$<$<CONFIG:Debug>:E:/Python27/python_d.exe>$<$<NOT:$<CONFIG:Debug>>:E:/Python27/python.exe>
(found version "1.4")
Build LLDB as a RelWithDebInfo build, because debug builds of lldb
produce an lldb_d.pyd file, but the __init__.py still refers to
lldb.pyd.
The LLDB python bindings should have built in
"llvm_build\RelWithDebInfo\lib\site-packages\lldb". Point the test
suite towards "llvm_build\RelWithDebInfo\bin\lldb.exe".
When running the test suite itself, make sure to use the python
executable from the custom package.
A typical test transcript:
Located ADB
Located device ZX1G427S2S
Pushing all tests...
Pushed all tests
Pre run complete
Found 86 tests
Running test_allocation_dump_2_cpp.py: PASS
Running test_breakpoint_fileline_multiple_rs_files_cpp.py: PASS
Running test_read_local_cpp.py: PASS
Running test_breakpoint_kernel_multiple_rs_files_cpp.py: PASS
Running test_multiple_rs_files_cpp.py: PASS
Running test_breakpoint_kernel_all_multiple_rs_files_cpp.py: PASS
Running test_dwarf_lang_cpp.py: PASS
Running test_write_global_element_cpp.py: PASS
Running test_allocation_list_cpp.py: PASS
Running test_breakpoint_coordinate_cpp.py: PASS
Running test_rs_consts_cpp.py: PASS
Running test_allocation_file_cpp.py: PASS
Running test_allocation_dump_1_cpp.py: PASS
Running test_source_step_cpp.py: PASS
Running test_breakpoint_kernel_2_cpp.py: PASS
Running test_backtrace_cpp.py: PASS
Running test_language_subcmds_no_debug_cpp.py: PASS
Running test_breakpoint_kernel_1_cpp.py: PASS
Running test_language_subcmds_cpp.py: PASS
Running test_write_global_cpp.py: PASS
Running test_invoke_fun_cpp.py: PASS
Running test_breakpoint_fileline_cpp.py: PASS
Running test_write_local_cpp.py: PASS
Running test_breakpoint_kernel_all_cpp.py: PASS
Running test_write_local_element_cpp.py: PASS
Running test_call_api_funs_cpp.py: PASS
Running test_coordinates_cpp.py: PASS
Running test_read_global_cpp.py: PASS
Running test_language_subcmds.py: PASS
Running test_coordinates.py: PASS
Running test_language_subcmds_no_debug.py: PASS
Running test_read_local.py: PASS
Running test_call_api_funs.py: PASS
Running test_breakpoint_kernel_1.py: PASS
Running test_breakpoint_fileline.py: PASS
Running test_breakpoint_fileline_multiple_rs_files.py: PASS
Running test_rs_consts.py: PASS
Running test_invoke_fun.py: PASS
Running test_write_local_element.py: PASS
Running test_source_step.py: PASS
Running test_allocation_file.py: PASS
Running test_allocation_list.py: PASS
Running test_breakpoint_kernel_multiple_rs_files.py: PASS
Running test_allocation_dump_1.py: PASS
Running test_breakpoint_kernel_all.py: PASS
Running test_allocation_dump_2.py: PASS
Running test_allocation_dump_struct.py: PASS
Running test_read_global.py: PASS
Running test_language.py: PASS
Running test_dwarf_lang.py: PASS
Running test_breakpoint_coordinate.py: PASS
Running test_write_global.py: PASS
Running test_multiple_rs_files.py: PASS
Running test_write_global_element.py: PASS
Running test_breakpoint_kernel_all_multiple_rs_files.py: PASS
Running test_breakpoint_kernel_2.py: PASS
Running test_write_local.py: PASS
Running test_backtrace.py: PASS
Running test_call_api_funs_jni.py: PASS
Running test_invoke_fun_jni.py: PASS
Running test_allocation_dump_1_jni.py: PASS
Running test_breakpoint_fileline_multiple_rs_files_jni.py: PASS
Running test_allocation_file_jni.py: PASS
Running test_breakpoint_fileline_jni.py: PASS
Running test_source_step_jni.py: PASS
Running test_coordinates_jni.py: PASS
Running test_rs_consts_jni.py: PASS
Running test_breakpoint_kernel_all_multiple_rs_files_jni.py: PASS
Running test_multiple_rs_files_jni.py: PASS
Running test_allocation_dump_2_jni.py: PASS
Running test_allocation_list_jni.py: PASS
Running test_write_local_element_jni.py: PASS
Running test_breakpoint_kernel_all_jni.py: PASS
Running test_breakpoint_coordinate_jni.py: PASS
Running test_language_subcmds_no_debug_jni.py: PASS
Running test_read_local_jni.py: PASS
Running test_dwarf_lang_jni.py: PASS
Running test_breakpoint_kernel_2_jni.py: PASS
Running test_breakpoint_kernel_multiple_rs_files_jni.py: PASS
Running test_write_global_element_jni.py: PASS
Running test_breakpoint_kernel_1_jni.py: PASS
Running test_read_global_jni.py: PASS
Running test_language_subcmds_jni.py: PASS
Running test_write_global_jni.py: PASS
Running test_backtrace_jni.py: PASS
Running test_write_local_jni.py: PASS
Uninstalled/Deleted all tests
86 of 86 passed
100% rate
|
