The purpose of m_being_created in these classes was to prevent
broadcasting an event related to these Breakpoints during the creation
of the breakpoint (i.e. in the constructor). In Breakpoint and
Watchpoint, m_being_created had no effect. That is to say, removing it
does not change behavior.
However, BreakpointLocation does still use m_being_created. In the
constructor, SetThreadID is called which does broadcast an event only if
`m_being_created` is false. Instead of having this logic be roundabout,
the constructor instead calls `SetThreadIDInternal`, which actually
changes the thread ID. `SetThreadID` also will call
`SetThreadIDInternal` in addition to broadcasting a changed event.
This patch is the next piece of work in my Large Watchpoint proposal,
https://discourse.llvm.org/t/rfc-large-watchpoint-support-in-lldb/72116
This patch breaks a user's watchpoint into one or more
WatchpointResources which reflect what the hardware registers can cover.
This means we can watch objects larger than 8 bytes, and we can watched
unaligned address ranges. On a typical 64-bit target with 4 watchpoint
registers you can watch 32 bytes of memory if the start address is
doubleword aligned.
Additionally, if the remote stub implements AArch64 MASK style
watchpoints (e.g. debugserver on Darwin), we can watch any power-of-2
size region of memory up to 2GB, aligned to that same size.
I updated the Watchpoint constructor and CommandObjectWatchpoint to
create a CompilerType of Array<UInt8> when the size of the watched
region is greater than pointer-size and we don't have a variable type to
use. For pointer-size and smaller, we can display the watched granule as
an integer value; for larger-than-pointer-size we will display as an
array of bytes.
I have `watchpoint list` now print the WatchpointResources used to
implement the watchpoint.
I added a WatchpointAlgorithm class which has a top-level static method
that takes an enum flag mask WatchpointHardwareFeature and a user
address and size, and returns a vector of WatchpointResources covering
the request. It does not take into account the number of watchpoint
registers the target has, or the number still available for use. Right
now there is only one algorithm, which monitors power-of-2 regions of
memory. For up to pointer-size, this is what Intel hardware supports.
AArch64 Byte Address Select watchpoints can watch any number of
contiguous bytes in a pointer-size memory granule, that is not currently
supported so if you ask to watch bytes 3-5, the algorithm will watch the
entire doubleword (8 bytes). The newly default "modify" style means we
will silently ignore modifications to bytes outside the watched range.
I've temporarily skipped TestLargeWatchpoint.py for all targets. It was
only run on Darwin when using the in-tree debugserver, which was a proxy
for "debugserver supports MASK watchpoints". I'll be adding the
aforementioned feature flag from the stub and enabling full mask
watchpoints when a debugserver with that feature is enabled, and
re-enable this test.
I added a new TestUnalignedLargeWatchpoint.py which only has one test
but it's a great one, watching a 22-byte range that is unaligned and
requires four 8-byte watchpoints to cover.
I also added a unit test, WatchpointAlgorithmsTests, which has a number
of simple tests against WatchpointAlgorithms::PowerOf2Watchpoints. I
think there's interesting possible different approaches to how we cover
these; I note in the unit test that a user requesting a watch on address
0x12e0 of 120 bytes will be covered by two watchpoints today, a
128-bytes at 0x1280 and at 0x1300. But it could be done with a 16-byte
watchpoint at 0x12e0 and a 128-byte at 0x1300, which would have fewer
false positives/private stops. As we try refining this one, it's helpful
to have a collection of tests to make sure things don't regress.
I tested this on arm64 macOS, (genuine) x86_64 macOS, and AArch64
Ubuntu. I have not modifed the Windows process plugins yet, I might try
that as a standalone patch, I'd be making the change blind, but the
necessary changes (see ProcessGDBRemote::EnableWatchpoint) are pretty
small so it might be obvious enough that I can change it and see what
the Windows CI thinks.
There isn't yet a packet (or a qSupported feature query) for the gdb
remote serial protocol stub to communicate its watchpoint capabilities
to lldb. I'll be doing that in a patch right after this is landed,
having debugserver advertise its capability of AArch64 MASK watchpoints,
and have ProcessGDBRemote add eWatchpointHardwareArmMASK to
WatchpointAlgorithms so we can watch larger than 32-byte requests on
Darwin.
I haven't yet tackled WatchpointResource *sharing* by multiple
Watchpoints. This is all part of the goal, especially when we may be
watching a larger memory range than the user requested, if they then add
another watchpoint next to their first request, it may be covered by the
same WatchpointResource (hardware watchpoint register). Also one "read"
watchpoint and one "write" watchpoint on the same memory granule need to
be handled, making the WatchpointResource cover all requests.
As WatchpointResources aren't shared among multiple Watchpoints yet,
there's no handling of running the conditions/commands/etc on multiple
Watchpoints when their shared WatchpointResource is hit. The goal beyond
"large watchpoint" is to unify (much more) the Watchpoint and Breakpoint
behavior and commands. I have a feeling I may be slowly chipping away at
this for a while.
rdar://108234227
This avoids duplicating the logic to get the first
element of a libc++ `__compressed_pair`. This will
be useful in supporting upcoming changes to the layout
of `__compressed_pair`.
Drive-by changes:
* Renamed `m_item` to `size_node` for readability;
`m_item` suggests it's a member variable, which it
is not.
The `total` parameter for the constructor for Progress was changed to a
std::optional in https://github.com/llvm/llvm-project/pull/77547. It was originally set to 1 to indicate non-determinisitic progress, but this commit changes this. First, `UINT64_MAX` will again be used for non-deterministic progress, and `Progress` now has a static variable set to this value so that we can use this instead of a magic number.
The member variable `m_total` could be changed to a std::optional as
well, but this means that the `ProgressEventData::GetTotal()` (which is
used for the public API) would
either need to return a std::optional value or it would return some
specific integer to represent non-deterministic progress if `m_total` is
std::nullopt.
Temporarily revert to unblock the CI bots, this is breaking the -DLLVM_ENABLE_MODULES=On
modules style build. I've notified Ismail.
This reverts commit 888501bc631c4f6d373b4081ff6c504a1ce4a682.
This patch makes ScriptedThreadPlan conforming to the ScriptedInterface
& ScriptedPythonInterface facilities by introducing 2
ScriptedThreadPlanInterface & ScriptedThreadPlanPythonInterface classes.
This allows us to get rid of every ScriptedThreadPlan-specific SWIG
method and re-use the same affordances as other scripting offordances,
like Scripted{Process,Thread,Platform} & OperatingSystem.
To do so, this adds new transformer methods for `ThreadPlan`, `Stream` &
`Event`, to allow the bijection between C++ objects and their python
counterparts.
Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>
This fixes two issues related to the DebugSymbols symbol locator:
1. Only the default symbol locator plugin reports progress. On Darwin,
which uses the DebugSymbols framework we need to report the same
progress form the corresponding SymbolLocator plugin.
2. Forceful dSYM lookups, for example when using `add-dsym`, use a
different code path that currently does not report progress, which is
confusing. Here the progress event can be more specific and specify its
downloading a symbol file rather than just locating it as we'll always
shell out to dsymForUUID or its equivalent.
rdar://121629777
The `(( )?&)?` appears to match types which are references. However lldb
can load the
correct data formatters without having to pattern match against a `&`
suffix.
The suffix may have been needed at one point, but it's no longer needed.
There are 3 ways to create an EventDataBytes object: (const char *),
(llvm::StringRef), and (const void *, size_t len). All of these cases
can be handled under `llvm::StringRef`. Additionally, this allows us to
remove the otherwise unused `SetBytes`, `SwapBytes`, and
`SetBytesFromCString` methods.
`FindBreakpointID` take a BreakpointID and a pointer to a size_t (so you
can get position information). It returns a bool to indicate whether the
id was found in the list or not.
There are 2 callers of this currently and neither one actually uses the
position information, so I removed it. After that, I renamed it to
Contains to more accurately reflect the intent. Additionally, I changed
the argument type from a reference to a value (because BreakpointID is
just a wrapper around 2 integers, copies are cheap).
clang's -Wdtor name is correct, but the standard may have not
intended that meaning, according to https://bugs.llvm.org/show_bug.cgi?id=46979#c1.
Some of the wording may have changed in 20/23, but we of course
need to support c++17 as well as that's our default.
One workaround would be to explicitly open the namespaces,
then declare the destructor inside that.
Another as shown in the bug report is to repeat the class name, without
the template arguments, before the ::~. For example `Bar::Foo<T>::Foo::~Foo`.
(this extra Foo is the injected class name
https://en.cppreference.com/w/cpp/language/injected-class-name)
I chose to do this because it's the smallest change. It works
with gcc-13 and clang in c++17 and 20 modes (https://godbolt.org/z/fqs4fGE7T).
This reverts commit 5e9f0e37494ab42ff8d850527c5517f3006e63e9
because it creates a new warning from clang:
```
NSDictionary.cpp:1063:14: warning: ISO C++ requires the name after '::~' to be found in the same scope as the name before '::~' [-Wdtor-name]
D32, D64>::~GenericNSDictionaryMSyntheticFrontEnd() {
~~~~~~~~~^~
::GenericNSDictionaryMSyntheticFrontEnd
```
If you remove the template arguments from before the `::`, you
then get:
```
NSDictionary.cpp:1062:27: error: use of class template 'lldb_private::formatters::GenericNSDictionaryMSyntheticFrontEnd' requires template arguments
lldb_private::formatters::GenericNSDictionaryMSyntheticFrontEnd::~GenericNSDictionaryMSyntheticFrontEnd() {
^
```
And I'm not aware of a way to fix that.
When compiling with gcc 11+ and -DCMAKE_CXX_STANDARD=20, errors
like the following happened:
```
llvm-project/lldb/source/Plugins/Language/ObjC/NSDictionary.cpp:1063:5: error: template-id not allowed for destructor
1063 | ~GenericNSDictionaryMSyntheticFrontEnd<D32,D64>() {
| ^
```
This appears to be something only gcc enforces and only from 11 and beyond.
This changes fixes all the instances of this pattern by removing the
template arguments.
This patch fixes:
lldb/source/Plugins/Language/CPlusPlus/LibCxx.cpp:1108:39: error:
format specifies type 'long long' but the argument has type
'std::time_t' (aka 'long') [-Werror,-Wformat]
lldb/source/Plugins/Language/CPlusPlus/LibCxx.cpp:1116:64: error:
format specifies type 'long long' but the argument has type
'std::time_t' (aka 'long') [-Werror,-Wformat]
This fixes:
```
[6331/7452] Building CXX object tools\lldb\source\Plugins\Language\CPlusPlus\CMakeFiles\lldbPluginCPlusPlusLanguage.dir\LibCxx.cpp.obj
C:\git\llvm-project\lldb\source\Plugins\Language\CPlusPlus\LibCxx.cpp(1108,38): warning: format specifies type 'long' but the argument has type 'std::time_t' (aka 'long long') [-Wformat]
1108 | stream.Printf("timestamp=%ld s", seconds);
| ~~~ ^~~~~~~
| %lld
C:\git\llvm-project\lldb\source\Plugins\Language\CPlusPlus\LibCxx.cpp(1116,63): warning: format specifies type 'long' but the argument has type 'std::time_t' (aka 'long long') [-Wformat]
1116 | stream.Printf("date/time=%s timestamp=%ld s", str.data(), seconds);
| ~~~ ^~~~~~~
| %lld
2 warnings generated.
```
I originally thought to try to guesstimate the hardware watchpoint index
number that a Resource was associated with, but gdb remote serial
protocol doesn't give us the hardware register index used so it was only
a guess. I changed my mind and simply use ever-incrementing ID numbers
for the WatchpointResources, but forgot to remove the SetID method.
In `[lldb] [mostly NFC] Large WP foundation: WatchpointResources
(#68845)` I added a new template StopPointSiteList to combine
WatchpointResourceList and BreakpointSiteList. But I didn't remove the
now-unused WatchpointResourceList class. This patch fixes that.
This reverts commit d657519838e4b2310e13ec5ff52599e041860825 as it
breaks two dozen tests. The breakages are related to variable path
expression parsing and summary string parsing (possibly the same code).
As I worked through changes to another PR
(https://github.com/llvm/llvm-project/pull/74912), I couldn't help but
rewrite a few methods for readability, maintainability, and possibly
some behavior correctness too.
1. Exiting early instead of nested `if`-statements, which:
- Reduces indentation levels for all subsequent lines
- Treats missing pre-conditions similar to an error
- Clearly indicates that the full length of the method is the "happy
path".
2. Explicitly return empty Value Object shared pointers for those error
(like) situations, which
- Reduces the time it takes a maintainer to figure out what the method
actually returns based on those conditions.
3. Converting a mix of `if` and `if`-`else`-statements around an enum
into one `switch` statement, which:
- Consolidates the former branching logic
- Lets the compiler warn you of a (future) missing enum case
- This one may actually change behavior slightly, because what was an
early test for one enum case, now happens later on in the `switch`.
4. Consolidating near-identical, "copy-pasta" logic into one place,
which:
- Separates the common code to the diverging paths.
- Highlights the differences between the code paths.
rdar://119833526
I've been working on more/better configuration for improving DEBUGINFOD
support. This is the first (and easiest) slice of the work.
I've added `timeout` and `cache-path` settings that can override the
DEBUGINFOD library defaults (and environment variables.) I also renamed
the `plugin.symbol-locator.debuginfod.server_urls` setting to
`server-urls` to be more consistent with the rest of LLDB's settings
(the underscore switch is switched to a hyphen)
I've got a few tests that validate the cache-path setting (as a
side-effect), but they've exposed a few bugs that I'll be putting up a
separate PR for (which will include the tests).
---------
Co-authored-by: Kevin Frei <freik@meta.com>
BroadcastEvent currently takes its EventData* param and shoves it into
an Event object, which takes ownership of the pointer and places it into
a shared_ptr to manage the lifetime.
Instead of relying on `new` and passing raw pointers around, I think it
would make more sense to create the shared_ptr up front.
Follow-up to #69422.
This PR puts all the highlighting settings into a single struct for
easier handling
Co-authored-by: Talha Tahir <talha.tahir@10xengineers.ai>
Previously committed as 9e08e51a20d0d2b1c5724bb17e969d036fced4cd, and
reverted because a dependency commit was reverted, then committed again
as 4b574008aef5a7235c1f894ab065fe300d26e786 and reverted again because
"dependency commit" 5a391d38ac6c561ba908334d427f26124ed9132e was
reverted. But it doesn't seem that 5a391d38ac6c was a real dependency
for this.
This commit incorporates 4b574008aef5a7235c1f894ab065fe300d26e786 and
18e093faf726d15f210ab4917142beec51848258 by Richard Smith (@zygoloid),
with some minor fixes, most notably:
- `UncommonValue` renamed to `StructuralValue`
- `VK_PRValue` instead of `VK_RValue` as default kind in lvalue and
member pointer handling branch in
`BuildExpressionFromNonTypeTemplateArgumentValue`;
- handling of `StructuralValue` in `IsTypeDeclaredInsideVisitor`;
- filling in `SugaredConverted` along with `CanonicalConverted`
parameter in `Sema::CheckTemplateArgument`;
- minor cleanup in
`TemplateInstantiator::transformNonTypeTemplateParmRef`;
- `TemplateArgument` constructors refactored;
- `ODRHash` calculation for `UncommonValue`;
- USR generation for `UncommonValue`;
- more correct MS compatibility mangling algorithm (tested on MSVC ver.
19.35; toolset ver. 143);
- IR emitting fixed on using a subobject as a template argument when the
corresponding template parameter is used in an lvalue context;
- `noundef` attribute and opaque pointers in `template-arguments` test;
- analysis for C++17 mode is turned off for templates in
`warn-bool-conversion` test; in C++17 and C++20 mode, array reference
used as a template argument of pointer type produces template argument
of UncommonValue type, and
`BuildExpressionFromNonTypeTemplateArgumentValue` makes
`OpaqueValueExpr` for it, and `DiagnoseAlwaysNonNullPointer` cannot see
through it; despite of "These cases should not warn" comment, I'm not
sure about correct behavior; I'd expect a suggestion to replace `if` by
`if constexpr`;
- `temp.arg.nontype/p1.cpp` and `dr18xx.cpp` tests fixed.
PlatformDarwinKernel::GetSharedModule, which can find a kernel or kext
from a local filesystem scan, needed a little cleanup. The method which
finds kernels was (1) not looking for the SymbolFileSpec when creating a
Module, and (2) adding that newly created Module to a Target, which
GetSharedModule should not be doing - after auditing many other subclass
implementations of this method, I haven't found any others doing it.
Platform::GetSharedModule didn't have a headerdoc so it took a little
work to piece together the intended behaviors.
This is addressing a bug where
PlatformDarwinKernel::GetSharedModuleKernel would find the ObjectFile
for a kernel, create a Module, and add it to the Target. Then up in
DynamicLoaderDarwinKernel, it would check if the Module had a SymbolFile
FileSpec, and because it did not, it would do its own search for a
binary & dSYM, find them, and then add that to the Target. Now we have
two copies of the Module in the Target, one with a dSYM and the other
without, and only one of them has its load addresses set.
GetSharedModule should not be adding binaries to the Target, and it
should set the SymbolFile FileSpec when it is creating the Module.
rdar://120895951
The lifetime of these BreakpointEventData objects is difficult to reason
about. These BreakpointEventData pointers are created and passed along
to `Event` which takes the raw pointer and sticks them in a shared
pointer. Instead of manually managing the lifetime and memory, it would
be simpler to have them be shared pointers from the start.
For example, the following message has the severity string "error: "
twice.
> "error: <EXPR>:3:1: error: cannot find 'bogus' in scope
This method already appends the severity string in the beginning, but
with this fix, it also removes a secondary instance, if applicable.
Note that this change only removes the *first* redundant substring. I
considered putting the removal logic in a loop, but I decided that if
something is generating more than one redundant severity substring, then
that's a problem the message's source should probably fix.
rdar://114203423
Fixes:
```
[3465/3822] Building CXX object tools\lldb\source\Plugins\SymbolFile\CTF\CMakeFiles\lldbPluginSymbolFileCTF.dir\SymbolFileCTF.cpp.obj
C:\git\llvm-project\lldb\source\Plugins\SymbolFile\CTF\SymbolFileCTF.cpp(606) : warning C4715: 'lldb_private::SymbolFileCTF::CreateType': not all control paths return a value
```
This fixes missing inlined function names when formatting frame and the
`Block` in `SymbolContext` is a lexical block (e.g.
`DW_TAG_lexical_block` in Dwarf).
The TLS implementation on apple platforms has changed. Instead of
invoking pthread_getspecific with a pthread_key_t, we instead perform a
virtual function call.
Note: Some versions of Apple's new linker do not emit debug symbols for
TLS symbols. This causes the TLS tests to fail because LLDB and dsymutil
expects there to be debug symbols to resolve the relevant TLS block. You
may work around this by switching to the older linker (ld-classic) or by
disabling the TLS tests until you have a newer version of the new
linker.
rdar://120676969
This fixes:
```
[6083/7449] Building CXX object tools\lldb\source\Commands\CMakeFiles\lldbCommands.dir\CommandObjectFrame.cpp.obj
C:\git\llvm-project\lldb\source\Commands\CommandObjectFrame.cpp(497) : warning C4715: 'CommandObjectFrameVariable::ScopeRequested': not all control paths return a value
```
