Make LanguageRuntime::GetTypeBitSize return an optional. This should be
NFC, though the ObjCLanguageRuntime implementation is (possibly) more
defensive against returning 0.
I'm not sure if it's possible for both `m_ivar.size` and `m_ivar.offset`
to be zero. Previously, we'd return 0 and cache it, only to discard it
the next time when finding it in the cache, and recomputing it again.
The new code will avoid putting it in the cache in the first place.
This change by itself has no measurable effect on the LLDB
testsuite. I'm making it in preparation for threading through more
errors in the Swift language plugin.
With simple template names the template arguments aren't embedded in the
DW_AT_name attribute of the type. The code in
FindDefinitionTypeForDWARFDeclContext was comparing the synthesized
template arguments on the leaf (most deeply nested) DIE, but was not
sufficient, as the difference get be at any level above that
(Foo<T>::Bar vs. Foo<U>::Bar). This patch makes sure we compare the
entire context.
As a drive-by I also remove the completely unnecessary
ConstStringification of the GetDIEClassTemplateParams result.
# Added/changed options
The following options are **added** to the `statistics dump` command:
* `--targets=bool`: Boolean. Dumps the `targets` section.
* `--modules=bool`: Boolean. Dumps the `modules` section.
When both options are given, the field `moduleIdentifiers` will be
dumped for each target in the `targets` section.
The following options are **changed**:
* `--transcript=bool`: Changed to a boolean. Dumps the `transcript`
section.
# Behavior of `statistics dump` with various options
The behavior is **backward compatible**:
- When no options are provided, `statistics dump` dumps all sections.
- When `--summary` is provided, only dumps the summary info.
**New** behavior:
- `--targets=bool`, `--modules=bool`, `--transcript=bool` overrides the
above "default".
For **example**:
- `statistics dump --modules=false` dumps summary + targets +
transcript. No modules.
- `statistics dump --summary --targets=true --transcript=true` dumps
summary + targets (in summary mode) + transcript.
# Added options into public API
In `SBStatisticsOptions`, add:
* `Set/GetIncludeTargets`
* `Set/GetIncludeModules`
* `Set/GetIncludeTranscript`
**Alternative considered**: Thought about adding
`Set/GetIncludeSections(string sections_spec)`, which receives a
comma-separated list of section names to be included ("targets",
"modules", "transcript"). The **benefit** of this approach is that the
API is more future-proof when it comes to possible adding/changing of
section names. **However**, I feel the section names are likely to
remain unchanged for a while - it's not like we plan to make big changes
to the output of `statistics dump` any time soon. The **downsides** of
this approach are: 1\ the readability of the API is worse (requires
reading doc to understand what string can be accepted), 2\ string input
are more prone to human error (e.g. typo "target" instead of expected
"targets").
# Tests
```
bin/llvm-lit -sv ../external/llvm-project/lldb/test/API/commands/statistics/basic/TestStats.py
```
```
./tools/lldb/unittests/Interpreter/InterpreterTests
```
New test cases have been added to verify:
* Different sections are dumped/not dumped when different
`StatisticsOptions` are given through command line (CLI or
`HandleCommand`; see `test_sections_existence_through_command`) or API
(see `test_sections_existence_through_api`).
* The order in which the options are given in command line does not
matter (see `test_order_of_options_do_not_matter`).
---------
Co-authored-by: Roy Shi <royshi@meta.com>
The following warning is technically correct, but pretty much useless,
since there aren't any frame variables that we'd expect the debugger to
understand.
> This version of LLDB has no plugin for the language "assembler".
> Inspection of frame variables will be limited.
This message is useful in the general case but should be suppressed for
the "assembler" case.
rdar://92745462
Currently, the instrumentation runtime is caching a library the first
time it sees it in the module list. However, in some rare cases on
Darwin, the cached pre-run unloaded modules are different from the
runtime module that is loaded at runtime. This patch removes the cached
module if the plugin fails to activate, ensuring that on subsequent
calls we don't try to activate using the unloaded cached module.
There are a few related bugs to fix in a follow up: CheckIfRuntimeValid
should have a stronger check to ensure the module is loaded and can be
activated. Further investigation in
UpdateSpecialBinariesFromNewImageInfos calling ModulesDidLoad when the
module list may have unloaded modules.
I have not included a test for the following reasons:
1. This is an incredibly rare occurance and is only observed in a
specific circumstance on Darwin. It is tied to behavior in the
DynamicLoader thai is not commonly encountered.
2. It is difficult to reproduce -- this bug requires precise conditions
on darwin and it is unclear how we'd reproduce that in a controlled
testing environment.
rdar://128971453
When Jason was looking into the issue caused by #95606 he suggested
using the Checksum from the original file in LineEntry. I like the idea
because it makes sense semantically, but also allows us to get rid of
the Update method and ensures we make a new copy, in case someone else
is holding onto the old SupportFile.
This represents the enum type that can be assigned to a field using the
`<enum>` element in the target XML.
https://sourceware.org/gdb/current/onlinedocs/gdb.html/Enum-Target-Types.html
Each enumerator has:
* A non-empty name
* A value that is within the range of the field it's applied to
The XML includes a "size" but we don't need that for anything and it's a
pain to verify so I've left it out of our internal structures. When
emitting XML we'll set size to the size of the register using the enum.
An Enumerator class is added to RegisterFlags and hooked up to the
existing ToXML so lldb-server can use it to emit enums as well.
As enums are elements on the same level as flags, when emitting XML
we'll do so via the registers. Before emitting a flags element we look
at all the fields and see what enums they reference. Then print all of
those if we haven't already done so.
Functions are added to dump enum information for `register info` to use
to show the enum information.
The dead code is caught by PVS studio analyzer -
https://pvs-studio.com/en/blog/posts/cpp/1126/, fragment N12.
Warning message -
V523 The 'then' statement is equivalent to the 'else' statement.
Options.cpp 1212
The check that max_bit_pos == sign_bit_pos conflicts with the check that
sign_bit_pos < max_bit_pos in the block surrounding it.
Originally found by cppcheck -
lldb/source/Utility/Scalar.cpp:756:23: warning: Opposite inner 'if'
condition leads to a dead code block. [oppositeInnerCondition]
Fixes#85985
To implement SaveCore for elf binaries we need to populate some
additional fields in the prpsinfo struct. Those fields are the nice
value of the process whose core is to be taken as well as a boolean flag
indicating whether or not that process is a zombie. This commit adds
those as well as tests to ensure that the values are consistent with
expectations
This patch factors out the completion logic for individual clang::Type's
into their own helper functions.
During the process I cleaned up a few assumptions (e.g., unnecessary
if-guards that could be asserts because these conditions are guaranteed
by the `clang::Type::TypeClass` switch in `GetCompleteQualType`).
This is mainly motivated by the type-completion rework proposed in
https://github.com/llvm/llvm-project/pull/95100.
Hello!
Currently, watchpoints don't work on Windows (this can be reproduced
with the existing tests). This patch fixes the related issues so that
the tests and watchpoints start working.
Here is the list of tests that are fixed by this patch (on Windows,
checked in **release/18.x** branch):
- commands/watchpoints/hello_watchpoint/TestMyFirstWatchpoint.py
- commands/watchpoints/multiple_hits/TestMultipleHits.py
- commands/watchpoints/multiple_threads/TestWatchpointMultipleThreads.py
- commands/watchpoints/step_over_watchpoint/TestStepOverWatchpoint.py
- commands/watchpoints/unaligned-watchpoint/TestUnalignedWatchpoint.py
- commands/watchpoints/watchpoint_commands/TestWatchpointCommands.py
-
commands/watchpoints/watchpoint_commands/command/TestWatchpointCommandLLDB.py
-
commands/watchpoints/watchpoint_commands/command/TestWatchpointCommandPython.py
-
commands/watchpoints/watchpoint_commands/condition/TestWatchpointConditionCmd.py
- commands/watchpoints/watchpoint_count/TestWatchpointCount.py
- commands/watchpoints/watchpoint_disable/TestWatchpointDisable.py
- commands/watchpoints/watchpoint_size/TestWatchpointSizes.py
- python_api/watchpoint/TestSetWatchpoint.py
- python_api/watchpoint/TestWatchpointIgnoreCount.py
- python_api/watchpoint/TestWatchpointIter.py
- python_api/watchpoint/condition/TestWatchpointConditionAPI.py
- python_api/watchpoint/watchlocation/TestTargetWatchAddress.py
---------
Co-authored-by: Jason Molenda <jmolenda@apple.com>
Create additional helper functions for the ValueObject class, for:
- returning the value as an APSInt or APFloat
- additional type casting options
- additional ways to create ValueObjects from various types of data
- dereferencing a ValueObject
These helper functions are needed for implementing the Data Inspection
Language, described in
https://discourse.llvm.org/t/rfc-data-inspection-language/69893
…ARFDIE
This puts them closer to the other two functions doing something very
similar. I've tried to stick to the original logic of the functions as
much as possible, though I did apply some easy simplifications.
The changes in DWARFDeclContext.h are there to make the unit tests
produce more useful error messages.
This is an attempt at displaying the work that's being done by LLDB when waiting on type-completion events, e.g., when running an expression. This patch adds a single new progress event for cases where we search for the definition DIE of a forward declaration, which can be an expensive operation in the presence of many object files.
This patch moves some of the `is_cxx_method`/`objc_method` logic out of
`DWARFASTParserClang::ParseSubroutine` into their own functions. Mainly
the purpose of this is to (hopefully) make this function more readable
by turning the deeply nested if-statements into early-returns. This will
be useful in an upcoming change where we remove some of the branches of
said if-statement.
Considerations:
* Would be nice to make them into static helpers in
`DWARFASTParserClang.cpp`. That would require them take few more
arguments which seemed to get unwieldy.
* `HandleCXXMethod` can return three states: (1) found a `TypeSP` we
previously parsed (2) successfully set a link between the DIE and
DeclContext (3) failure. One could express this with
`std::optional<TypeSP>`, but then returning `std::nullopt` vs `nullptr`
becomes hard to reason about. So I opted to return `std::pair<bool,
TypeSP>`, where the `bool` indicates success and the `TypeSP` the cached
type.
* `HandleCXXMethod` takes `ignore_containing_context` as an output
parameter. Haven't found a great way to do this differently
The function that calculated the declaration context for a DIE was incorrectly transparently traversing acrosss DW_TAG_subprogram dies when climbing the parent DIE chain. This meant that types defined in functions would appear to have the declaration context of anything above the function. I fixed the GetTypeLookupContextImpl(...) function in DWARFDIE.cpp to not transparently skip over functions, lexical blocks and inlined functions and compile and type units. Added a test to verify things are working.
`GetDeclContextDIEs` and `DIEDeclContextsMatch` are unused (possibly
since we added support for simplified template names, but I haven't
checked). `GetDeclContextDIEs` is also very similar (but subtly
different) from `GetDeclContext` and `GetTypeLookupContext`.
I am keeping `GetParentDeclContextDIE` as that one still has some
callers, but I want to look into the possibility of merging it with at
least one of the functions mentioned above.
This makes sure we try to process declaration DIEs that are erroneously
present in the index. Until bd5c6367bd, clang was emitting index
entries for declaration DIEs with DW_AT_signature attributes. This makes
sure to avoid returning those DIEs as the definitions of a type, but
also makes sure to pass through DIEs referring to static constexpr
member variables, which is a (probably nonconforming) extension used by
dsymutil.
It adds test cases for both of the scenarios. It is essentially a
recommit of #91808.
Add comments and a test for delay-init libraries on macOS. I originally
added the support in 954d00e87c a month
ago, but without these additional clarifications.
rdar://126885033
This patch tightens the assert check for the ABISP object in
`StopInfoMachException::DeterminePtrauthFailure`.
This causes some failure when debugging on a system that doesn't have
pointer authentification support, like on Intel for instance.
rdar://129401926
Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>
This issue is reported by cppcheck as a pointless test in the watch mask
check. The `else if` condition is opposite to the previous `if`
condition, making the expression always true.
Caught by cppcheck -
lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm.cpp:509:25:
style: Expression is always true because 'else if' condition is opposite
to previous condition at line 505. [multiCondition]
Fix#91223
The `else if` condition for checking `m_compression_type` is redundant
as it matches with a previous `if` condition, making the expression
always false. Reported by cppcheck as a possible cut-and-paste error.
Caught by cppcheck -
lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunication.cpp:543:35:
style: Expression is always false because 'else if' condition matches
previous condition at line 535. [multiCondition]
Fix#91222
Cppcheck recommends using a const reference for range variables in a
for-each loop.
This avoids unnecessary copying of elements, improving performance.
Caught by cppcheck -
lldb/source/API/SBBreakpoint.cpp:717:22: performance: Range variable
'name' should be declared as const reference. [iterateByValue]
lldb/source/API/SBTarget.cpp:1150:15: performance: Range variable 'name'
should be declared as const reference. [iterateByValue]
lldb/source/Breakpoint/Breakpoint.cpp:888:26: performance: Range
variable 'name' should be declared as const reference. [iterateByValue]
lldb/source/Breakpoint/BreakpointIDList.cpp:262:26: performance: Range
variable 'name' should be declared as const reference. [iterateByValue]
Fix#91213Fix#91217Fix#91219Fix#91220
This is useful if you have a transcript of a user session and want to
rerun those commands with RunCommandInterpreter. The same functionality
is also useful in testing.
I'm adding it primarily for the second reason. In a subsequent patch,
I'm adding the ability to Python based commands to provide their
"auto-repeat" command. Among other things, that will allow potentially
state destroying user commands to prevent auto-repeat. Testing this with
Shell or pexpect tests is not nearly as accurate or convenient as using
RunCommandInterpreter, but to use that I need to allow auto-repeat.
I think for consistency's sake, having interactive sessions always do
auto-repeats is the right choice, though that's a lightly held
opinion...
This PR extends Dwarf.def to include the number of operands and the arity (the
number of entries on the DWARF stack).
- The arity is used in LLDB's DWARF expression evaluator.
- The number of operands is unused, but is present in the table to avoid
confusing the arity with the operands. Keeping the latter up to date should
be straightforward as it maps directly to a table present in the DWARF
standard.
Re-apply https://github.com/llvm/llvm-project/pull/87550 with fixes.
Details:
Some tests in fuchsia failed because of the newly added assertion.
This was because `GetExceptionBreakpoint()` could be called before
`g_dap.debugger` was initted.
The fix here is to just lazily populate the list in
GetExceptionBreakpoint() rather than assuming it's already been initted.
(There is some nuisance here because we can't simply just populate it in
DAP::DAP(), which is a global ctor and is called before
`SBDebugger::Initialize()` is called. )
The the function is doing two fairly different things, depending on how
it is called. While this allows for some code reuse, it also makes it
hard to override it correctly. Possibly for this reason
ValueObjectSynthetic overerides GetChildAtIndex instead, which forces it
to reimplement some of its functionality, most notably caching of
generated children.
Splitting this up makes it easier to move the caching to a common place
(and hopefully makes the code easier to follow in general).
The summary already includes other size information, e.g. total debug
info size in bytes. The only other way I can get this information is by
dumping all statistics which can be quite large. Adding it to the
summary seems fair.
and two follow-up commits. The reason is the crash we've discovered when
processing -gsimple-template-names binaries. I'm committing a minimal
reproducer as a separate patch.
This reverts the following commits:
- 51dd4eaaa2 (#92328)
- 3d9d485239 (#93839)
- afe6ab7586 (#94400)
This patch make all errors start with a lowercase letter and removes
trailing periods and newlines. This fixes inconsistencies between error
messages and facilitate concatenating them.
UpdateFormatsIfNeeded has hardcoded the call to GetFormat with no
dynamic values. GetFormat will try to find the synthetic children of the
ValueObject, and passing the wrong one can fail, which can be bad for
performance but should not be user visible. Fix the performace bug by
passing the dynamic value type of the ValueObject.
rdar://122506593
Change the signature of `DWARFExpression::Evaluate` and
`DWARFExpressionList::Evaluate` to return an `llvm::Expected` instead of a
boolean. This eliminates the `Status` output parameter and generally improves
error handling.
The PR adds the support of CoreDump debugging for RISC-V 64. It
implements new `RegisterContextCorePOSIX_riscv64` class.
Also, the contribution fixes `GetRegisterCount()` ->
`GetRegisterSetCount()` misprint in
`RegisterContextPOSIX_riscv64::GetRegisterSetCount()` method, which
leaded to `set && "Register set should be valid."` assertion during
`register info aX` command call.
The patch was tested (on coredumps generated for simple Integer/FP
calculation code) for _cross x86_64 -> RISCV_ and _native RISCV_ LLDB
builds. There were performed basic LLDB functionality tests, such as:
- CoreDump file load
- Backtrace / frames
- GP/FP registers read/info/list
- Basic switch between threads
- Disassembler code
- Memory regions read / display
This is a follow-up of
https://github.com/llvm/llvm-project/pull/92328#issuecomment-2145849441
Clang attaches `DW_AT_declaration` to static inline data members and
`dsymutil` indexes these constants. Skipping these caused the expression
evaluator to fail to find such constants when using DWARFv5.
Fixes `TestConstStaticIntegralMember.py` on DWARFv5.
Very minor change to help message on `process save-core`. Adds space
between two sentences explaining the `-p` option:
"Specify a plugin name to create the core file.This allows core files to
be saved in different formats."
-->
"Specify a plugin name to create the core file. This allows core files
to be saved in different formats."
Before:
```
(lldb) help process save-core
Save the current process as a core file using an appropriate file type.
Syntax: process save-core [-s corefile-style -p plugin-name] FILE
Command Options Usage:
process save-core [-p[<plugin>]] [-s <corefile-style>] <path>
-p[<plugin>] ( --plugin-name=[<plugin>] )
Specify a plugin name to create the core file.This allows core files to be saved in different formats.
-s <corefile-style> ( --style <corefile-style> )
Request a specific style of corefile to be saved.
Values: full | modified-memory | stack
This command takes options and free-form arguments. If your arguments resemble option specifiers (i.e., they start with a -
or --), you must use ' -- ' between the end of the command options and the beginning of the arguments.
```
After:
```
michristensen@devbig356 build/Debug » $HOME/llvm-sand/build/Debug/bin/lldb -x
(lldb) help process save-core
Save the current process as a core file using an appropriate file type.
Syntax: process save-core [-s corefile-style -p plugin-name] FILE
Command Options Usage:
process save-core [-p[<plugin>]] [-s <corefile-style>] <path>
-p[<plugin>] ( --plugin-name=[<plugin>] )
Specify a plugin name to create the core file. This allows core files to be saved in different formats.
-s <corefile-style> ( --style <corefile-style> )
Request a specific style of corefile to be saved.
Values: full | modified-memory | stack
This command takes options and free-form arguments. If your arguments resemble option specifiers (i.e., they start with a -
or --), you must use ' -- ' between the end of the command options and the beginning of the arguments.
```
