I added some tests for the case where the breakpoints take immediately
to the extant test case, and made a new test case for when the source
regex breakpoint will be set in a dlopen-ed library.
I also noticed when doing this that "lldbutil.run_to_source_breakpoint
can't handle the case where the breakpoint will be in a dlopen-ed
library, since it requires the breakpoint to have at least 1 location
before run. I fixed that by adding a parameter to say whether a
before run location is expected.
Differential Revision: https://reviews.llvm.org/D111920
Introduce three new stop reasons for fork, vfork and vforkdone events.
This includes server support for serializing fork/vfork events into
gdb-remote protocol. The stop infos for the two base events take a pair
of PID and TID for the newly forked process.
Differential Revision: https://reviews.llvm.org/D100196
Respect --apple-sdk <path> if it's specified. If the SDK is simply
mounted from some disk image, and not actually installed, this is the
only way to use it.
Differential Revision: https://reviews.llvm.org/D99746
In sanitized builds the last packet this function finds for the
TestMacCatalyst and TestPlatformSimulator tests is for the asan runtime.
```
< 69> send packet: $jGetLoadedDynamicLibrariesInfos:{"solib_addresses":[4296048640]}]#3a <
715> read packet: ${"images":[{"load_address":4296048640,"mod_date":0,"pathname":
"/Users/buildslave/jenkins/workspace/lldb-cmake-sanitized/host-compiler/lib/clang/12.0.0/lib/darwin/libclang_rt.asan_osx_dynamic.dylib",
"uuid":"8E38A2CD-753F-3E0F-8EB0-F4BD5788A5CA",
"min_version_os_name":"macosx","min_version_os_sdk":"10.9",
"mach_header":{"magic":4277009103,"cputype":16777223,"cpusubtype":3,"filetype":6,
"flags":43090053}],"segments":[{"name":"__TEXT","vmaddr":0,"vmsize":565248,"fileoff":0,
"filesize":565248,"maxprot":5}],{"name":"__DATA","vmaddr":565248,"vmsize":13152256,"fileoff":565248,
"filesize":20480,"maxprot":3}],{"name":"__LINKEDIT","vmaddr":13717504,"vmsize":438272,"fileoff":585728,
"filesize":435008,"maxprot":1}]]}]]}]#00
```
This just fetches the last package which has fetch_all_solibs and we know
it will contain the image of our test executable to get the tests running again.
We've been seeing this failure on green dragon when the system is
under high load. Unfortunately this is outside of LLDB's control.
Differential Revision: https://reviews.llvm.org/D85542
This patch is similar in spirit to https://reviews.llvm.org/D84480,
but does the maccatalyst/macosx disambiguation. I also took the
opportunity to factor out the gdb-remote packet log scanning used by
several testcases into lldbutil functions.
rdar://problem/66059257
Differential Revision: https://reviews.llvm.org/D84576
file:line:column form that we use to print out locations. Since we
print them this way it makes sense we also accept that form.
Differential Revision: https://reviews.llvm.org/D83975
Even non-remote targets may need to set the launch environment
((DY)LD_LIBRARY_PATH, specifically) to run successfully.
Also, add an assertion to better detect the case when launching a target
fails and the breakpoint is never hit.
This patch changes the way the StackFrame Recognizers match a certain
frame.
Until now, recognizers could be registered with a function
name but also an alternate symbol.
This change is motivated by a test failure for the Assert frame
recognizer on Linux. Depending the version of the libc, the abort
function (triggered by an assertion), could have more than two
signatures (i.e. `raise`, `__GI_raise` and `gsignal`).
Instead of only checking the default symbol name and the alternate one,
lldb will iterate over a list of symbols to match against.
rdar://60386577
Differential Revision: https://reviews.llvm.org/D76188
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
This allows an unsanitized test process which loads a sanitized DSO (the
motivating example is a Swift runtime dylib) to launch on Darwin.
rdar://57290132
Differential Revision: https://reviews.llvm.org/D71379
Summary:
To run the testsuite remotely the executable needs to be uploaded to
the target system. The Target takes care of this by default.
When the test uses additional shared libraries, those won't be handled
by default and need to be registered with the target using
test.registerSharedLibrariesWithTarget(target, dylib).
Calling this API requires a target, so it doesn't mesh well with the
run_to_* helpers that we've been advertising as the right way to write
tests.
This patch adds an extra_images argument to all the helpers and does
the registration automatically when running a remote
testsuite. TestWeakSymbols.py was converted to use this new scheme.
Reviewers: jingham
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D70134
This test was timing out on the swift CI bots. I didn't see any obvious reason
for that, and the test hasn't had problems on greendragon. OTOH, it was a bit
oddly written, and needed modernizing, so I did that.
Differential Revision: https://reviews.llvm.org/D69453
Summary:
Dump more information about "access violation" and "in page error" exceptions to
description. Description now contains data about read/write violation type and
actual address as described at
https://docs.microsoft.com/en-us/windows/desktop/api/winnt/ns-winnt-_exception_record
Reviewers: asmith, stella.stamenova
Reviewed By: stella.stamenova
Subscribers: teemperor, amccarth, abidh, lldb-commits, aleksandr.urakov
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D60519
llvm-svn: 359420
Summary:
This patch contains several small fixes, which makes it possible to evaluate
expressions on Windows using information from PDB. The changes are:
- several sanitize checks;
- make IRExecutionUnit::MemoryManager::getSymbolAddress to not return a magic
value on a failure, because callers wait 0 in this case;
- entry point required to be a file address, not RVA, in the ObjectFilePECOFF;
- do not crash on a debuggee second chance exception - it may be an expression
evaluation crash. Also fix detection of "crushed" threads in tests;
- create parameter declarations for functions in AST to make it possible to call
debugee functions from expressions;
- relax name searching rules for variables, functions, namespaces and types. Now
it works just like in the DWARF plugin;
- fix endless recursion in SymbolFilePDB::ParseCompileUnitFunctionForPDBFunc.
Reviewers: zturner, asmith, stella.stamenova
Reviewed By: stella.stamenova, asmith
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D53759
llvm-svn: 348136
This change allows you to write a new breakpoint type where the
logic for setting breakpoints is determined by a Python callback
written using the SB API's.
Differential Revision: https://reviews.llvm.org/D51830
llvm-svn: 342185
This patch extends the SBAPI to allow for setting a breakpoint not
only at a specific line, but also at a specific (minimum) column. When
a column is specified, it will try to find an exact match or the
closest match on the same line that comes after the specified
location.
Differential Revision: https://reviews.llvm.org/D51461
llvm-svn: 341078
Summary:
The test suite has often unnecessary trailing whitespace, and sometimes
unnecessary trailing lines or a missing final new line. This patch just strips
trailing whitespace/lines and adds missing newlines at the end.
Subscribers: ki.stfu, JDevlieghere, christof, lldb-commits
Differential Revision: https://reviews.llvm.org/D49943
llvm-svn: 338171
Many IDEs set breakpoints using absolute paths and this causes problems when the full path of the source file path doesn't match what is in the debug info. This can be due to different build systems and do or do not resolve symlinks. This patch allows relative breakpoint to be set correctly without needing to do any target.source-map tricks. If IDEs want to, they can send down relative paths like:
./main.c
./src/main.c
src/main.c
foo/bar/src/main.c
I used the breakpoint resolver to match on the file basename and then we weed out anything whose relative paths don't match. This will be a huge improvement for IDEs as they can specify as much of a relative path as desired to uniquely identify a source file in the current project.
Differential Revision: https://reviews.llvm.org/D45592
llvm-svn: 330028
Summary:
The changes here fall into several categories.
- some tests were redirecting inferior stdout/err to a file. For these I
make sure we use an absolute path for the file. I also create a
lldbutil.read_file_on_target helper function to encapsulate the
differences between reading a file locally and remotely.
- some tests were redirecting the pexpect I/O into a file. For these I
use a python StringIO object to avoid creating a file altogether.
- the TestSettings inferior was creating a file. Here, I make sure the
inferior is launched with pwd=build-dir so that the files end up
created there.
- lldb-mi --log (used by some tests) creates a log file in PWD without
the ability say differently. To make this work I make sure to run
lldb-mi with PWD=build_dir. This in turn necessitated a couple of
changes in other lldb-mi tests, which were using relative paths to
access the source tree.
Reviewers: aprantl
Subscribers: ki.stfu, mehdi_amini, lldb-commits
Differential Revision: https://reviews.llvm.org/D44159
llvm-svn: 327625
Summary:
This test was failing on Windows because it expected the breakpoint in the
dynamic library to be resolved before the process is launched. Since the DLL
isn't loaded until the process is launched this didn't work.
The fix creates a special value (-2) for num_expected_locations that ignores
the actual number of breakpoint locations found.
Reviewers: jasonmolenda
Subscribers: sanjoy, lldb-commits
Differential Revision: https://reviews.llvm.org/D43419
llvm-svn: 325704
Summary:
These were not being flaky, but they're still making the tree dirty.
These tests were using lldbutil.append_to_process_working_directory to
derive the file path so I fix them by modifying the function to return
the build directory for local tests.
Technically, now the path returned by this function does not point to
the process working directory for local tests, but I think it makes
sense to keep the function name, as I think we should move towards
launching the process in the build directory (and I intend to change
this for the handful of inferiors that actually care about their PWD,
for example because they need to create files there).
Reviewers: davide, aprantl
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D43506
llvm-svn: 325690
Using the "run_to_{source,name}_breakpoint will allow us to remove
a lot of boiler-plate from the testsuite. We mostly use source
breakpoints, but some tests use by name ones so this was needed.
llvm-svn: 324010
This patch is the result of a discussion on lldb-dev, see
http://lists.llvm.org/pipermail/lldb-dev/2018-January/013111.html for
background.
For each test (should be eventually: each test configuration) a
separate build directory is created and we execute
make VPATH=$srcdir/path/to/test -C $builddir/path/to/test -f $srcdir/path/to/test/Makefile -I $srcdir/path/to/test
In order to make this work all LLDB tests need to be updated to find
the executable in the test build directory, since CWD still points at
the test's source directory, which is a requirement for unittest2.
Although we have done extensive testing, I'm expecting that this first
attempt will break a few bots. Please DO NOT HESITATE TO REVERT this
patch in order to get the bots green again. We will likely have to
iterate on this some more.
Differential Revision: https://reviews.llvm.org/D42281
llvm-svn: 323803
to make a target, set a source regex breakpoint, run to
the breakpoint and find the thread that hit the breakpoint.
Start the process of replacing the boiler plate with this
routine.
llvm-svn: 307234
*** 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
The android dirty stderr problem has uncovered an issue where lldbutil.expect_state_changes was
reading events other than state change events, which resulted in general confusion. Make it more
strict to accept *only* state changes.
llvm-svn: 266327
Previously we had 3 different method to run shell commands on the
target and 4 copy of code waiting until a given file appears on the
target device (used for syncronization). This CL merges these methods
to 1 run_platform_command and 1 wait_for_file_on_target functions
located in some utility classes.
Differential revision: http://reviews.llvm.org/D18789
llvm-svn: 265398
SBProcess::ReadMemory and other related functions such as
WriteMemory are returning Python string() objects. This means
that in Python 3 that are returning Unicode objects. In reality
they should be returning bytes objects which is the same as a string
in Python 2, but different in Python 3. This patch updates the
generated SWIG code to return Python bytes objects for all
memory related functions.
One quirk of this patch is that the C++ signature of ReadCStringFromMemory
has it writing c-string data into a void*. This confuses our swig
typemaps which expect that a void* means byte data. So I hacked up
a custom typemap which maps this specific function to treat the
void* as string data instead of byte data.
llvm-svn: 258743
The Windows 10 loader spawns threads at startup, so
tests which count threads or assume that a given user
thread will be at a specific index are incorrect in
this case. The fix here is to use the standard mechanisms
for getting the stopped thread (which is all we are
really interested in anyway) and correlating them with
the breakpoints that were set, and doing checks against
those things.
This fixes about 6 tests on Windows 10.
llvm-svn: 258586
Starting with Windows 10, the Windows loader is itself multi-threaded,
meaning that the loader spins up a few threads to do process
initialization before it executes main. Windows delivers these
notifications asynchronously and they can come out of order, so
we can't be sure that the first thread we get a notification about
is actually the zero'th thread.
This patch fixes this by requesting the thread stopped at the
breakpoint that was specified, rather than getting thread 0 and
verifying that it is stopped at a breakpoint.
Differential Revision: http://reviews.llvm.org/D16247
llvm-svn: 258432
The logic for skipping over the stop-and-restart events was incorrect as it was also skipping the
expectations. Implement it properly. No test is affected by this as they were not encountering
these events, but I encountered this issue when trying to use this function in a new test.
llvm-svn: 256928
Absolute imports were introduced in Python 2.5 as a feature
(e.g. from __future__ import absolute_import), and made default
in Python 3.
When absolute imports are enabled, the import system changes in
a couple of ways:
1) The `import foo` syntax will *only* search sys.path. If `foo`
isn't in sys.path, it won't be found. Period. Without absolute
imports, the import system will also search the same directory
that the importing file resides in, so that you can easily
import from the same folder.
2) From inside a package, you can use a dot syntax to refer to higher
levels of the current package. For example, if you are in the
package lldbsuite.test.utility, then ..foo refers to
lldbsuite.test.foo. You can use this notation with the
`from X import Y` syntax to write intra-package references. For
example, using the previous locationa s a starting point, writing
`from ..support import seven` would import lldbsuite.support.seven
Since this is now the default behavior in Python 3, this means that
importing from the same directory with `import foo` *no longer works*.
As a result, the only way to have portable code is to force absolute
imports for all versions of Python.
See PEP 0328 [https://www.python.org/dev/peps/pep-0328/] for more
information about absolute and relative imports.
Differential Revision: http://reviews.llvm.org/D14342
Reviewed By: Todd Fiala
llvm-svn: 252191
This module was originally intended to be imported by top-level
scripts to be able to find the LLDB packages and third party
libraries. Packages themselves shouldn't need to import it,
because by the time it gets into the package, the top-level
script should have already done this. Indeed, it was just
adding the same values to sys.path multiple times, so this
patch is essentially no functional change.
To make sure it doesn't get re-introduced, we also delete the
`use_lldb_suite` module from `lldbsuite/test`, although the
original copy still remains in `lldb/test`
llvm-svn: 251963
This is the conclusion of an effort to get LLDB's Python code
structured into a bona-fide Python package. This has a number
of benefits, but most notably the ability to more easily share
Python code between different but related pieces of LLDB's Python
infrastructure (for example, `scripts` can now share code with
`test`).
llvm-svn: 251532
SYNOPSYS\georgiev