| Age | Commit message (Collapse) | Author |
|---|
|
supports -fbounds-safety (#169112)
This patch makes it possible to detect in LLDB shell and API tests if
`-fbounds-safety` is supported by the compiler used for testing. The
motivation behind this is to allow upstreaming
https://github.com/swiftlang/llvm-project/pull/11835 but with the tests
disabled in upstream because the full implementation of -fbounds-safety
isn't available in Clang yet.
For shell tests when -fbounds-safety is available the
`clang-bounds-safety` feature is available which means tests can be
annotated with `# REQUIRES: clang-bounds-safety`.
API tests that need -fbounds-safety support in the compiler can use the
new `@skipUnlessBoundsSafety` decorator.
rdar://165225507
|
|
* original change #162730
* with windows fix #164843
* remove timeout that was pointed out in the comment above
* Remove test that starts and listens on a socket to avoid timeout
issues
|
|
Think it's just a path slash difference.
Fixes #167997.
|
|
DWARF units in .dwp files in LLDB. (#167997)
This patch is updating the reading capabilities of the LLDB DWARF parser
for a llvm-dwp patch https://github.com/llvm/llvm-project/pull/167457
that will emit .dwp files where the compile units are DWARF32 and the
.debug_str_offsets tables will be emitted as DWARF64 to allow .debug_str
sections that exceed 4GB in size.
|
|
The Transactional Memory Extension (TME) was introduced as part of
Armv9-A but has not been adopted by the ecosystem. This mirrors what
Arm has observed with similar extensions in other architectures.
Therefore, remove FEAT_TME assembly and ACLE code from llvm, because
support for TME has now been officially withdrawn, as noted here:
```
FEAT_TME is withdrawn from all future versions of Arm®
Architecture Reference Manual for A-profile architecture.
```
referenced in Known Issue D24093, documented here:
https://developer.arm.com/documentation/102105/lb-05/
|
|
|
|
`asm()` on function declarations is used for specifying the mangling.
But that specific spelling is a GNU extension unlike `__asm()`.
Found by building with `-std=c2y` in Clang's C frontend's config file.
|
|
|
|
|
|
(#167220)
The explicit language specifications for Objective C/C++ don't seem necessary either so I've removed
them too.
I found these by using Clang frontend configuration files containing language-specific options for
both C and C++ (e.g. `-std=c2y` and `-std=c++26`).
Prior-art: 21041c9
|
|
expression log instead of console (#166964)
Depends on:
* https://github.com/llvm/llvm-project/pull/166917
* https://github.com/llvm/llvm-project/pull/166940
While these errors can contribute to an expression failing, they are
never *the* reason the expression failed. I.e., they are always just
'note:' diagnostics that we hand-emit. Because they are quite noisy (and
we potentially have many of them if we auto-load all modules in a CU),
this patch logs the errors to the `expr` log, instead of the console.
Previously these errors would only get omitted when the expression
itself failed. Meaning if the expression failed, we'd dump these 'note'
module load errors in next to the actual expression error, obscuring the
output. Moreover, if the expression succeeded, any module load errors
would be dropped. Now we always log all module loading errors to the
expression log, regardless of whether the expression fails or not.
|
|
individual import failed (#166940)
Depends on:
* https://github.com/llvm/llvm-project/pull/166917
When loading all Clang modules for a CU, we stop on first error. This
means benign module loading errors may stop us from importing actually
useful modules. There's no good reason to bail on the first one. The
pathological case would be if we try to load a large number of Clang
modules
but all fail to load for the same reason. That could happen, but in
practice I've always seen only a handful of modules failing to load out
of a large number. Particularly system modules are useful and usually
don't fail to load. Whereas project-specific Clang modules are more
likely to fail because the build system moves the modulemap/sources
around.
This patch accumulates all module loading errors and doesn't stop when
an error is encountered.
|
|
modules (#166917)
Instead of propagating the errors as a `bool`+`Stream` we change the
`ClangModulesDeclVendor` module loading APIs to use `llvm::Error`. We
also reword some of the diagnostics (notably removing the hardcoded
`error:` prefix). A follow-up patch will further make the module loading
errors less noisy.
See the new tests for what the errors look like.
rdar://164002569
|
|
call" (#166970)
Reverts llvm/llvm-project#166769
Darwin platforms prefix symbols with `_`, other platforms don't
necessarily.
|
|
`asm()` on function declarations is used for specifying the mangling. But it's a GNU extension and
very much unnecessary here since the name matches.
Fixes compiling if the compiler defaults to non-extensions mode.
|
|
Otherwise these tests are reliant on the compiler defaulting to having the extensions on.
Rest of LLVM's codebase doesn't seem to make such assumptions.
Tested by building with `-std=c2y` in Clang's C frotend's config file.
|
|
When anonymous unions are used in a struct or vice versa, their fields
are merged into the parent record when using PDB. LLDB tries to recreate
the original definition of the record _with_ the anonymous
unions/structs.
For tagged unions (like `std::optional`) where the tag followed the
anonymous union, the result was suboptimal:
```cpp
// input:
struct Foo {
union {
Bar b;
char c;
};
bool tag;
};
// reconstructed:
struct Foo {
union {
Bar b;
struct {
char c;
bool tag;
};
};
};
```
Once the algorithm is in some nested union, it can't get out.
In the above case, we can get to the correct reconstructed record if we
always add fields that don't overlap others in the root struct. So when
we see `tag`, we'll see that it comes after all other fields, so it's
possible to add it in the root `Foo`.
|
|
Fails with:
```
RUN: at line 4
split-file C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\test\Shell\Recognizer\registration-unique.test C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\build\tools\lldb\test\Shell\Recognizer\Output\registration-unique.test.tmp
executed command: split-file 'C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\test\Shell\Recognizer\registration-unique.test' 'C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\build\tools\lldb\test\Shell\Recognizer\Output\registration-unique.test.tmp'
note: command had no output on stdout or stderr
RUN: at line 6
c:\users\tcwg\llvm-worker\lldb-aarch64-windows\build\bin\clang.exe --target=specify-a-target-or-use-a-_host-substitution --target=aarch64-pc-windows-msvc -fmodules-cache-path=C:/Users/tcwg/llvm-worker/lldb-aarch64-windows/build/lldb-test-build.noindex/module-cache-clang\lldb-shell C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\build\tools\lldb\test\Shell\Recognizer\Output\registration-unique.test.tmp/main.cpp -g -o C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\build\tools\lldb\test\Shell\Recognizer\Output\registration-unique.test.tmp/cpp.out
executed command: 'c:\users\tcwg\llvm-worker\lldb-aarch64-windows\build\bin\clang.exe' --target=specify-a-target-or-use-a-_host-substitution --target=aarch64-pc-windows-msvc '-fmodules-cache-path=C:/Users/tcwg/llvm-worker/lldb-aarch64-windows/build/lldb-test-build.noindex/module-cache-clang\lldb-shell' 'C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\build\tools\lldb\test\Shell\Recognizer\Output\registration-unique.test.tmp/main.cpp' -g -o 'C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\build\tools\lldb\test\Shell\Recognizer\Output\registration-unique.test.tmp/cpp.out'
.---command stderr------------
| clang: warning: argument unused during compilation: '-fmodules-cache-path=C:/Users/tcwg/llvm-worker/lldb-aarch64-windows/build/lldb-test-build.noindex/module-cache-clang\lldb-shell' [-Wunused-command-line-argument]
`-----------------------------
RUN: at line 7
c:\users\tcwg\llvm-worker\lldb-aarch64-windows\build\bin\lldb.exe --no-lldbinit -S C:/Users/tcwg/llvm-worker/lldb-aarch64-windows/build/tools/lldb\test\Shell\lit-lldb-init-quiet -b -s C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\build\tools\lldb\test\Shell\Recognizer\Output\registration-unique.test.tmp/commands.input C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\build\tools\lldb\test\Shell\Recognizer\Output\registration-unique.test.tmp/cpp.out | c:\users\tcwg\llvm-worker\lldb-aarch64-windows\build\bin\filecheck.exe C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\test\Shell\Recognizer\registration-unique.test
executed command: 'c:\users\tcwg\llvm-worker\lldb-aarch64-windows\build\bin\lldb.exe' --no-lldbinit -S 'C:/Users/tcwg/llvm-worker/lldb-aarch64-windows/build/tools/lldb\test\Shell\lit-lldb-init-quiet' -b -s 'C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\build\tools\lldb\test\Shell\Recognizer\Output\registration-unique.test.tmp/commands.input' 'C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\build\tools\lldb\test\Shell\Recognizer\Output\registration-unique.test.tmp/cpp.out'
note: command had no output on stdout or stderr
executed command: 'c:\users\tcwg\llvm-worker\lldb-aarch64-windows\build\bin\filecheck.exe' 'C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\test\Shell\Recognizer\registration-unique.test'
.---command stderr------------
| C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\test\Shell\Recognizer\registration-unique.test:45:10: error: CHECK: expected string not found in input
| # CHECK: Assert StackFrame Recognizer
| ^
| <stdin>:20:38: note: scanning from here
| 1: Verbose Trap StackFrame Recognizer, demangled symbol regex ^__clang_trap_msg
| ^
| <stdin>:34:10: note: possible intended match here
| 3: Verbose Trap StackFrame Recognizer, demangled symbol regex ^__clang_trap_msg
| ^
|
| Input file: <stdin>
| Check file: C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\test\Shell\Recognizer\registration-unique.test
|
| -dump-input=help explains the following input dump.
```
|
|
recognizer registration
These might get registered in a different order on different platforms.
Use `CHECK-DAG` to account for that.
Attempts to fix the failure seen on the x86 Linux bots:
```
******************** TEST 'lldb-shell :: Recognizer/registration-unique.test' FAILED ********************
Exit Code: 1
Command Output (stdout):
--
RUN: at line 4
lit-file C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\test\Shell\Recognizer\registration-unique.test C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\build\tools\lldb\test\Shell\Recognizer\Output\registration-unique.test.tmp
executed command: split-file 'C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\test\Shell\Recognizer\registration-unique.test' 'C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\build\tools\lldb\test\Shell\Recognizer\Output\registration-unique.test.tmp'
note: command had no output on stdout or stderr
RUN: at line 6
\users\tcwg\llvm-worker\lldb-aarch64-windows\build\bin\clang.exe --target=specify-a-target-or-use-a-_host-substitution --target=aarch64-pc-windows-msvc -fmodules-cache-path=C:/Users/tcwg/llvm-worker/lldb-aarch64-windows/build/lldb-test-build.noindex/module-cache-clang\lldb-shell C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\build\tools\lldb\test\Shell\Recognizer\Output\registration-unique.test.tmp/main.cpp -g -o C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\build\tools\lldb\test\Shell\Recognizer\Output\registration-unique.test.tmp/cpp.out
executed command: 'c:\users\tcwg\llvm-worker\lldb-aarch64-windows\build\bin\clang.exe' --target=specify-a-target-or-use-a-_host-substitution --target=aarch64-pc-windows-msvc '-fmodules-cache-path=C:/Users/tcwg/llvm-worker/lldb-aarch64-windows/build/lldb-test-build.noindex/module-cache-clang\lldb-shell' 'C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\build\tools\lldb\test\Shell\Recognizer\Output\registration-unique.test.tmp/main.cpp' -g -o 'C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\build\tools\lldb\test\Shell\Recognizer\Output\registration-unique.test.tmp/cpp.out'
.---command stderr------------
| clang: warning: argument unused during compilation: '-fmodules-cache-path=C:/Users/tcwg/llvm-worker/lldb-aarch64-windows/build/lldb-test-build.noindex/module-cache-clang\lldb-shell' [-Wunused-command-line-argument]
`-----------------------------
RUN: at line 7
\users\tcwg\llvm-worker\lldb-aarch64-windows\build\bin\lldb.exe --no-lldbinit -S C:/Users/tcwg/llvm-worker/lldb-aarch64-windows/build/tools/lldb\test\Shell\lit-lldb-init-quiet -b -s C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\build\tools\lldb\test\Shell\Recognizer\Output\registration-unique.test.tmp/commands.input C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\build\tools\lldb\test\Shell\Recognizer\Output\registration-unique.test.tmp/cpp.out | c:\users\tcwg\llvm-worker\lldb-aarch64-windows\build\bin\filecheck.exe C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\test\Shell\Recognizer\registration-unique.test
executed command: 'c:\users\tcwg\llvm-worker\lldb-aarch64-windows\build\bin\lldb.exe' --no-lldbinit -S 'C:/Users/tcwg/llvm-worker/lldb-aarch64-windows/build/tools/lldb\test\Shell\lit-lldb-init-quiet' -b -s 'C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\build\tools\lldb\test\Shell\Recognizer\Output\registration-unique.test.tmp/commands.input' 'C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\build\tools\lldb\test\Shell\Recognizer\Output\registration-unique.test.tmp/cpp.out'
note: command had no output on stdout or stderr
executed command: 'c:\users\tcwg\llvm-worker\lldb-aarch64-windows\build\bin\filecheck.exe' 'C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\test\Shell\Recognizer\registration-unique.test'
.---command stderr------------
| C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\test\Shell\Recognizer\registration-unique.test:45:10: error: CHECK: expected string not found in input
| # CHECK: Assert StackFrame Recognizer
| ^
| <stdin>:20:38: note: scanning from here
| 1: Verbose Trap StackFrame Recognizer, demangled symbol regex ^__clang_trap_msg
| ^
| <stdin>:34:10: note: possible intended match here
| 3: Verbose Trap StackFrame Recognizer, demangled symbol regex ^__clang_trap_msg
| ^
|
| Input file: <stdin>
| Check file: C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\test\Shell\Recognizer\registration-unique.test
|
| -dump-input=help explains the following input dump.
|
| Input was:
| <<<<<<
```
|
|
(#166157)
https://github.com/llvm/llvm-project/pull/165996 is adding a Clang
dependency to Target because we're moving some of the functionality of
the VerboseTrapFrameRecognizer into libClang. To avoid adding this
dependency this patch moves VerboseTrapFrameRecognizer into the
CPPLanguageRuntime. Most of the frame recognizers already live in the
various runtime plugins.
An alternative discussed was to create a common `CLanguageRuntime` whose
currently sole responsibility was to register the
`VerboseTrapFrameRecognizer` and `AssertStackFrameRecognizer`. The main
issue I ran into here was frame recognizers aren't uniqued in the
target. Currently this only manifests when re-running a target, which
re-triggers all the recognizer registration (added a test with a FIXME
for this). If we had a common `CLanguageRuntime` that
`CPPLanguageRuntime` and `ObjCLanguageRuntime` inherited from, I didn't
find a great way to avoid registering the recognizer multiple times. We
can't just call_once on it because we do want the recognisers to be
re-registered for new targets in the same debugger session. If the
recognisers were stored in something like a UniqueVector in the Target,
then we wouldn't have that issue. But currently that's not the case, and
it would take a bit of refactoring to de-dupe the recognisers.
There may very well be solutions I haven't considered, but all the
things I've tried so far I wasn't very happy with. So in the end I just
moved this to the C++ runtime for now in order to unblock
https://github.com/llvm/llvm-project/pull/165996.
The C++ language runtime is always available (even for C targets) if the
C++ language plugin is available. Which it should also be unless someone
is using an LLDB with the C++ plugin compiled out. But at that point
numerous things wouldn't work when even debugging just C.
|
|
Support launching a supported DAP client using the lldb-dap binary.
Currently, only the official LLDB-DAP Visual Studio Code extension is
supported. It uses the VS Code launch URL format.
Here's an example:
```
lldb-dap --client vscode -- /path/to/exe foo bar
```
This will open the following URL with `code --open-url`:
```
vscode://llvm-vs-code-extensions.lldb-dap/start?program=/path/to/exe&args=foo&arg=bar
```
Fixes #125777
|
|
This commit aggregates the following changes:
1. Fix the format (i.e., indentation) when printing stop hooks via `target
stop-hook list`.
2. Add `IndentScope Stream::MakeIndentScope()` to make managing (and restoring!)
of the indentation level on `Stream` instances more ergonomic and less error
prone.
3. Simplify printing of stop hooks using the new `IndentScope`.
|
|
In #165604, a test was skipped on Windows, because the native PDB plugin
didn't set sizes on symbols. While the test isn't compiled with debug
info, it's linked with `-gdwarf`, causing a PDB to be created on
Windows. This PDB will only contain the public symbols (written by the
linker) and section information. The symbols themselves don't have a
size, however the DIA SDK sets a size for them.
It seems like, for these data symbols, the size given from DIA is the
distance to the next symbol (or the section end).
This PR implements the naive approach for the native plugin. The main
difference is in function/code symbols. There, DIA searches for a
corresponding `S_GPROC32` which have a "code size" that is sometimes
slightly smaller than the difference to the next symbol.
|
|
Most of the cases were where a C++ file was being compiled with the C substitution.
There were a few cases of the opposite though.
LLDB seems to be the only real culprit in the LLVM codebase for these mismatches.
Rest of the LLVM presumably sticks at least language-specific options in the common substitutions
making the mistakes immediately apparent.
I found these by using Clang frontend configuration files containing language-specific options for
both C and C++ (e.g. `-std=c2y` and `-std=c++26`).
|
|
`std::ref()` is provided in `<functional>` and with recent libc++ changes it no longer seems to be
included transitively. Fix by including explicitly.
|
|
llvm-dsymutil can produce mach-o files where some sections in __DWARF
exceed the 4GB barrier and subsequent sections in the dSYM will be
inaccessible because the mach-o section_64 structure only has a 32 bit
file offset. This patch enables LLDB to load a large dSYM file by
figuring out when this happens and properly adjusting the file offset of
the LLDB sections.
I was unable to add a test as obj2yaml and yaml2obj are broken for
mach-o files and they can't convert a yaml file back into a valid mach-o
object file. Any suggestions for adding a test would be appreciated.
|
|
All PDB tests now pass when compiled without DIA on Windows, so they
pass with the native reader.
With this PR, the default reader changes to the native reader.
The plan is to eventually remove the DIA reader (see
https://discourse.llvm.org/t/rfc-removing-the-dia-pdb-plugin-from-lldb/87827
and #114906).
For now, DIA can be used by setting `plugin.symbol-file.pdb.reader` to
`dia` or by setting `LLDB_USE_NATIVE_PDB_READER=0` (mostly undocumented,
but used in tests).
|
|
This test passes with both plugins, but only ran with the DIA plugin. It
was fixed with #161678, where I missed this test.
|
|
types (#163621)
When creating all types in a compilation unit, simple types (~>
primitive and pointer types) that were only used in function arguments
or return types weren't created as LLDB `Type`s.
With this PR, they're created when creating the function/method types.
This makes it possible to run the `SymbolFile/PDB/typedefs.test` with
both plugins.
|
|
Introduce the concept of internal stop hooks.
These are similar to LLDB's internal breakpoints:
LLDB itself will add them and users of LLDB will
not be able to add or remove them.
This change adds the following 3
independently-useful concepts:
* Maintain a list of internal stop hooks that will be populated by LLDB
and cannot be added to or removed from by users. They are managed in a
separate list in `Target::m_internal_stop_hooks`.
* `StopHookKind:CodeBased` and `StopHookCoded` represent a stop hook
defined by a C++ code callback (instead of command line expressions or a
Python class).
* Stop hooks that do not print any output can now also suppress the
printing of their header and description when they are hit via
`StopHook::GetSuppressOutput`.
Combining these 3 concepts we can model "internal
stop hooks" which serve the same function as
LLDB's internal breakpoints: executing built-in,
LLDB-defined behavior, leveraging the existing
mechanism of stop hooks.
This change also simplifies
`Target::RunStopHooks`. We already have to
materialize a new list for combining internal and
user stop hooks. Filter and only add active hooks to this list to avoid
the need for "isActive?"
checks later on.
|
|
This reverts commit faf7af864f9258768133894764f1fae58d43bb09.
This is failing on the Darwin bots.
https://green.lab.llvm.org/job/llvm.org/view/LLDB/job/lldb-cmake/16164/changes#faf7af864f9258768133894764f1fae58d43bb09
|
|
This reverts commit 930b36cfbbc873fe6c329b95e1c56c6ae1ea1d94.
Reverting because it depends on 5fc40a5f2bedaf6ca3f024aa2a91c5f4ce187061.
|
|
Fix windows test failures from
https://github.com/llvm/llvm-project/pull/162730 by including and
optional .exe on the lldb-server name. Still passes on linux, but should
pass on windows now.
```
> bin/llvm-lit -v tools/lldb/test/Shell/lldb-server/
llvm-lit: llvm-project/llvm/utils/lit/lit/llvm/config.py:531: note: using clang: llvm-project/build/bin/clang
llvm-lit: llvm-project/llvm/utils/lit/lit/llvm/config.py:531: note: using ld.lld: /usr/bin/ld.lld
llvm-lit: llvm-project/llvm/utils/lit/lit/llvm/config.py:531: note: using lld-link: /usr/bin/lld-link
llvm-lit: llvm-project/llvm/utils/lit/lit/llvm/config.py:531: note: using ld64.lld: /usr/bin/ld64.lld
llvm-lit: llvm-project/llvm/utils/lit/lit/llvm/config.py:531: note: using wasm-ld: /usr/bin/wasm-ld
llvm-lit: llvm-project/llvm/utils/lit/lit/llvm/subst.py:126: note: Did not find obj2yaml in llvm-project/build/./bin:llvm-project/build/./bin
llvm-lit: llvm-project/llvm/utils/lit/lit/llvm/subst.py:126: note: Did not find llvm-objdump in llvm-project/build/./bin:llvm-project/build/./bin
llvm-lit: llvm-project/lldb/test/Shell/lit.cfg.py:125: warning: Could not set a default per-test timeout. Requires the Python psutil module but it could not be found. Try installing it via pip or via your operating system's package manager.
-- Testing: 4 tests, 4 workers --
PASS: lldb-shell :: lldb-server/TestGdbserverErrorMessages.test (1 of 4)
PASS: lldb-shell :: lldb-server/TestPlatformHelp.test (2 of 4)
PASS: lldb-shell :: lldb-server/TestPlatformErrorMessages.test (3 of 4)
PASS: lldb-shell :: lldb-server/TestPlatformSuccessfulStartup.test (4 of 4)
Testing Time: 1.10s
Total Discovered Tests: 4
Passed: 4 (100.00%)
1 warning(s) in tests
```
|
|
The lldb-server platform help text is inconsistent with lldb-server
gdbserver help text. This PR modernizes the platform server to use
LLVM's [TableGen](https://llvm.org/docs/TableGen/)-based option parsing
(matching the existing gdbserver implementation), which auto-generates
option parsing code and help text.
The changes improve documentation quality by adding comprehensive option
descriptions,, adding support for `-h`/`--help` flags, and organizing
help output with DESCRIPTION and EXAMPLES sections. Internal-only
options (`--child-platform-fd`) and unused legacy options (`--debug`,
`--verbose`) are now hidden from help while maintaining backward
compatibility. All functional behavior remains unchanged—this is purely
a documentation and code modernization improvement.
## before
```
> /opt/llvm/bin/lldb-server p -h
p: unrecognized option '-h'
Usage:
/opt/llvm/bin/lldb-server p [--log-file log-file-name] [--log-channels log-channel-list] [--port-file port-file-path] --server --listen port
```
## after
```
lldb-server p -h
OVERVIEW: lldb-server platform
USAGE: lldb-server p [options] --listen <[host]:port> [[--] program args...]
CONNECTION OPTIONS:
--gdbserver-port <port> Port to use for spawned gdbserver instances. If 0 or unspecified, a port will be chosen automatically. Short form: -P
--listen <[host]:port> Host and port to listen on. Format: [host]:port or protocol://[host]:port (e.g., tcp://localhost:1234, unix:///path/to/socket). Short form: -L
--socket-file <path> Write listening socket information (port number for TCP or path for Unix domain sockets) to the specified file. Short form: -f
GENERAL OPTIONS:
--help Display this help message and exit.
--log-channels <channel1 categories...:channel2 categories...>
Channels to log. A colon-separated list of entries. Each entry starts with a channel followed by a space-separated list of categories. Common channels: lldb, gdb-remote, platform, process. Short form: -c
--log-file <file> Destination file to log to. If empty, log to stderr. Short form: -l
--server Run in server mode, accepting multiple client connections sequentially. Without this flag, the server exits after handling the first connection.
OPTIONS:
-- program args Arguments to pass to launched gdbserver instances.
DESCRIPTION
Acts as a platform server for remote debugging. When LLDB clients connect,
the platform server handles platform operations (file transfers, process
launching) and spawns debug server instances (lldb-server gdbserver) to
handle actual debugging sessions.
By default, the server exits after handling one connection. Use --server
to keep running and accept multiple connections sequentially.
EXAMPLES
# Listen on port 1234, exit after first connection
lldb-server platform --listen tcp://0.0.0.0:1234
# Listen on port 5555, accept multiple connections
lldb-server platform --server --listen tcp://localhost:5555
# Listen on Unix domain socket
lldb-server platform --listen unix:///tmp/lldb-server.sock
```
For comparison, here is the **gdbserver** help text:
```
lldb-server g -h
OVERVIEW: lldb-server
USAGE: lldb-server g[dbserver] [options] [[host]:port] [[--] program args...]
CONNECTION:
--fd <fd> Communicate over the given file descriptor.
--named-pipe <name> Write port lldb-server will listen on to the given named pipe.
--pipe <fd> Write port lldb-server will listen on to the given file descriptor.
--reverse-connect Connect to the client instead of passively waiting for a connection. In this case [host]:port denotes the remote address to connect to.
GENERAL OPTIONS:
--help Prints out the usage information for lldb-server.
--log-channels <channel1 categories...:channel2 categories...>
Channels to log. A colon-separated list of entries. Each entry starts with a channel followed by a space-separated list of categories.
--log-file <file> Destination file to log to. If empty, log to stderr.
--setsid Run lldb-server in a new session.
TARGET SELECTION:
--attach <pid-or-name> Attach to the process given by a (numeric) process id or a name.
-- program args Launch program for debugging.
DESCRIPTION
lldb-server connects to the LLDB client, which drives the debugging session.
If no connection options are given, the [host]:port argument must be present
and will denote the address that lldb-server will listen on. [host] defaults
to "localhost" if empty. Port can be zero, in which case the port number will
be chosen dynamically and written to destinations given by --named-pipe and
--pipe arguments.
If no target is selected at startup, lldb-server can be directed by the LLDB
client to launch or attach to a process.
```
|
|
The test builds files for Windows, so the target has to be required. I
didn't add this in #163733.
Fixes the failure from
https://github.com/llvm/llvm-project/pull/163733#issuecomment-3426275296.
|
|
The `pointers.test` was only run with the DIA plugin. I made the
following changes:
- Remove the check for the function type.
The types of the function are different in the plugins:
```
Native:
Type{0x00010084} , size = 0, compiler_type = 0x00000209aff60060 int
(int) __attribute__((thiscall))
DIA:
Type{0x0000000a} , name = "f", decl = PointerTypeTest.cpp:8,
compiler_type = 0x0000020bc22356c0 int (int) __attribute__((thiscall))
```
In DIA, each function gets its own type with a name and decl. In the
native plugin, only one unnamed type is created per signature. This
matches DWARF.
- The check for the `struct ST` fields was split, because the order of
members and methods is swapped between the plugins. In DIA, the member
is first and in the native plugin the method is first. We still check
that both are in the struct.
- The type names for the local variables are different. The native
plugin includes <code>\`extern "C" main'::\`2'::ST</code> which I added
as an allowed prefix. This comes from the mangled name of the struct
`ST` - `.?AUST@?1??main@@9@`.
- The location of local variables is different. DIA creates one static
location (e.g. `DW_OP_breg6 ESI-52`) whereas the native plugin limits
the location to the block (e.g. `[0x0040100d, 0x00401038): DW_OP_breg6
ESI-52`). This gets printed on a second line and the `location` starts
with `0x00000000:`
- DIA adds a decl for each parameter (and local variable). However, this
information is not contained in the PDB. I'm not sure how DIA calculates
this. It's often wrong and assumes variables are declared earlier. For
example, in this test
([PointerTypeTest.cpp](https://github.com/llvm/llvm-project/blob/2b135b931338a57c38d9c4a34ffdd59877ba82d6/lldb/test/Shell/SymbolFile/PDB/Inputs/PointerTypeTest.cpp)),
it assumes that all local variables of `main` are created on line 4. The
native plugin doesn't include this, so I made the check optional.
|
|
The test checks that functions have the correct type assigned. Because
of the differences between the two PDB plugins, I split the test.
DIA creates one named `Type` per function and uses identical UIDs for
`Type` and `Function`, whereas native creates one unnamed type per
signature and has different UIDs.
The native test has the same input and checks the same functions.
I also removed the `target-windows` requirement from the test, since it
only uses `lldb-test`.
|
|
This aligns the simple types created by the native plugin with the ones
from DIA as well as LLVM and the original cvdump.
- A few type names weren't handled when creating the LLDB `Type` name
(e.g. `short`)
- 64-bit integers were created as `(u)int64_t` and are now created as
`(unsigned) long long` (matches DIA)
- 128-bit integers (only supported by clang-cl) weren't created as types
(they have `SimpleTypeKind::(U)Int128Oct`)
- All complex types had the same name - now they have `_Complex
<float-type>`
Some types like `SimpleTypeKind::Float48` can't be tested because they
can't be created in C++.
|
|
Actually emit a warning, rather than an error, when there's an .lldbinit
file in the current directly. Currently, the message is prepended by
"error" which looks rather odd, as the warning refers to itself as a
warning.
|
|
This still fails on Windows because the default language for the C++
frame is not the same as on Unix.
Also remove the LLD requirement, since we're not relying on DWARF here.
|
|
_winreg was renamed to winreg in 3.0, and we require >= 3.8.
https://docs.python.org/3/whatsnew/3.0.html#library-changes
|
|
Before this PR, the native PDB plugin would create the following LLDB
`Type` for `using SomeTypedef = long`:
```
Type{0x00002e03} , name = "SomeTypedef", size = 4, compiler_type = 0x000002becd8d8620 long
```
with this PR, the following is created:
```
Type{0x00002e03} , name = "SomeTypedef", size = 4, compiler_type = 0x0000024d6a7e3c90 typedef SomeTypedef
```
This matches the behavior of the DIA PDB plugin and works towards making
[`Shell/SymbolFile/PDB/typedefs.test`](https://github.com/llvm/llvm-project/blob/main/lldb/test/Shell/SymbolFile/PDB/typedefs.test)
pass with the native plugin.
I added a similar test to the `NativePDB` shell tests to capture the
current state, which doesn't quite match that of DIA yet. I'll add some
comments on what's missing on this PR, because I'm not fully sure what
the correct output would be.
|
|
Otherwise debug-info is stripped, which influences the language of the
current frame.
Also, set explicit breakpoint because Windows seems to not obey the
debugtrap.
Log from failing test on Windows:
```
(lldb) command source -s 0 'lit-lldb-init-quiet'
Executing commands in 'D:\test\lit-lldb-init-quiet'.
(lldb) command source -C --silent-run true lit-lldb-init
(lldb) target create "main.out"
Current executable set to 'D:\test\main.out' (x86_64).
(lldb) settings set interpreter.stop-command-source-on-error false
(lldb) command source -s 0 'with-target.input'
Executing commands in 'D:\test\with-target.input'.
(lldb) expr blah
^
error: use of undeclared identifier 'blah'
note: Falling back to default language. Ran expression as 'Objective C++'.
(lldb) run
Process 29404 launched: 'D:\test\main.out' (x86_64)
Process 29404 stopped
* thread #1, stop reason = Exception 0x80000003 encountered at address 0x7ff7b3df7189
frame #0: 0x00007ff7b3df718a main.out
-> 0x7ff7b3df718a: xorl %eax, %eax
0x7ff7b3df718c: popq %rcx
0x7ff7b3df718d: retq
0x7ff7b3df718e: int3
(lldb) expr blah
^
error: use of undeclared identifier 'blah'
note: Falling back to default language. Ran expression as 'Objective C++'.
(lldb) expr -l objc -- blah
^
error: use of undeclared identifier 'blah'
note: Expression evaluation in pure Objective-C not supported. Ran expression as 'Objective C++'.
(lldb) expr -l c -- blah
^
error: use of undeclared identifier 'blah'
note: Expression evaluation in pure C not supported. Ran expression as 'ISO C++'.
```
|
|
The LLDB test-suite compiles the tests on Windows with 'C++14' by
default:
https://github.com/llvm/llvm-project/blob/3bfb5b0e7ccbcb9f127f5b9c958e6499ba9c0523/lldb/packages/Python/lldbsuite/test/make/Makefile.rules#L357-L360
This fixes Windows buildbot failures.
|
|
for expression evaluation (#161688)
Depends on:
* https://github.com/llvm/llvm-project/pull/162050
Since it's a 'Note' diagnostic it would only show up when expression
evaluation actually failed. This helps with expression evaluation
failure reports in mixed language environments where it's not quite
clear what language the expression ran as. It may also reduce confusion
around why the expression evaluator ran an expression in a language it
wasn't asked to run (a softer alternative to what I attempted in
https://github.com/llvm/llvm-project/pull/156648).
Here are some example outputs:
```
# Without target
(lldb) expr blah
note: Falling back to default language. Ran expression as 'Objective C++'.
# Stopped in target
(lldb) expr blah
note: Ran expression as 'C++14'.
(lldb) expr -l objc -- blah
note: Expression evaluation in pure Objective-C not supported. Ran expression as 'Objective C++'.
(lldb) expr -l c -- blah
note: Expression evaluation in pure C not supported. Ran expression as 'ISO C++'.
(lldb) expr -l c++14 -- blah
note: Ran expression as 'C++14'
(lldb) expr -l c++20 -- blah
note: Ran expression as 'C++20'
(lldb) expr -l objective-c++ -- blah
note: Ran expression as 'Objective C++'
(lldb) expr -l D -- blah
note: Expression evaluation in D not supported. Falling back to default language. Ran expression as 'Objective C++'.
```
I didn't put the diagnostic on the same line as the inline diagnostic
for now because of implementation convenience, but if reviewers deem
that a blocker I can take a stab at that again.
Also, other language plugins (namely Swift), won't immediately benefit
from this and will have to emit their own diagnistc. I played around
with having a virtual API on `UserExpression` or `ExpressionParser` that
will be called consistently, but by the time we're about to parse the
expression we are already several frames deep into the plugin. Before
(and at the beginning of) the generic `UserExpression::Parse` call we
don't have enough information to notify which language we're going to
parse in (at least for the C++ plugin).
rdar://160297649
rdar://159669244
|
|
Fixes the test failure from
https://github.com/llvm/llvm-project/pull/161678#issuecomment-3377949862.
|
|
Relands #149701 which was reverted in
https://github.com/llvm/llvm-project/commit/185ae5cdc695248b58ae017508cc764c19bee5b7
because it broke demangling of Itanium symbols on i386.
The last commit in this PR adds the fix for this (discussed in #160930).
On x86 environments, the prefix of `__cdecl` functions will now be
removed to match DWARF. I opened #161676 to discuss this for the other
calling conventions.
|
|
The cpp file fails to build without `lld-link`.
|
|
Failing with:
```
error: command failed with exit status: 1
executed command: 'c:\buildbot\as-builder-10\lldb-x86-64\build\bin\filecheck.exe' 'C:\buildbot\as-builder-10\lldb-x86-64\llvm-project\lldb\test\Shell\Expr\TestGlobalSymbolObjCConflict.c'
.---command stderr------------
| C:\buildbot\as-builder-10\lldb-x86-64\llvm-project\lldb\test\Shell\Expr\TestGlobalSymbolObjCConflict.c:30:11: error: CHECK: expected string not found in input
| // CHECK: (lldb) p OglobalVar
| ^
| <stdin>:1:1: note: scanning from here
| (lldb) command source -s 0 'C:/buildbot/as-builder-10/lldb-x86-64/build/tools/lldb\test\Shell\lit-lldb-init-quiet'
| ^
| <stdin>:4:1: note: possible intended match here
| (lldb) target create "C:\\buildbot\\as-builder-10\\lldb-x86-64\\build\\tools\\lldb\\test\\Shell\\Expr\\Output\\TestGlobalSymbolObjCConflict.c.tmp.out"
| ^
|
| Input file: <stdin>
| Check file: C:\buildbot\as-builder-10\lldb-x86-64\llvm-project\lldb\test\Shell\Expr\TestGlobalSymbolObjCConflict.c
|
| -dump-input=help explains the following input dump.
|
| Input was:
| <<<<<<
| 1: (lldb) command source -s 0 'C:/buildbot/as-builder-10/lldb-x86-64/build/tools/lldb\test\Shell\lit-lldb-init-quiet'
| check:30'0 X~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ error: no match found
| 2: Executing commands in 'C:\buildbot\as-builder-10\lldb-x86-64\build\tools\lldb\test\Shell\lit-lldb-init-quiet'.
| check:30'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| 3: (lldb) command source -C --silent-run true lit-lldb-init
| check:30'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| 4: (lldb) target create "C:\\buildbot\\as-builder-10\\lldb-x86-64\\build\\tools\\lldb\\test\\Shell\\Expr\\Output\\TestGlobalSymbolObjCConflict.c.tmp.out"
| check:30'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| check:30'1 ? possible intended match
| 5: Current executable set to 'C:\buildbot\as-builder-10\lldb-x86-64\build\tools\lldb\test\Shell\Expr\Output\TestGlobalSymbolObjCConflict.c.tmp.out' (x86_64).
| check:30'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| 6: (lldb) b 27
| check:30'0 ~~~~~~~~~~~~
| >>>>>>
`-----------------------------
error: command failed with exit status: 1
```
We probably need to use LLD here or something. But I don't have a Windows machine to test this on. So XFAILing for now.
|
|
On Darwin C-symbols are prefixed with a '_'. The LLDB Macho-O parses
handles Objective-C metadata symbols starting with '_OBJC' specially.
Previously global symbols starting with a '_O' prefix were lost because
of incorrectly scoped if-guards. This patch removes those checks.
There is more cleanup that can be done in this file because there's a
bunch of duplicated checks for these ObjC symbols. I decided to leave
that for an NFC follow-up.
Depends on https://github.com/llvm/llvm-project/pull/161520
rdar://158159242
|
