This patch fixes a failure in `TestFunctionStarts.py` that appeared
following a change of implementation for synthetic symbol names:
https://reviews.llvm.org/D105160
The failure is caused because the previously mentioned patch removes the
object file basename from the generated synthetic symbol names to allow
them to be shared in the constant string pool.
Hence, that last check is not necessary anymore.
rdar://80092322
Differential Revision: https://reviews.llvm.org/D105366
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
Support using the extended thread-id syntax with Hg packet to select
a subprocess. This makes it possible to start providing support for
running some of the debugger packets against another subprocesses.
Differential Revision: https://reviews.llvm.org/D100261
I didn't get around to fix this change and the original commit itself seems
fine, so this looks like an existing LLDB/Clang bug that was just uncovered
by this change. Skipping while I'm investigating.
Previously, when `interpreter.save-session-on-quit` was enabled, lldb
would save the session transcript only when running the `quit` command.
This patch changes that so the transcripts are saved when the debugger
object is destroyed if the setting is enabled.
rdar://72902650
Differential Revision: https://reviews.llvm.org/D105038
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
This patch introduces a new interpreter setting
`interpreter.save-session-directory` so the user can specify a directory
where the session transcripts will be saved.
If not set, the session transcript are saved on a temporary file.
rdar://72902842
Differential Revision: https://reviews.llvm.org/D105030
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
This was an oversight of the commit: bb93483c11 that
added support for the Frozen variants. Also added a test case for the way that
currently produces one of these variants (a copy).
This corrects the test added in
31f9960c38
and temporarily patched in
3b4aad1186.
This test checks that the memory tag read
command errors when you use it on a platform
without memory tagging.
(which is why we skip the test if you actually
have MTE)
The problem with this test is that there's
two levels of unsupported each with it's own
specific error.
On anything that isn't AArch64, there's no
tagging extension we support. So you're told
that that is the case. As in "this won't ever work".
When you're on AArch64 we know that MTE could
be present on the remote and when we find that it
isn't, we tell you that instead.
Expect a different error message on AArch64 to fix
the test.
TestAArch64UnwindPAC.py started failing on LLDB buildbot as underlying
hardware does not support PAC. This patch skips this test for targets
which do not support PAC feature.
This new command looks much like "memory read"
and mirrors its basic behaviour.
(lldb) memory tag read new_buf_ptr new_buf_ptr+32
Logical tag: 0x9
Allocation tags:
[0x900fffff7ffa000, 0x900fffff7ffa010): 0x9
[0x900fffff7ffa010, 0x900fffff7ffa020): 0x0
Important proprties:
* The end address is optional and defaults to reading
1 tag if ommitted
* It is an error to try to read tags if the architecture
or process doesn't support it, or if the range asked
for is not tagged.
* It is an error to read an inverted range (end < begin)
(logical tags are removed for this check so you can
pass tagged addresses here)
* The range will be expanded to fit the tagging granule,
so you can get more tags than simply (end-begin)/granule size.
Whatever you get back will always cover the original range.
Reviewed By: omjavaid
Differential Revision: https://reviews.llvm.org/D97285
This adds memory tag reading using the new "qMemTags"
packet and ptrace on AArch64 Linux.
This new packet is following the one used by GDB.
(https://sourceware.org/gdb/current/onlinedocs/gdb/General-Query-Packets.html)
On AArch64 Linux we use ptrace's PEEKMTETAGS to read
tags and we assume that lldb has already checked that the
memory region actually has tagging enabled.
We do not assume that lldb has expanded the requested range
to granules and expand it again to be sure.
(although lldb will be sending aligned ranges because it happens
to need them client side anyway)
Also we don't assume untagged addresses. So for AArch64 we'll
remove the top byte before using them. (the top byte includes
MTE and other non address data)
To do the ptrace read NativeProcessLinux will ask the native
register context for a memory tag manager based on the
type in the packet. This also gives you the ptrace numbers you need.
(it's called a register context but it also has non register data,
so it saves adding another per platform sub class)
The only supported platform for this is AArch64 Linux and the only
supported tag type is MTE allocation tags. Anything else will
error.
Ptrace can return a partial result but for lldb-server we will
be treating that as an error. To succeed we need to get all the tags
we expect.
(Note that the protocol leaves room for logical tags to be
read via qMemTags but this is not going to be implemented for lldb
at this time.)
Reviewed By: omjavaid
Differential Revision: https://reviews.llvm.org/D95601
This feature "memory-tagging+" indicates that lldb-server
supports memory tagging packets. (added in a later patch)
We check HWCAP2_MTE to decide whether to enable this
feature for Linux.
Reviewed By: omjavaid
Differential Revision: https://reviews.llvm.org/D97282
TestExitDuringExpression test_exit_before_one_thread_no_unwind fails
sporadically on both Arm and AArch64 linux buildbots. This seems like
manifesting itself on a fully loaded machine. I have not found a reliable
timeout value so marking it skip for now.
Those tests are all failing for older Clang versions. This is adding the
respective test decorators for the passing Clang versions to get the recently
revived matrix bot green.
Without DW_CC_pass_by_* attributes that Clang 7 started to emit in this test
we don't properly read back the return value of the `get_*` functions and just
read bogus memory.
See also the TestReturnValue.py test.
Add a new feature to process save-core on Darwin systems -- for
lldb to create a user process corefile with only the dirty (modified
memory) pages included. All of the binaries that were used in the
corefile are assumed to still exist on the system for the duration
of the use of the corefile. A new --style option to process save-core
is added, so a full corefile can be requested if portability across
systems, or across time, is needed for this corefile.
debugserver can now identify the dirty pages in a memory region
when queried with qMemoryRegionInfo, and the size of vm pages is
given in qHostInfo.
Create a new "all image infos" LC_NOTE for Mach-O which allows us
to describe all of the binaries that were loaded in the process --
load address, UUID, file path, segment load addresses, and optionally
whether code from the binary was executing on any thread. The old
"read dyld_all_image_infos and then the in-memory Mach-O load
commands to get segment load addresses" no longer works when we
only have dirty memory.
rdar://69670807
Differential Revision: https://reviews.llvm.org/D88387
This adds a basic SB API for creating and stopping traces.
Note: This doesn't add any APIs for inspecting individual instructions. That'd be a more complicated change and it might be better to enhande the dump functionality to output the data in binary format. I'll leave that for a later diff.
This also enhances the existing tests so that they test the same flow using both the command interface and the SB API.
I also did some cleanup of legacy code.
Differential Revision: https://reviews.llvm.org/D103500
Clang 5 and Clang 6 can no longer parse newer versions of libc++. As we can't
specify the specific libc++ version in the decorator, let's only allow Clang
versions that can parse all currently available libc++ versions.
This test is using -gpubnames which is only available since Clang 8. The
original Clang 7 requirement was based on the availability of
-accel-tables=Dwarf (which the test initially used before being changed to
-gpubnames in commit 15a6df52ef ).
This patch builds on D100521 and other related patches to add support
for unwinding stack on AArch64 systems with pointer authentication
feature enabled.
We override FixCodeAddress and FixDataAddress function in ABISysV_arm64
class. We now try to calculate and set code and data masks after reading
data_mask and code_mask registers exposed by AArch64 targets running Linux.
This patch utilizes core file linux-aarch64-pac.core for testing that
LLDB can successfully unwind stack frames in the presence of signed
return address after masking off ignored bits.
This patch also includes a AArch64 Linux native test case to demonstrate
successful back trace calculation in presence of pointer authentication
feature.
Differential Revision: https://reviews.llvm.org/D99944
DWARF doesn't describe templates itself but only actual template instantiations.
Because of that LLDB has to infer the parameters of the class template
declarations from the actual instantiations when creating the internal Clang AST
from debug info
Because there is no dedicated DIE for the class template, LLDB also creates the
`ClassTemplateDecl` implicitly when parsing a template instantiation. To avoid
creating one ClassTemplateDecls for every instantiation,
`TypeSystemClang::CreateClassTemplateDecl` will check if there is already a
`ClassTemplateDecl` in the requested `DeclContext` and will reuse a found
fitting declaration.
The logic that checks if a found class template fits to an instantiation is
currently just comparing the name of the template. So right now we map
`template<typename T> struct S;` to an instantiation with the values `S<1, 2,
3>` even though they clearly don't belong together.
This causes crashes later on when for example the Itanium mangler's
`TemplateArgManglingInfo::needExactType` method tries to find fitting the class
template parameter that fits to an instantiation value. In the example above it
will try to find the parameter for the value `2` but will just trigger a
boundary check when retrieving the parameter with index 1 from the class
template.
There are two ways we can end up with an instantiation that doesn't fit to a
class template with the same name:
1. We have two TUs with two templates that have the same name and internal
linkage.
2. A forward declared template instantiation is emitted by GCC and Clang
without an empty list of parameter values.
This patch makes the check for whether a class template declaration can be
reused more sophisticated by also comparing whether the parameter values can fit
to the found class template. If we can't find a fitting class template we
justcreate a second class template with the fitting parameters.
Fixes rdar://76592821
Reviewed By: kastiglione
Differential Revision: https://reviews.llvm.org/D100662
This reverts commit db93e4e70a.
This modifies TestRegsters.py to account for Darwin showing
AVX registers as part of "Floating Point Registers" instead
of in a separate "Advanced Vector Extensions" category.
Both tests are passing for GCC>8 on Linux so let's mark them as passing.
TestCPPAuto was originally disabled due to "an problem with debug info generation"
in ea35dbeff2 .
TestClassTemplateParameterPack was disabled without explanation in
0f01fb39e3 .
This reverts commit 00764c36ed and the
follow up d2223c7a49.
The original patch broke that one could use static member variables while
inside a static member functions without having a running target. It seems that
LLDB currently requires that static variables are only found via the global
variable lookup so that they can get materialized and mapped to the argument
struct of the expression.
After 00764c36ed static variables of the current
class could be found via Clang's lookup which LLDB isn't observing. This
resulting in expressions actually containing these variables as normal
globals that can't be rewritten to a member of the argument struct.
More specifically, in the test TestCPPThis, the expression
`expr --j false -- s_a` is now only passing if we have a runnable target.
I'll revert the patch as the possible fixes aren't trivial and it degrades
the debugging experience more than the issue that the revert patch addressed.
The underlying bug can be reproduced before/after this patch by stopping
in `TestCPPThis` main function and running: `e -j false -- my_a; A<int>::s_a`.
The `my_a` will pull in the `A<int>` class and the second expression will
be resolved by Clang on its own (which causes LLDB to not materialize the
static variable).
Note: A workaround is to just do `::s_a` which will force LLDB to take the global
variable lookup.
There is a common pattern:
result.AppendError(...);
result.SetStatus(eReturnStatusFailed);
I found that some commands don't actually "fail" but only
print "error: ..." because the second line got missed.
This can cause you to miss a failed command when you're
using the Python interface during testing.
(and produce some confusing script results)
I did not find any place where you would want to add
an error without setting the return status, so just
set eReturnStatusFailed whenever you add an error to
a command result.
This change does not remove any of the now redundant
SetStatus. This should allow us to see if there are any
tests that have commands unexpectedly fail with this change.
(the test suite passes for me but I don't have access to all
the systems we cover so there could be some corner cases)
Some tests that failed on x86 and AArch64 have been modified
to work with the new behaviour.
Differential Revision: https://reviews.llvm.org/D103701
This is another step towards implementing the equivalent of
`platform process list` and related functionality.
`uint32_t` is used for the argument count and index despite the
underlying value being `size_t` to be consistent with other
index-based access to arguments.
Differential Revision: https://reviews.llvm.org/D103675
When checking for type properties we usually want to strip all kind of type
sugar from the type. For example, sugar like Clang's ElaboratedType or typedefs
rarely influence the fundamental behaviour of a type such as its byte size.
However we always need to preserve type sugar for everything else as it does
matter for users that their variable of type `size_t` instead of `unsigned long`
for example.
This patch fixes one such bug when trying to use the SBValue API to dereference
a type.
Reviewed By: werat, shafik
Differential Revision: https://reviews.llvm.org/D103532
This is present when doing a `platform process list` and is
tracked by the underlying code. To do something like the
process list via the SB API in the future, this must be
exposed.
Differential Revision: https://reviews.llvm.org/D103375
Previously ignore counts were checked when we stopped to do the sync callback in Breakpoint::ShouldStop. That meant we would do all the ignore count work even when
there is also a condition says the breakpoint should not stop.
That's wrong, lldb treats breakpoint hits that fail the thread or condition checks as "not having hit the breakpoint". So the ignore count check should happen after
the condition and thread checks in StopInfoBreakpoint::PerformAction.
The one side-effect of doing this is that if you have a breakpoint with a synchronous callback, it will run the synchronous callback before checking the ignore count.
That is probably a good thing, since this was already true of the condition and thread checks, so this removes an odd asymmetry. And breakpoints with sync callbacks
are all internal lldb breakpoints and there's not a really good reason why you would want one of these to use an ignore count (but not a condition or thread check...)
Differential Revision https://reviews.llvm.org/D103217
