D55859 and D63339 prevented needless dependencies on system symbol
files. This testcase was checked-in afterwards and it brings back one
such unwanted dependency. Under some circumstances it may cause false
FAILs and/or excessive resource usage to run the testcase.
clang-format does not support .py so I have formatted it as I found most
compatible.
Also this is not a full testcase-style initialization, for example
--no-lldbinit ignores env("NO_LLDBINIT") setting which lldbtest.py does
implement:
# If we spawn an lldb process for test (via pexpect), do not load the
# init file unless told otherwise.
if os.environ.get("NO_LLDBINIT") != "NO":
self.lldbOption += " --no-lldbinit"
But this is what lldbpexpect.py does - it also ignores
env("NO_LLDBINIT"). Sure one could also fix lldbpexpect.py to unify the
initialization more with lldbtest.py but I find that outside of the
scope of this patch.
Differential Revision: https://reviews.llvm.org/D79649
Because LLDB isn't the one spawning the subprocess, the PID is different
during replay. Exclude it form the substring check during replay.
Depends on D79646 to pass with reproducer replay.
Summary:
On macOS, we can't do the DYLD_INSERT_LIBRARIES trick with a shim
python binary as the ASan interceptors get loaded too late. Find the
"real" python binary, copy it, and invoke it.
Hopefully this makes the GreenDragon and swift-ci sanitizer bots
happy...
I tested this out by running `../llvm-macosx-x86_64/bin/llvm-lit test
--filter TestNSDictionarySynthetic.py` in an ASanified swift-lldb build
directory and it worked (i.e. no more "interceptors loaded too late"
messages).
Reviewers: JDevlieghere
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D79607
This skips some tests that pass with active replay (which doesn't check
the output) but fail with passive replay. Valid reasons for this
include:
- Checking the output of the process (which doesn't run during replay),
- Checking files that cannot be captured in the VFS (non-existing or
unreadable files or files that are removed during test),
Unfortunately there's no good way to mark a test as supported for active
replay but unsupported for passive replay because the number and order
of API calls needs to be identical during capture and replay. I don't
think this is a huge loss however.
Summary:
1. Created a new common completion for the registers of the current context;
2. Apply this new common completion to the commands register read/write;
3. Unit test.
Reviewers: teemperor, JDevlieghere
Reviewed By: teemperor
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D79490
The source file used to test Objective-C data-formatters didn't respected
any formatting (mixed tab and spaces, lines exceed column 80, etc...).
This patch reformats the file using clang-format to make it easier to
work with.
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
The Python used to run lit can be different from the Python LLDB was
build with. One scenario where this happens is when LLVM can find the
Python 3 interpreter, but not the Python 3 libraries, in which case LLDB
build and links against Python 3. Without this change, you end up with
an ModuleNotFoundError because of the mismatch.
Instead of looking at the Python interpreter that's used to run lit,
lldbtest should use the interpreter that matches the Python version LLDB
was build against.
Differential revision: https://reviews.llvm.org/D79519
Summary:
Sometimes users think that setting a function regex for all function that contain the word 'needle' in their
name looks like this: `*needle*`. However, LLDB only searches the function name and doesn't fully match
it against the regex, so the leading and trailing '*' operators don't do anything and actually just cause the
regex engine to reject the regular expression with "repetition-operator operand invalid".
This patch makes this a bit more obvious to the user by printing a warning that a leading '*' before this
regular expression here doesn't have any purpose (and will cause an error). This doesn't attempt to detect
a case where there is only a trailing '*' as that would involve parsing the regex and it seems the most
common way to end up in this situation is by doing `rbreak *needle*`.
Reviewers: JDevlieghere
Reviewed By: JDevlieghere
Differential Revision: https://reviews.llvm.org/D78809
Summary:
This fixes a bug where
frame var a[0]+5
returns the value a[0] without any warning because the current logic simply ignores everything after ']' as long as there is no '.', '-' or '[' in the rest of the string.
The fix simplifies the termination condition of the expression path parsing loop to check if have a non-empty remaining string to parse. Previously, the condition checked if a separator was found. That condition coincided with the remaining string-to-parse condition except for the buggy indexed case where non-empty string was left ("+5" in the example above), but the separator index was 'npos'.
Reviewed By: teemperor, labath
Differential Revision: https://reviews.llvm.org/D79404
The overloaded new operator in TestCppOperators.py are working by accident because of how
we currently deal with artificial methods.
Differential Revision: https://reviews.llvm.org/D79251
This patch fixes the test failure happening on Windows introduced by
`015117411e11458f9816ba4359246132164a4297`.
Since the failure message comes from the OS, the test needs to support both
UNIX and Windows messages.
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
When trying to read a core file that is not owned by the user running lldb
and that doesn't have read permission on the file, lldb shows a misleading
error message:
```
Unable to find process plug-in for core file
```
This is due to the fact that currently, lldb doesn't check the file
ownership. And when trying to to open and read a core file, the syscall
fails, which prevents a process to be created.
Since lldb already have a portable `open` syscall interface, lets take
advantage of that and delegate the error handling to the syscall
itself. This way, no matter if the file exists or if the user has proper
ownership, lldb will always try to open the file, and behave accordingly
to the error code returned.
rdar://42630030
https://reviews.llvm.org/D78712
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
Summary:
This patch adds support to access AArch64 FP SIMD core dump registers and adds a test case to verify registers.
This patches fixes a bug where doing "register read --all" causes lldb to crash.
Reviewers: labath
Reviewed By: labath
Subscribers: kristof.beyls, danielkiss, lldb-commits
Differential Revision: https://reviews.llvm.org/D77793
Summary:
Currently loading core files on lldb-vscode is broken because there's a check in the attach workflow that asserts that the PID is valid, which of course fails for this case.
Hence, I'm adding a "coreFile" argument for the attach request, which does the work correctly.
I don't know how to test it effectively so that it runs on the buildbots and the debugger can in fact makes sense of it. Anyway, the change has been relatively simple.
Reviewers: labath, clayborg
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D78839
This patch improves data formatting for CoreFoundation containers:
CFDictionary and CFSet.
These data formatters make the containers and their children appear in Xcode's
variables view (and on the command line) without having to expand the
data structure.
Previous implementation only supported showing the container's element count.
```
(lldb) frame var dict
(__NSCFDictionary *) dict = 0x00000001004062b0 2 key/value pairs
(lldb) frame var set
(__NSCFSet *) set = 0x0000000100406330 2 elements
```
Now the variable can be dereferenced to dispaly the container's children:
```
(lldb) frame var *dict
(__NSCFDictionary) *dict = {
[0] = {
key = 0x0000000100004050 @"123"
value = 0x0000000100004090 @"456"
}
[1] = {
key = 0x0000000100004030 @"abc"
value = 0x0000000100004070 @"def"
}
}
(lldb) frame var *set
(__NSCFSet) *set = {
[0] = 0x0000000100004050 @"123"
[1] = 0x0000000100004030 @"abc"
}
```
rdar://39882287
Differential Revision: https://reviews.llvm.org/D78396
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
Summary:
For some reason the TestExec test on the macOS bots randomly fails with this error:
```
output: * thread #2, stop reason = EXC_BAD_ACCESS (code=1, address=0x108e66000)
* frame #0: 0x0000000108e66000
[...]
File "/Users/buildslave/jenkins/workspace/lldb-cmake/llvm-project/lldb/test/API/functionalities/exec/TestExec.py", line 25, in test_hitting_exec
self.do_test(False)
File "/Users/buildslave/jenkins/workspace/lldb-cmake/llvm-project/lldb/test/API/functionalities/exec/TestExec.py", line 113, in do_test
"Stopped at breakpoint in exec'ed process.")
AssertionError: False is not True : Stopped at breakpoint in exec'ed process.
Config=x86_64-/Users/buildslave/jenkins/workspace/lldb-cmake/lldb-build/bin/clang-11
```
I don't know why the test program is failing and I couldn't reproduce this problem on my own.
This patch is a stab in the dark that just tries to make the test code more similar to code which
we would expect in a user program to make whatever part of macOS happy that is currently
not liking our code.
The actual changes are:
* We pass in argv[0] that is describing otherprog path instead of the current argv[0].
* We pass in a non-null envp (which anyway doesn't seem to be allowed on macOS man page).
Reviewers: labath, JDevlieghere
Reviewed By: labath
Subscribers: abidh, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D75241
Summary:
Sometimes a result variable of some expression can be presented as an elaborated
type. In this case the methods `IsTypedefType()` and `GetTypedefedType()` of
`SBType` didn't work. This patch fixes that.
I didn't find the test for these API methods, so I added a basic test for this
too.
Reviewers: aprantl, teemperor, labath, leonid.mashinskiy
Reviewed By: teemperor
Subscribers: labath, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D78697
Summary:
Currently the breakpoint command is prompting the user to file a bug report if the provided regex is invalid:
```
(lldb) rbreak *foo
error: Function name regular expression could not be compiled: "Inconvertible error value. An error has occurred that could not be converted to a known std::error_code. Please file a bug. repetition-operator operand invalid"
```
The reason is simply that we are using the wrong StringError constructor (the one with the error code as the first parameter
is also printing the string version of the error code, and the inconvertible error code is just an invalid place holder code with
that description). Switching the StringError constructor parameters will only print the error message we get from the regex
engine when we convert the error into a string.
I checked the rest of the code base and I couldn't find the same issue anywhere else.
Fixes rdar://62233561
Reviewers: JDevlieghere
Reviewed By: JDevlieghere
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D78808
In ImportContext(…) we may call into CompleteDecl(…) which if FromRecrord is not
defined will start the definition of a ToRecord but from what I can tell at least
one of the paths though here don't ensure we complete the definition.
For a RecordDecl this can be problematic since this means we won’t import base
classes and we won’t have any of the methods or types we inherit from these bases.
Differential Revision: https://reviews.llvm.org/D78000
Add the skipIfReproducer decorator to the remaining tests that fail to
replay because the GDB remote packets diverge during replay. This is
*not* expected and should be fixed, but figuring out exactly what caused
the divergence has proven pretty difficult to track down.
I've marked these tests as skipped for now so we can get clean results
and detect new regressions. I have no evidence to believe that these
failures have the same root cause, so I've not assigned them a PR.
Some tests are not expected to work with reproducers, for example tests
that completely circumvent the reproducers (i.e. using the side_effects
Python module) or that rely on changes to the file system.
Lit's to_string will just return the string when it's a `str` instance,
which in Python 2 can still contain UTF-8 characters.
Differential revision: https://reviews.llvm.org/D76955
Summary:
...and replace it with m_last_file_spec instead.
When Source Cache is enabled, the value stored in m_last_file_sp is
already in the Source Cache, and caching it again in SourceManager
brings no extra benefit. All we need is to "remember" the last used
file, and FileSpec can serve the same purpose.
When Source Cache is disabled, the user explicitly requested no caching
of source files, and therefore, m_last_file_sp should NOT be used.
Bug: llvm.org/PR45310
Depends on D76805.
Reviewers: labath, jingham
Reviewed By: jingham
Subscribers: labath, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D76806
Summary:
In D49685 sysroot behaviour was partially fixed. But files from local filesystem with same path still has priority over files from sysroot.
This patch fixes it by removing fallback to local filesystem from RemoteAwarePlatform::GetModuleSpec(). It is not actually required because higher level code do such fallback itself. See, for example, resolver in Platform::GetSharedModule().
Reviewers: labath, clayborg, EugeneBi
Reviewed By: labath
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D77529
This is a regression since:
[lldb][NFC] Modernize lang/cpp/scope test
acb0b99c8e4f1dc65a7f1e26da9db77239a67da7
rGacb0b99c8e4f
File "/home/jkratoch/redhat/llvm-monorepo/lldb/test/API/lang/cpp/scope/TestCppScope.py", line 19, in test
self.assertEqual(global_var_names, expected_var_names)
AssertionError: Lists differ: ['C::a', 'A::a', 'B::a', '::a'... != ['A::a', 'B::a', 'C::a', '::a'...
First differing element 0:
C::a
A::a
- ['C::a', 'A::a', 'B::a', '::a']
+ ['A::a', 'B::a', 'C::a', '::a']
ManualDWARFIndex using NameToDIE does not sort alphabetically:
// This is only for uniqueness, not lexicographical ordering, so we can
// just compare pointers.
return uintptr_t(lhs.GetCString()) < uintptr_t(rhs.GetCString());
Since D77214 there is a testsuite regression for TestFixIts.py
on Fedora 31 x86_64.
File "/home/jkratoch/redhat/llvm-monorepo/lldb/test/API/commands/expression/fixits/TestFixIts.py", line 148, in test_with_target
self.assertEquals(value.GetError().GetCString(), "error: No value")
AssertionError: 'error: error: Multiple internal symbols found for \'d\'\nid = {0x00000d2a}, ran [truncated]... != 'error: No value'
That is because Fedora glibc incl. libm.so contains also ELF debug
symbols and there exists a 'd' symbol:
(gdb) p d
$1 = {i = {0, 1076887552}, d = 16}
(gdb) p &d
$2 = (const number *) 0x7ffff78e8bc0 <d>
(gdb) info sym 0x7ffff78e8bc0
d in section .rodata of /lib64/libm.so.6
$ nm /lib64/libm.so.6 |grep ' d$'
00000000000bfbc0 r d
00000000000caa20 r d
00000000000caa20 r d
00000000000caa20 r d
glibc-build$ for i in `find -name "*.o"`;do nm 2>/dev/null $i|grep ' d$' && echo $i;done
0000000000000080 r d
./math/s_atan-fma4.o
0000000000000080 r d
./math/s_atan-avx.o
0000000000000080 r d
./math/s_atan.o
[intel-pt] Improve the way the test determines whether to run
- Now I'm creating a default value for the new test parameter
- I fixed a small mistake in the skipping logic of the test
... I forgot to clear the cmake cache when testing my diff
Summary:
@labath raised a concern on the way I was skipping this test. I think that was
fair and I found a better way.
Now I'm skipping if the CMAKE flag LLDB_BUILD_INTEL_PT is false.
I added an enabled_plugins entry in the dotest configuration, which gets
set by lit or lldb-dotest. The only available plugin right now is
'intel-pt', but I imagine it will be useful in the future for other
kinds of plugins that get determined at configuration time. I didn't
want to add a new argument option --enable-intel-pt or something or the
sort, as it wouldn't be useful for other cases.
Reviewers: labath, clayborg
Subscribers: lldb-commits, labath
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D77452
Make it possible to capture reproducers from the API test suite. Given
the symmetry between capture and replay, this patch also adds the
necessary code for replay. For now this is a NO-OP until the
corresponding reproducer instrumentation changes land.
For more info please refer to the RFC on lldb-dev:
http://lists.llvm.org/pipermail/lldb-dev/2020-April/016100.html
Differential revision: https://reviews.llvm.org/D77588
Summary:
[lldb/test] Fix TestLoadUnload failure introduced in e0dbd025131c4d77d8a5050a91d391d950529a8c
It seems that `env_cmd_string` is declared and used few lines under this
self.runCmd expression. I guess this is some left-over from an older
version.
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
Reviewers: labath
Reviewed By: labath
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D78094
test_step_over_load_with_svr4 and test_step_over_load now pass on
aarch64 linux.
Fixed by change-id: e0dbd025131c4d77d8a5050a91d391d950529a8c
Differential Revision: https://reviews.llvm.org/D77662
Summary:
This patch introduces a header "dylib.h" which can be used in tests to
handle shared libraries semi-portably. The shared library APIs on
windows and posix systems look very different, but their underlying
functionality is relatively similar, so the mapping is not difficult.
It also introduces two new macros to wrap the functinality necessary to
export/import function across the dll boundary on windows. Previously we
had the LLDB_TEST_API macro for this purpose, which automagically
changed meaning depending on whether we were building the shared library
or the executable. While convenient for simple cases, this approach was
not sufficient for the more complicated setups where one deals with
multiple shared libraries.
Lastly it rewrites TestLoadUnload, to make use of the new APIs. The
trickiest aspect there is the handling of DYLD_LIBRARY_PATH on macos --
previously setting this variable was not needed as the test used
@executable_path-relative dlopens, but the new generic api does not
support that. Other systems do not support such dlopens either so the
test already contained support for setting the appropriate path
variable, and this patch just makes that logic more generic. In doesn't
seem that the purpose of this test was to exercise @executable_path
imports, so this should not be a problem.
These changes are sufficient to make some of the TestLoadUnload tests
pass on windows. Two other tests will start to pass once D77287 lands.
Reviewers: amccarth, jingham, JDevlieghere, compnerd
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D77662
that pushes a step over plan. Relax the listing checker
so it will look past any entries after the ones listed in
the input patterns. Then for the internal plans just check
for the StepOver plan that our scripted plan pushes, and look past
any others.
This should make the test more robust on systems that don't use the
step-in then push a step-out plan to step over a function.
The final function call to `test_X` is failing on aarch64-linux with SIGILL.
Function calls to previous expressions seem to just not work on aarch64-linux
but I don't see another way to test the multiple-run Fix-Its.
This patch refactors the test that the skipIf for aarch64 Linux only covers
the part of the test that was added D77214.
I fixed the bug that the "log timer" has no tab command.
Original code has the only CommandObjectLogTimer class, but it is not
sufficient. Thus I divided the content of CommandObjectLog class into
CommandObjectLogEnable class, CommandObjectLogDisable class,
CommandObjectLogDump class, CommandObjectLogReset class,
CommandObjectLogIncrement class.
Reviewed by: teemperor
Differential Revision: https://reviews.llvm.org/D76906
Summary:
When using source maps for a breakpoint, in order to find the actual source that breakpoint has resolved, we
need to use a query similar to what CommandObjectSource::DumpLinesInSymbolContexts does, which is the logic
used by the CLI to display the source line at a given breakpoint. That's necessary because from a breakpoint
location you only have an address, which points to the original source location, not the source mapped one.
in the setBreakpoints request handler, we haven't been doing such query and we were returning the original
source location, which was breaking the UX of VSCode, as many breakpoints were being set but not displayed
in the source file next to each line. Besides, clicking the source path of a breakpoint in the breakpoints
view in the debug tab was not working for this case, as VSCode was trying to open a non-existent file, thus
showing an error to the user.
Ideally, we should do the query mentioned above to find the actual source location to respond to the IDE,
however, that query is expensive and users can have an arbitrary number of breakpoints set. As a simpler fix,
the request sent by VSCode already contains the full source path, which exists because the user set it from
the IDE itself, so we can simply reuse it instead of querying from the SB API.
I wrote a test for this, and found out that I had to move SetSourceMapFromArguments after RunInitCommands in
lldb-vscode.cpp, because an init command used in all tests is `settings clear -all`, which would clear the
source map unless specified after initCommands. And in any case, I think it makes sense to have initCommands
run before anything the debugger would do.
Reviewers: clayborg, kusmour, labath, aadsm
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D76968
