There appears to be consensus in D80165 that this is the desired
behavior and I personally agree.
Differential revision: https://reviews.llvm.org/D80226
Summary: Adding this in line with "stopCommands" and "exitCommands" so that we can run commands at the end of the debugging session.
Reviewers: clayborg, wallace, labath
Reviewed By: clayborg, labath
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D79726
Before the transition to libOption it was possible to specify arguments
for the inferior without -- as long as they didn't start with a dash.
For example, the following invocations should all behave the same:
$ lldb inferior inferior-arg
$ lldb inferior -- inferior-arg
$ lldb -- inferior inferior-arg
This patch fixes that behavior, documents it and adds a test to cover
the different combinations.
Differential revision: https://reviews.llvm.org/D80165
This reverts commit 525a591f0f48b9d54018bf5245f2abee09c9c1c8.
Fixed an issue with pointers to members based on typedefs. In this case,
LLVM would emit a second UDT. I fixed it by not passing the class type
to getTypeIndex when the base type is not a function type. lowerType
only uses the class type for direct function types. This suggests if we
have a PMF with a function typedef, there may be an issue, but that can
be solved separately.
> Before this patch, S_[L|G][THREAD32|DATA32] records were emitted with a simple name, not the fully qualified name (namespace + class scope).
>
> Differential Revision: https://reviews.llvm.org/D79447
This causes asserts in Chromium builds:
CodeViewDebug.cpp:2997: void llvm::CodeViewDebug::emitDebugInfoForUDTs(const std::vector<std::pair<std::string, const DIType *>> &):
Assertion `OriginalSize == UDTs.size()' failed.
I will follow up on the Phabricator issue.
This patch introduces the `(-h|--host)` option to the `platform shell`
command. It allows the user to run shell commands from the host platform
(always available) without putting lldb in the background.
Since the default behaviour of `platform shell` is to run the command of
the selected platform, having such a choice can be quite handy when
debugging remote targets, for instances.
This patch also introduces a `shell` alias, to improve the command
discoverability and make it more convenient to use for the user.
rdar://62856024
Differential Revision: https://reviews.llvm.org/D79659
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
This patch improves data formatting for CFDictionaryRef and CFSetRef.
It uses the same data-formatter as NSCFDictionaries and NSCFSets introduced
previously but did require some adjustments in Core::ValueObject.
Since the "Ref" types are opaque pointers to the actual CF containers, if the
value object has a synthetic value, lldb will use the opaque pointer's pointee
type to create the new ValueObjectChild needed to dereference the ValueObject.
This allows the "Ref" types to behaves the same as CF containers when used with
the `frame variable` command, the SBAPI or in Xcode's variable inspector.
This patch also adds support for incomplete types in ValueObject.
rdar://53104287
Differential Revision: https://reviews.llvm.org/D79554
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
Before this patch, S_[L|G][THREAD32|DATA32] records were emitted with a simple name, not the fully qualified name (namespace + class scope).
Differential Revision: https://reviews.llvm.org/D79447
This recommits f665e80c023 which was reverted in 1cbd1b8f692d for breaking
TestFoundationDisassembly.py. The fix is to use --force in the test to avoid
bailing out on large functions.
I have also doubled the large function limit to 8000 bytes (~~ 2000 insns), as
the foundation library contains a lot of large-ish functions. The intent of this
feature is to prevent accidental disassembling of enormous (multi-megabyte)
"functions", not to get in people's way.
The original commit message follows:
If we have a binary without symbol information (and without
LC_FUNCTION_STARTS, if on a mac), then we have to resort to using
heuristics to determine the function boundaries. However, these don't
always work, and so we can easily end up thinking we have functions
which are several megabytes in size. Attempting to (accidentally)
disassemble these can take a very long time spam the terminal with
thousands of lines of disassembly.
This patch works around that problem by adding a sanity check to the
disassemble command. If we are about to disassemble a function which is
larger than a certain threshold, we will refuse to disassemble such a
function unless the user explicitly specifies the number of instructions
to disassemble, uses start/stop addresses for disassembly, or passes the
(new) --force argument.
The threshold is currently fairly aggressive (4000 bytes ~~ 1000
instructions). If needed, we can increase it, or even make it
configurable.
Differential Revision: https://reviews.llvm.org/D79789
Summary:
When the ClangModulesDeclVendor currently fails it just prints very basic and often incomplete diagnostics without any source locations:
```
(lldb) p @import Foundation
error: while importing modules:
'foo/bar.h' file not found
could not build module 'Darwin'
[...]
```
or even just
```
(lldb) p @import Foundation
error: while importing modules:
could not build module 'Darwin'
[...]
```
These diagnostics help neither the user nor us with figuring out what is the reason for the failure.
This patch wires up a full TextDiagnosticPrinter in the ClangModulesDeclVendor and makes
sure we always return the error stream to the user when we fail to compile our modules.
Fixes rdar://63216849
Reviewers: aprantl, jdoerfert
Reviewed By: aprantl
Subscribers: JDevlieghere
Differential Revision: https://reviews.llvm.org/D79947
Skip tests or parts thereof that aren't expected to work when run from a
reproducer. Also improve the doc comments in configuration.py to prevent
mistakes in the future.
These test don't execute the binaries they build, and so they don't need
to build for the host. By hardcoding the target, we don't have do xfail
or skip them for targets which don't have the appropriate support in
clang(-cl).
Summary:
If we have a binary without symbol information (and without
LC_FUNCTION_STARTS, if on a mac), then we have to resort to using
heuristics to determine the function boundaries. However, these don't
always work, and so we can easily end up thinking we have functions
which are several megabytes in size. Attempting to (accidentally)
disassemble these can take a very long time spam the terminal with
thousands of lines of disassembly.
This patch works around that problem by adding a sanity check to the
disassemble command. If we are about to disassemble a function which is
larger than a certain threshold, we will refuse to disassemble such a
function unless the user explicitly specifies the number of instructions
to disassemble, uses start/stop addresses for disassembly, or passes the
(new) --force argument.
The threshold is currently fairly aggressive (4000 bytes ~~ 1000
instructions). If needed, we can increase it, or even make it
configurable.
Differential Revision: https://reviews.llvm.org/D79789
Summary:
The D programming language has 'char', 'wchar', and 'dchar' as base types,
which are defined as UTF-8, UTF-16, and UTF-32, respectively.
It also has type constructors (e.g. 'const' and 'immutable'),
that leads to D compilers emitting DW_TAG_base_type with DW_ATE_UTF
and name 'char', 'immutable(wchar)', 'const(char)', etc...
Before this patch, DW_ATE_UTF would only recognize types that
followed the C/C++ naming, and emit an error message for the rest, e.g.:
```
error: need to add support for DW_TAG_base_type 'immutable(char)'
encoded with DW_ATE = 0x10, bit_size = 8
```
The code was changed to check the byte size first,
then fall back to the old name-based check.
Reviewers: clayborg, labath
Reviewed By: labath
Subscribers: labath, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D79559
This patch marks following tests as xfail for arm-linux target.
lldb/test/API/functionalities/load_using_paths/TestLoadUsingPaths.py
lldb/test/API/python_api/thread/TestThreadAPI.py
lldb/test/Shell/Recognizer/assert.test
Bugs have been filed for all of them for the corresponding failing
component.
This patch fixes minidebuginfo-set-and-hit-breakpoint.test for arm-linux
targets. 32-bit elf executables use .rel.dyn and 64-bit uses .rela.dyn for
relocation entries for dynamic symbols.
Summary:
This patch fixes an error happening in TestNumThreads.py when it encounters frame.GetFunctionName none for address only locations in stripped libc.
This error was showing up on arm-linux docker container running lldb buildbot.
Reviewers: labath
Reviewed By: labath
Subscribers: kristof.beyls, lldb-commits
Differential Revision: https://reviews.llvm.org/D79777
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
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: 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
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
