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
The previous logic for determining if an expression was a command or
variable expression in the repl would incorrectly identify the context
in many common cases where a local variable name partially overlaps with
the repl input.
For example:
```
int foo() {
int var = 1; // break point, evaluating "p var", previously emitted a warning
}
```
Instead of checking potentially multiple conflicting values against the
expression input, I updated the heuristic to only consider the first
term. This is much more reliable at eliminating false positives when the
input does not actually hide a local variable.
Additionally, I updated the warning on conflicts to occur anytime the
conflict is detected since the specific conflict can change based on the
current input. This also includes additional details on how users can
change the behavior.
Example Debug Console output from
lldb/test/API/tools/lldb-dap/evaluate/main.cpp:11 breakpoint 3.
```
lldb-dap> var + 3
Warning: Expression 'var' is both an LLDB command and variable. It will be evaluated as a variable. To evaluate the expression as an LLDB command, use '`' as a prefix.
45
lldb-dap> var + 1
Warning: Expression 'var' is both an LLDB command and variable. It will be evaluated as a variable. To evaluate the expression as an LLDB command, use '`' as a prefix.
43
```
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
```
ELF does not have a hard distinction between shared libraries (and
position-independent) executables. It is possible to create a shared
library that will also be executable.
In https://reviews.llvm.org/D151292 I added the ability to track address
masks separately for high and low memory addresses, a capability of
AArch64. I did my testing with manual address mask settings (via
target.process.highmem-virtual-addressable-bits) but didn't have a real
corefile that included this metadata and required it.
My intention is that when the high address mask isn't specified, by the
user (via the setting) or the Process plugin, we fall back to using the
low address mask. The low and high address mask is the same for almost
all environments.
But the patch I wrote never uses the Process plugin high address mask if
it was set, e.g. from corefile metadata. This patch corrects that.
I also have an old patch in Phabractor that was approved to add
FixAddress methods to SBProcess; I need to pick that patch up and finish
it (I wanted to add an enum to specify which mask is being requested
iirc), so I can do address masks tests in API tests.
rdar://120926000
I have my editor configured to remove trailing whitespace and every time
I touch this file I end up with a bunch of clang-format changes to lines
that were modified because of it. Nobody likes trailing whitespace so
this cleans up the file.
Store a SupportFile, rather than a FileSpec, in CompileUnit. This commit
works towards having the SourceManager operate on SupportFiles so that
it can (1) validate the Checksum and (2) materialize the content of
inline source information.
Store a SupportFile, rather than a FileSpec, in LineEntry. This commit
works towards having the SourceManageroperate on SupportFiles so that it
can (1) validate the Checksum and (2) materialize the content of inline
source information.
We claim in a couple places that the zeroth element of the module list
for a target is the main executable, but we don't actually enforce that
in the ModuleList class. As we saw, for instance, in
32dd5b2097
it's not all that hard to get this to be off. This patch ensures that
the first object file of type Executable added to it is moved to the
front of the ModuleList. I also added a test for this.
In the normal course of operation, where the executable is added first,
this only adds a check for whether the first element in the module list
is an executable. If that's true, we just append as normal.
Note, the code in Target::GetExecutableModule doesn't actually agree
that the zeroth element must be the executable, it instead returns the
first Module of type Executable. But I can't tell whether that was a
change in intention or just working around the bug that we don't always
maintain this ordering. But given we've said this in scripting as well
as internally, I think we shouldn't change our minds about this.
This is a speculative fix for TestRosetta.py which is currently failing
on Green Dragon.
TestRosetta just makes sure we can debug an x86_64 process on Apple
Silicon. However, we're failing to build the x86_64 test binary. The
linker is failing with some warnings about libc++ and libunwind being
build for arm64 while the target binary is x86_64. I'm going to try
building with the system standard libraries instead of the just-built
ones to workaround it.
The test TestTrimmedProgressReporting tests that progress reports are
being sent by listening for events with the titles of specific progress
reports. Commit f1ef910b removed the report for Apple DWARF indices
which was one of the reports being listened for in this test, so that
report is removed here as well.
That commit also now creates all progress reports with details so
reports string are prepended with the details count. This changes the
length of the trimmed progress report title string that's checked for
here so this commit changes the string to match as well.
This test was skipped on non-Apple platforms, but since the progress
report for Apple DWARF indices has been removed this commit removes that
decorator.
With lldb build fix.
Original message:
EnumConstantDecl is allocated by the ASTContext allocator so the
destructor is never called.
This patch takes a similar approach to IntegerLiteral by using
APIntStorage to allocate large APSInts using the ASTContext allocator as
well.
The downside is that an additional heap allocation and copy of the data
needs to be made when calling getInitValue if the APSInt is large.
Fixes#78160.
There's a bad interaction between the macOS 14 dyld and the "dyld_sim"
shim that comes from older (iOS 15) simulator downloads that results in
dyld reporting some modules twice in the return from the dyld callback
to list modules. The records were identical, but lldb wasn't happy with
seeing the duplicates...
Since it's not possible to load two different modules at the same
address, this change just picks the first instance of any entries that
have the same load address.
There really isn't a good way to test this patch.
Per this RFC:
https://discourse.llvm.org/t/rfc-improve-lldb-progress-reporting/75717
on improving progress reports, this commit separates the title field and
details field so that the title specifies the category that the progress
report falls under. The details field is added as a part of the
constructor for progress reports and by default is an empty string. In addition, changes the total amount of progress completed into a std::optional. Also
updates the test to check for details being correctly reported from the
event structured data dictionary.
This allows release teams to customize the bug report url for lldb. It
also removes unnecessary constructions of
`llvm::PrettyStackTraceProgram` as it's already constructed inside
`llvm::InitLLVM`.
We only ever call this function once, without relying on the defaulted
`honor_array` parameter, so make it non-defaulted. Also `max_length` is
always set to `0`, so remove it entirely.
This simplifies some upcoming refactoring.
This is a followup of #76983 and adds the libc++ data formatters for
- weekday,
- weekday_indexed,
- weekday_last,
- month_weekday,
- month_weekday_last,
- year_month,
- year_month_day_last
- year_month_weekday, and
- year_month_weekday_last.
When generating a `display_value` for a variable the current approach
calls `SBValue::GetValue()` and `SBValue::GetSummary()` to generate a
`display_value` for the `SBValue`. However, there are cases where both
of these return an empty string and the fallback is to print a pointer
and type name instead (e.g. `FooBarType @ 0x00321`).
For swift types, lldb includes a langauge runtime plugin that can
generate a description of the object but this is only used with
`SBValue::GetDescription()`.
For example:
```
$ lldb swift-binary
... stop at breakpoint ...
lldb> script
>>> event = lldb.frame.GetValueForVariablePath("event")
>>> print("Value", event.GetValue())
Value None
>>> print("Summary", event.GetSummary())
Summary None
>>> print("Description", event) # __str__ calls SBValue::GetDescription()
Description (main.Event) event = (name = "Greetings", time = 2024-01-04 23:38:06 UTC)
```
With this change, if GetValue and GetSummary return empty then we try
`SBValue::GetDescription()` as a fallback before using the previous
logic of printing `<type> @ <addr>`.
BreakpointIDList does not need to know about CommandReturnObject.
BreakpointIDList::FindAndReplaceIDRanges is the last place that uses it
in BreakpointIDList.
Instead of passing in a CommandReturnObject, it now returns an
llvm::Error. The callsite uses the Error to populate the
CommandReturnObject as needed.
When I added the MD5 checksum I was on the fence between storing it in
FileSpec or creating a new SupportFile abstraction. The latter was
deemed overkill for just the MD5 hashes, but support for inline sources
in the DWARF 5 line table tipped the scales. This patch moves the MD5
checksum into the new SupportFile class.
There seems to be a regression since
6f8b33f6df.
`Max String Summary Length` target property is not read properly and the
default value (1024) is being used instead.
16.0.6:
```
(lldb) settings set target.max-string-summary-length 16
(lldb) var
(std::string) longStdString = "0123456789101112131415161718192021222324252627282930313233343536"
(const char *) longCharPointer = 0x000055555556f310 "0123456789101112131415161718192021222324252627282930313233343536"
```
17.0.4:
```
(lldb) settings set target.max-string-summary-length 16
(lldb) var
(std::string) longStdString = "0123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367368369370371372373374375376377"...
(const char *) longCharPointer = 0x000055555556f310 "*same as line above*"...
```
Comparison fails here:
9cb1673fa5/lldb/source/Interpreter/OptionValue.cpp (L256)
Due to the type difference:
9cb1673fa5/lldb/source/Target/Target.cpp (L4611)9cb1673fa5/lldb/source/Target/TargetProperties.td (L98)
This change just adds a `bool colors` parameter to the `StreamString`
class's constructor, which it passes up to its superclass’s constructor.
I'm working on another patch that prints out error messages using a
`StreamString` but I wasn't getting colorized text because of this
missing implementation detail.
rdar://120671168
The "kern ver str" LC_NOTE gives lldb a kernel version string -- with a
UUID and/or a load address (stext) to load it at. The LC_NOTE specifies
a size of the identifier string in bytes. In
ObjectFileMachO::GetIdentifierString, I copy that number of bytes into a
std::string, and in case there were additional nul characters at the end
of the sting for padding reasons, I tried to shrink the std::string to
not include these extra nul's.
However, I did this resizing without handling the case of an empty
identifier string. I don't know why any corefile creator would do that,
but of course at least one does. This patch removes the resizing
altogether; I was solving something that hasn't ever shown to be a
problem. I also added a test case for this, to check that lldb doesn't
crash when given one of these corefiles.
rdar://120390199
The main motivations behind this are two:
- Allow different companies developing their own vscode extensions for
LLDB to have a single contribution point, thus sharing resources and
working as a virtual large team.
- Allow for visual ways to configure the debugger, which currently has
to be done through launch.json files.
In terms of implementation, this is very straightforward and these are
the most important details:
- All the cpp code has been moved to a subfolder for cleanness. There's
a specific commit in the list of commits of this PR that just does that,
in case that helps reviewing this.
- A new folder `src-ts` has been created for the typescript code
- The ts extension can be used in two ways: as a regular vscode
extension and as a library. There file `extension.ts` explains which
entry point to use.
- The README has been updated the mention how to install the extension,
which is simpler than before. There are two additional sections for
rebuilding and formatting.
- The ts code I added merely sets up the debug adapter using two
possible options: reading the lldb-dap path from vscode settings or from
a config object passed by users of the extension is used as a library. I
did this to show how we can support easily both worlds.
This patch fixes:
lldb/source/Target/ProcessTrace.cpp:23:33: error: extra ';' outside
of a function is incompatible with C++98
[-Werror,-Wc++98-compat-extra-semi]
…ntext
Following the specification chain seems to be clearly the expected
behavior of GetDeclContext(). Otherwise C++ methods have an empty
CompilerContext instead of being nested in their struct/class.
Theprimary motivation for this functionality is the Swift plugin. In
order to test the change I added a proof-of-concept implementation of a
Module::FindFunction() variant that takes a CompilerContext, expesed via
lldb-test.
rdar://120553412
This adds a subset of the C++20 calendar data formatters:
- day,
- month,
- year,
- month_day,
- month_day_last, and
- year_month_day.
A followup patch will add the missing calendar data formatters:
- weekday,
- weekday_indexed,
- weekday_last,
- month_weekday,
- month_weekday_last,
- year_month,
- year_month_day_last
- year_month_weekday, and
- year_month_weekday_last.
This is required for users of `TypeQuery` that limit the set of
languages of the query using APIs such as
`GetSupportedLanguagesForTypes` or
`GetSupportedLanguagesForExpressions`.
Example usage: https://github.com/apple/llvm-project/pull/7885
AddName gives no feedback other than if it succeeded whereas
AddNameWithErrorHandling gives you back an SBError object. I would like
to mark AddName as deprecated and direct folks to use
AddNameWithErorrHandling instead.
---------
Co-authored-by: Med Ismail Bennani <ismail@bennani.ma>
There are 2 motivations here:
1.) There is no need to hand out constant references to BreakpointIDs,
they are only 8 bytes big. In addition, every use of this method already
makes a copy anyway.
2.) Each BreakpointIDList held onto an invalid BreakpointID specifically
to
prevent lifetime issues. Returning a value means you can return an
invalid BreakpointID instead of needing to allocate storage for an
invalid BreakpointID.
This abstraction is leaky and BreakpointIDList does not need to know
about CommandReturnObject.
Additionally, setting the CommandReturnObject inout param to a success
state does very little. The function returns immediately if the input
ArrayRef is empty, and reading
CommandObjectMultiwordBreakpoint::VerifyIDs more closely, the input is
always empty if the previous call to
BreakpointIDList::FindAndReplaceIDRanges failed. If the call was
successful, then the CommandReturnObject is already in a success state.
I have opted to remove the function altogether and inline the
functionality where it was used.
This moves the functionally of finding a DIE based on a fully qualified
name from SymbolFileDWARF into DWARFIndex itself, so that
specializations of DWARFIndex can implement faster versions of this
query.
With DWARFv5, C++ static data members are represented as
`DW_TAG_variable`s (see `faa3a5ea9ae481da757dab1c95c589e2d5645982`).
In GetClangDeclForDIE, when trying to parse the `DW_AT_specification`
that a static data member's CU-level `DW_TAG_variable` points to, we
would try to `CreateVariableDeclaration`. Whereas previously it was a
no-op (for `DW_TAG_member`s). However, adding `VarDecls` to RecordDecls
for static data members should always be done in
`CreateStaticMemberVariable`. The test-case is an exapmle where we would
crash if we tried to create a `VarDecl` from within `GetClangDeclForDIE`
for a static data member.
This patch simply checks whether the `DW_TAG_variable` being parsed is a
static data member, and if so, trivially returns from
`GetClangDeclForDIE` (as we previously did for `DW_TAG_member`s).
