Summary:
The comment in the Editine.h header made it sound like editline was
just unable to handle terminal resizing. We were not ever telling
editline that the terminal had changed size, which might explain why
it wasn't working.
This patch threads a `TerminalSizeChanged()` callback through the
IOHandler and invokes it from the SIGWINCH handler in the driver. Our
`Editline` class already had a `TerminalSizeChanged()` method which
was invoked only when editline was configured.
This patch also changes `Editline` to not apply the changes right away
in `TerminalSizeChanged()`, but instead defer that to the next
character read. During my testing, it happened once that the signal
was received while our `ConnectionFileDescriptor::Read` was allocating
memory. As `el_resize` seems to allocate memory too, this crashed.
Reviewers: labath, teemperor
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D79654
While debugging why TestProcessList.py failed during passive replay, I
remembered that we don't serialize the arguments for ProcessInfo. This
is necessary to make the test pass and to make platform process list -v
behave the same during capture and replay.
Differential revision: https://reviews.llvm.org/D79646
If the error message from qLaunchSucess included a gdb RSP
metacharacter, it could crash lldb. Apply the binary
escaping to the string before sending it to lldb; lldb
promiscuously applies the binary escaping protocol on
packets it receives.
Also fix a small bug in cstring_to_asciihex_string where
a high bit character (eg utf-8 chars) would not be
quoted correctly due to signed char fun.
Differential Revision: https://reviews.llvm.org/D79614
rdar://problem/62873581
Summary:
TestNSDictionarySynthetic sets up an NSURL which does not initialize its
_baseURL member. When the test runs and we print out the NSURL, we print
out some garbage memory pointed-to by the _baseURL member, like:
```
_baseURL = 0x0800010020004029 @"d��qX"
```
and this can cause a python unicode decoding error like:
```
UnicodeDecodeError: 'utf8' codec can't decode byte 0xa0 in position
10309: invalid start byte
```
There's a discrepancy here because lldb's StringPrinter facility tries
to only print out "printable" sequences (see: isprint32()), whereas python
rejects the StringPrinter output as invalid utf8. For the specific error
seen above, lldb's `isprint32(0xa0) = true`, even though 0xa0 is not
really "printable" in the usual sense.
The problem is that lldb and python disagree on what exactly is
"printable". Both have dismayingly hand-rolled utf8 validation code
(c.f. _Py_DecodeUTF8Ex), and I can't really tell which one is more
correct.
I tried replacing lldb's isprint32() with a call to libc's iswprint():
this satisfied python, but broke emoji printing :|.
Now, I believe that lldb (and python too) ought to just call into some
battle-tested utf library, and that we shouldn't aim for compatibility
with python's strict unicode decoding mode until then.
FWIW I ran this test under an ASanified lldb hundreds of times but
didn't turn up any other issues.
rdar://62941711
Reviewers: JDevlieghere, jingham, shafik
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D79645
Summary:
The test machinery translates each continuous block of "//%" comments
into a single breakpoint. If there's no code between the blocks the
breakpoints will end up at the same location in the program. When the
process stops at a breakpoint lldb correctly reports all breakpoint IDs,
but the test machinery only looks at the first one. This results in a
very dangerous situation as it means some checks can be silently
stopped.
This patch fixes that by making the test machinery iterate through all
breakpoints at a given location and execute all commands.
Reviewers: vsk, JDevlieghere
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D79563
Summary:
This function rewrites the test to be (hopefully) less susceptible to
codegen changes and re-enables it.
The most interesting changes are:
- use an __attribute__((optnone)) function instead of a volatile asm to
"use" a value. This isn't strictly necessary, but it makes the
function simpler while achieving the same effect.
- use a call to a function with the exact same signature instead of a
volatile asm to "destroy" arguments. This makes the independent of the
ABI, and (together with avoiding the usage of the arguments after the
call) ensures that the compiler has no reason to move the argument
from its initial register (previously we needed to guess where will
the compiler store the arguments).
Reviewers: vsk, djtodoro, dblaikie
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D79491
Summary:
We got a few crash reports where LLDB crashes while derefencing the `frames_value` shared_ptr in the AppleObjCRuntime::GetBacktraceThreadFromException. `GetChildMemberWithName` returns a nullptr when an error occurs, so this seems to be just a missing nullptr check.
This patch adds that nullptr check and the other ones in the similar code directly below.
Fixes rdar://62174039
Reviewers: jingham, kubamracek
Reviewed By: jingham
Subscribers: abidh, JDevlieghere
Differential Revision: https://reviews.llvm.org/D78798
Summary: Apply the common completion created in [[ https://reviews.llvm.org/D75418 | Revision D75418 ]] to the commands `breakpoint write` and `breakpoint name add/delete`.
Reviewers: teemperor, JDevlieghere
Reviewed By: teemperor
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D79686
Summary:
1. A new common completion `CommandCompletions::Breakpoints` to provide a list of the breakpoints of the current context;
2. Apply the completion above to the commands breakpoint enable/disable/delete/modify;
3. Unit test.
Reviewers: teemperor, JDevlieghere
Reviewed By: teemperor
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D79666
Following test cases need minor adjustment in order to accomodate xfail
decorator:
lldb/test/Shell/SymbolFile/NativePDB/break-by-line.cpp
lldb/test/Shell/SymbolFile/NativePDB/source-list.cpp
MachProcess.mm uses a TARGET_OS_ macro without directly including
TargetConditionals.h. This currently works as we get the header
as an indirect dependency, but might not in the future.
I just spent some time investigating an internal regression
caused by a similar issue, so I audited the codebase for such
cases.
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:
`CalculateSyntheticValue` and `GetSyntheticValue` have a `use_synthetic` parameter
that makes the function do nothing when it's false. We obviously always pass true
to the function (or check that the value we pass is true), because there really isn't
any point calling with function with a `false`. This just removes all of this.
Reviewers: labath, JDevlieghere, davide
Reviewed By: davide
Subscribers: davide
Differential Revision: https://reviews.llvm.org/D79568
This was reverted due to a python2-specific bug. Re-landing with a fix
for python2.
Summary:
One small step in my long running quest to improve python exception handling in
LLDB. Replace GetInteger() which just returns an int with As<long long> and
friends, which return Expected types that can track python exceptions
Reviewers: labath, jasonmolenda, JDevlieghere, vadimcn, omjavaid
Reviewed By: labath, omjavaid
Subscribers: omjavaid, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D78462
Also, this moves numSDKs out of the actual enum, as to not mess with
the switch-cases-covered warning.
Differential Revision: https://reviews.llvm.org/D79603
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
Summary:
The arpa/inet.h header in macOS is providing an incorrect htonl
function with enabled local submodule visibility while building LLDB. This
caused several networking tests to fail as the IP addresses are now flipped
in LLDB.
This patch disables building with modules when local submodule visibility is
active and the current system is macOS for the source/Host directory (which
is the *only directory that includes arpa/inet.h).
* debugserver also includes arpa/inet.h but there we already disabled
modules.
Reviewers: aprantl
Reviewed By: aprantl
Subscribers: mgorny, JDevlieghere
Differential Revision: https://reviews.llvm.org/D79632
The relevant output FileCheck is scanning in this test is as follows:
CXXRecordDecl 0x7f96cf8239c8 <<invalid sloc>> <invalid sloc> imported in A.B <undeserialized declarations> struct definition
<<DefinitionData boilerplate>>
`-FieldDecl 0x7f96cf823b90 <<invalid sloc>> <invalid sloc> imported in A.B anon_field_b 'int'
(anonymous struct)
CXXRecordDecl 0x7f96cf823be8 <<invalid sloc>> <invalid sloc> imported in A.B struct
Before 710fa2c4ee this test was passing by
accident as it had a -DAG suffix in the checks changed by this patch,
causing FileCheck to first match the last line of the output above
(instead of the first one), and then finding the FieldDecl above.
When I removed the -DAG suffix, FileCheck actually enforced the ordering
and started failing as the FieldDecl comes before the CXXRecordDecl match
we get.
This patch fixes the CXXRecordDecl check to find the first line of the output
above which caused FileCheck to also find the FieldDecl that follows. Also
gives the FieldDecl a more unique name to make name collisions less likely.
This test was generating the following false-positive warning when being compiled:
warning: class 'SomeClass' defined without specifying a base class [-Wobjc-root-class]
The current test is checking both the anonymous structs and the template
specializations in one FileCheck run, but the anonymous struct line can
partially match the AST dump of a template specialization, causing that
FileCheck won't match that same line later against the template specialization
check and incorrectly fails on that check. This only happens when the
template specialization node somehow ends up before the anonymous struct node.
This patch just puts the checks for the anonymous structs in their own FileCheck
run to prevent them from partially matching any other record decl.
Fixes rdar://62997926
Similar to
com.apple.debugserver.plist & com.apple.debugserver.internal.plist
com.apple.debugserver.applist.plist & com.apple.debugserver.applist.internal.plist
add a variant of the posix plist.
<rdar://problem/62995567>
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.
All entry points into ProcessGDBRemote that connect to the debug server
should connect to the replay server instead during reproducer replay.
This patch adds the necessary logic for ConnectRemote, which is
accessible from the SB API. This fixes active replay for
TestRecognizeBreakpoint.py as described in D78588.
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
We currently rely on the TypeSystem implementation to initialize this value
with 0 in the GetChildCompilerTypeAtIndex call below. Let's just initialize
this variable like the rest.
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>
For Swift LLDB (but potentially also for module support in Clang-land)
we need a way to accumulate the path remappings produced by
Module::RegisterXcodeSDK(). In order to make this work for
SymbolFileDebugMaps, registering the search path remapping with both
modules is necessary.
Differential Revision: https://reviews.llvm.org/D79384
<rdar://problem/62750529>
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
When debugging a remote platform, the platform you get from
GetPlatformForArchitecture doesn't inherit from PlatformDarwin.
HostInfoMacOSX seems like the right place to have a global store of
local paths.
Differential Revision: https://reviews.llvm.org/D79364
When debugging from a SymbolMap the creation of CompileUnits for the
individual object files is so lazy that RegisterXcodeSDK() is not
invoked at all before the Swift TypeSystem wants to read it. This
patch fixes this by introducing an explicit
SymbolFile::ParseXcodeSDK() call that can be invoked deterministically
before the result is required.
<rdar://problem/62532151+62326862>
https://reviews.llvm.org/D79273
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
After 61d5b0e663 more shell test are expected to exit with a non-zero
status code. Because the exit status is computed in the driver and not
behind the SB API layer, reproducers don't know about it and always
return 0 unless replay failed.
This discrepancy means that these tests don't work with lldb-repro.py
and skipping them for this reason would be a pity. To solve this
problem, the script now serializes the exit code during capture and
returns that during replay.
These is an assert that ensures that replay exits with a zero exit
status to prevent replay failures from being silently ignored.
Update CallBoardSystemServiceOpenApplication to unconditionally log
the NSError's localizedDescription to Console on app launch failure
(as it was already doing), and also to log the NSError object's
full description to the console, which may contain additional nested
error messages. I'm experimenting to find cases where we will get
more detailed information from app launch failures and will start
by logging both to the console.
<rdar://problem/62709160>
Jonas Devlieghere