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).
The LLDB expression parser relies on using the external AST source
support in LLDB. This allows us to find a class at the root namespace
level, but it wouldn't allow us to find nested classes all of the time.
When LLDB finds a class via this mechanism, it would be able to complete
this class when needed, but during completion, we wouldn't populate
nested types within this class which would prevent us from finding
contained types when needed as clang would expect them to be present if
a class was completed. When we parse a type for a class, struct or
union, we make a forward declaration to the class which can be
completed. Now when the class is completed, we also add any contained
types to the class' declaration context which now allows these types to
be found. If we have a struct that contains a struct, we will add the
forward declaration of the contained structure which can be c ompleted
later. Having this forward declaration makes it possible for LLDB to
find everything it needs now.
This should fix an existing issue:
https://github.com/llvm/llvm-project/issues/53904
Previously, contained types could be parsed by accident and allow
expression to complete successfully. Other times we would have to run an
expression multiple times because our old type lookup from our
expressions would cau se a type to be parsed, but not used in the
current expression, but this would have parsed a type into the
containing decl context and the expression might succeed if it is run
again.
LLVM supports DWARF 5 linetable extension to store source files inline
in DWARF. This is particularly useful for compiler-generated source
code. This implementation tries to materialize them as temporary files
lazily, so SBAPI clients don't need to be aware of them.
rdar://110926168
BreakpointResolverAddress optionally can include the module name related
to the address that gets resolved. Currently this will never work
because it sets the name to itself (which is empty).
These are expected to fail but sometimes crash during the test leaving them
as unresolved.
Same failure message and likely same cause as the other test in this file.
In order to allow smarter vscode extensions, it's useful to send
additional structured information of SBValues to the client.
Specifically, I'm now sending error, summary, autoSummary and
inMemoryValue in addition to the existing properties being sent. This is
cheap because these properties have to be calculated anyway to generate
the display value of the variable, but they are now available for
extensions to better analyze variables. For example, if the error field
is not present, the extension might be able to provide cool features,
and the current way to do that is to look for the `"<error: "` prefix,
which is error-prone.
This also incorporates a tiny feedback from
https://github.com/llvm/llvm-project/pull/74865#issuecomment-1850695477
We previously were defining _BSD_SOURCE right before including getopt.h.
However, on mingw-w64, getopt.h is also transitively included by
unistd.h, and unistd.h can be transitively included by many headers
(recently, by some libc++ headers).
Therefore, to be safe, we need to define _BSD_SOURCE before including
any header. Thus do this in CMake.
This fixes https://github.com/llvm/llvm-project/issues/76050.
TestGlobalModuleCache.py, a recently added test, tries to update a
source file in the build directory, but it assumes the file is writable.
In our distributed build and test system, this is not always true, so
the test often fails with a write permissions error.
This change fixes that by setting the permissions on the file to be
writable before attempting to write to it.
If adding a user commands fails because a command with the same name
already exists, we only say that "force replace is not set" without
telling the user _how_ to set it. There are two ways to do so; this
commit changes the error message to mention both.
The way this code was updated in
dd95877958 meant that if the first module
did not have the symbol, the iteration stopped as returning true means
stop. So only if every module had the symbol would we find it, in the
last module.
Invert the condition to break when we find the first instance, which is
what the previous code did.
This reverts commit 01c4ecb7ae,
d14d52158b and
a756dc4724.
This removes the logging and workaround I added earlier,
and puts back the skip for Arm/AArch64 Linux.
I've not seen it fail on AArch64 since, but let's not create
more noise if it does.
I've written up the issue as https://github.com/llvm/llvm-project/issues/76057.
It's something to do with trying to destroy a process while
a thread is doing a single sep. So my workaround wouldn't have
worked in any case. It needs a more involved fix.
This has been flaky for a while, for example
https://lab.llvm.org/buildbot/#/builders/96/builds/50350
```
Command Output (stdout):
--
lldb version 18.0.0git (https://github.com/llvm/llvm-project.git revision 3974d89bde)
clang revision 3974d89bde
llvm revision 3974d89bde
"can't evaluate expressions when the process is running."
```
```
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace.
#0 0x0000ffffa46191a0 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/build/lib/python3.8/site-packages/lldb/_lldb.cpython-38-aarch64-linux-gnu.so+0x529a1a0)
#1 0x0000ffffa4617144 llvm::sys::RunSignalHandlers() (/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/build/lib/python3.8/site-packages/lldb/_lldb.cpython-38-aarch64-linux-gnu.so+0x5298144)
#2 0x0000ffffa46198d0 SignalHandler(int) (/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/build/lib/python3.8/site-packages/lldb/_lldb.cpython-38-aarch64-linux-gnu.so+0x529a8d0)
#3 0x0000ffffab25b7dc (linux-vdso.so.1+0x7dc)
#4 0x0000ffffab13d050 /build/glibc-Q8DG8B/glibc-2.31/string/../sysdeps/aarch64/multiarch/memcpy_advsimd.S:92:0
#5 0x0000ffffa446f420 lldb_private::process_gdb_remote::GDBRemoteRegisterContext::PrivateSetRegisterValue(unsigned int, llvm::ArrayRef<unsigned char>) (/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/build/lib/python3.8/site-packages/lldb/_lldb.cpython-38-aarch64-linux-gnu.so+0x50f0420)
#6 0x0000ffffa446f7b8 lldb_private::process_gdb_remote::GDBRemoteRegisterContext::GetPrimordialRegister(lldb_private::RegisterInfo const*, lldb_private::process_gdb_remote::GDBRemoteCommunicationClient&) (/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/build/lib/python3.8/site-packages/lldb/_lldb.cpython-38-aarch64-linux-gnu.so+0x50f07b8)
#7 0x0000ffffa446f308 lldb_private::process_gdb_remote::GDBRemoteRegisterContext::ReadRegisterBytes(lldb_private::RegisterInfo const*) (/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/build/lib/python3.8/site-packages/lldb/_lldb.cpython-38-aarch64-linux-gnu.so+0x50f0308)
#8 0x0000ffffa446ec1c lldb_private::process_gdb_remote::GDBRemoteRegisterContext::ReadRegister(lldb_private::RegisterInfo const*, lldb_private::RegisterValue&) (/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/build/lib/python3.8/site-packages/lldb/_lldb.cpython-38-aarch64-linux-gnu.so+0x50efc1c)
#9 0x0000ffffa412eaa4 lldb_private::RegisterContext::ReadRegisterAsUnsigned(lldb_private::RegisterInfo const*, unsigned long) (/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/build/lib/python3.8/site-packages/lldb/_lldb.cpython-38-aarch64-linux-gnu.so+0x4dafaa4)
#10 0x0000ffffa420861c ReadLinuxProcessAddressMask(std::shared_ptr<lldb_private::Process>, llvm::StringRef) (/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/build/lib/python3.8/site-packages/lldb/_lldb.cpython-38-aarch64-linux-gnu.so+0x4e8961c)
#11 0x0000ffffa4208430 ABISysV_arm64::FixCodeAddress(unsigned long) (/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/build/lib/python3.8/site-packages/lldb/_lldb.cpython-38-aarch64-linux-gnu.so+0x4e89430)
```
Judging by the backtrace something is trying to read the pointer authentication address/code mask
registers. This explains why I've not seen this issue locally, as the buildbot runs on Graviton
3 with has the pointer authentication extension.
I will try to reproduce, fix and re-enable the test.
And remove the workaround I was trying, as this logging may prove what
the actual issue is.
Which I think is that the thread plan map in Process is cleared before
the threads are destroyed. So Thread::ShouldStop could be getting
the current plan, then the plan map is cleared, then Thread::ShouldStop
is deciding based on that plan to pop a plan from the now empty stack.
This a follow-up PR from this other one:
https://github.com/llvm/llvm-project/pull/74413
Nothing calls into these two methods, so we (@DavidSpickett,
@adrian-prantl, and I) agreed to remove them once we merged the previous
PR.
NestedClass will be found via Class::NestedClass and
ClassTypedef::NestedClass. So the first part of the test gets 2 results
as the default is to find all matching types.
In the next part, we ask for only the first match and expect to get only
1 of those two possible results.
The function was using the default version of ValueObject::Dump, which
has a default of using the synthetic-ness of the top-level value for
determining whether to print _all_ values as synthetic. This resulted in
some unusual behavior, where e.g. a std::vector is stringified as
synthetic if its dumped as the top level object, but in its raw form if
it is a member of a struct without a pretty printer.
The SBValue class already has properties which determine whether one
should be looking at the synthetic view of the object (and also whether
to use dynamic types), so it seems more natural to use that.
This patch replaces uses of StringRef::startswith with
StringRef::starts_with for consistency with
std::{string,string_view}::starts_with in C++20.
I'm planning to deprecate and eventually remove
StringRef::{starts,ends}with.
This patch replaces uses of StringRef::{starts,ends}with with
StringRef::{starts,ends}_with for consistency with
std::{string,string_view}::{starts,ends}_with in C++20.
I'm planning to deprecate and eventually remove
StringRef::{starts,ends}with.
This patch replaces uses of StringRef::{starts,ends}with with
StringRef::{starts,ends}_with for consistency with
std::{string,string_view}::{starts,ends}_with in C++20.
I'm planning to deprecate and eventually remove
StringRef::{starts,ends}with.
This patch fixes the SymbolFilePDBTests::TestMaxMatches(...) by making
it test what it was testing before, see comments in the test case for
details.
It also disables TestUniqueTypes4.py for now until we can debug or fix
why it isn't working.
This adds 23 new helper functions to LLDB's CompilerType class, things
like IsSmartPtrType, IsPromotableIntegerType,
GetNumberofNonEmptyBaseClasses, and GetTemplateArgumentType (to name a
few).
It also has run clang-format on the files CompilerType.{h,cpp}.
These helper functions are needed as part of the implementation for the
Data Inspection Language, (see
https://discourse.llvm.org/t/rfc-data-inspection-language/69893).
This adds support for optionally prefixing any command with `?` and/or
`!`.
- `?` prevents the output of a commands to be printed to the console
unless it fails.
- `!` aborts the dap if the command fails.
They come in handy when programmatically running commands on behalf of
the user without wanting them to know unless they fail, or when a
critical setup is required as part of launchCommands and it's better to
abort on failures than to silently skip.
This reverts commit 481bb62e50 and
71b4d7498f, along with the logging
and assert I had added to the test previously.
Now that I've caught it failing on Arm:
https://lab.llvm.org/buildbot/#/builders/17/builds/46598
Now I have enough to investigate, skip the test on the effected
platforms while I do that.
If you type `settings show <tab>` LLDB might crash, depending on the
version of libedit you're compiled with, and whether you're compiled
with `-DLLDB_EDITLINE_USE_WCHAR=0` (and depending on how the optimizer
lays out the stack...)
The issue has to do with trying to figure out whether the libedit
`getchar` callback is supposed to read a wide or 8 bit character. In
order to maintain backward compatibility, there's really no 'clean' way
to do it. We just have to make sure that we're invoking el_[w]getc with
a buffer that is as wide as the getchar callback (registered by the
`SetGetCharacterFunction` function further down in `Editline.cpp`.
So, it's 'fixed' with a comment, and a wider version of the 'reply'
variable.
Co-authored-by: Kevin Frei <freik@meta.com>
