Summary:
This patch adds support for evaluation of expressions referring to types
which were compiled in -flimit-debug-info (a.k.a -fno-standalone-debug)
in clang. In this mode it's possible that the debug information needed
to fully describe a c++ type is not present in a single shared library
-- for example debug info for a base class or a member of a type can
only be found in another shared library. This situation is not
currently handled well within lldb as we are limited to searching within
a single shared library (lldb_private::Module) when searching for the
definition of these types.
The way that this patch gets around this limitation is by doing the
search at a later stage -- during the construction of the expression ast
context. This works by having the parser (currently SymbolFileDWARF, but
a similar approach is probably needed for PDBs too) mark a type as
"forcefully completed". What this means is that the parser has marked
the type as "complete" in the module ast context (as this is necessary
to e.g. derive classes from it), but its definition is not really there.
This is done via a new field on the ClangASTMetadata struct.
Later, when we are importing such a type into the expression ast, we
check this flag. If the flag is set, we try to find a better definition
for the type in other shared libraries. We do this by initiating a
new lookup for the "forcefully completed" classes, which then imports the
type from a module with a full definition.
This patch only implements this handling for base classes, but other
cases (members, array element types, etc.). The changes for that should
be fairly simple and mostly revolve around marking these types as
"forcefully completed" at an approriate time -- the importing logic is
generic already.
Another aspect, which is also not handled by this patch is viewing these
types via the "frame variable" command. This does not use the AST
importer and so it will need to handle these types on its own -- that
will be the subject of another patch.
Differential Revision: https://reviews.llvm.org/D81561
This patch improves the error reporting for SBBreakpoint::AddName by
adding a new method `SBBreakpoint::AddNameWithErrorHandling` that returns
a SBError instead of a boolean.
This way, if the breakpoint naming failed in the backend, the client
(i.e. Xcode), will be able to report the reason of that failure to the
user.
rdar://64765461
Differential Revision: https://reviews.llvm.org/D82879
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
This patch improves the error reporting for SBBreakpoint::AddName by
adding a new method `SBBreakpoint::AddNameWithErrorHandling` that returns
a SBError instead of a boolean.
This way, if the breakpoint naming failed in the backend, the client
(i.e. Xcode), will be able to report the reason of that failure to the
user.
rdar://64765461
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
'InitialLength' is replaced with 'Format' (DWARF32 by default) and 'Length' in this patch.
Besides, test cases for DWARFv4 and DWARFv5, DWARF32 and DWARF64 is
added.
Reviewed By: jhenderson
Differential Revision: https://reviews.llvm.org/D82622
OSType with less than 8 bytes has special code that isn't tested yet.
The same for C-strings that don't have `const char *` type. Also we're now testing
escaping the ASCII escape sequence (\033).
Reland 90c1af106a . This changes the char format
tests which were printing the pointer value of the C-string instead of its
contents, so this test failed on other machines. Now they just print the
bytes in a uint128_t.
Original commit description:
The previous tests apparently missed a few code branches in DumpDataExtractor
code. Also renames the 'test_instruction' which had the same name as another
test (and Python therefore ignored the test entirely).
The previous tests apparently missed a few code branches in DumpDataExtractor
code. Also renames the 'test_instruction' which had the same name as another
test (and Python therefore ignored the test entirely).
and delete a bunch (but not all) redundant code. If you compare the remaining implementations of Platform*Simulator.cpp, there is still an obvious leftover cleanup task.
Specifically, this patch
- removes SDK initialization from dotest (there is equivalent but more
complete code in Makefile.rules)
- make Platform*Simulator inherit the generic implementation of
PlatformAppleSimulator (more can be done here)
- simplify the platform logic in Makefile.rules
- replace the custom SDK finding logic in Platform*Simulator with XcodeSDK
- adds a test for each supported simulator
Differential Revision: https://reviews.llvm.org/D81980
Encountered the following situation: Let we started thread T1 and it hit
breakpoint on B1 location. We suspended T1 and continued the process.
Then we started thread T2 which hit for example the same location B1.
This time in a breakpoint callback we decided not to stop returning
false.
Expected result: process continues (as if T2 did not hit breakpoint) its
workflow with T1 still suspended. Actual result: process do stops (as if
T2 callback returned true).
Solution: We need invalidate StopInfo for threads that was previously
suspended just because something that is already inactive can not be the
reason of stop. Thread::GetPrivateStopInfo() may be appropriate place to
do it, because it gets called (through Thread::GetStopInfo()) every time
before process reports stop and user gets chance to change
m_resume_state again i.e if we see m_resume_state == eStateSuspended
it definitely means it was set during previous stop and it also means
this thread can not be stopped again (cos' it was frozen during
previous stop).
Differential revision: https://reviews.llvm.org/D80112
SBFileSpec.fullpath always uses the forward slash to join the directory with the
base name. This causes mismatches when comparing Windows paths with backslashes
in two of the minidump tests. To get around that we just compare the directory
names separately from the filenames.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D81465
Summary:
The way that the support for the GNU dialect of tail call frames was
implemented in D80519 meant that the were reporting very bogus PC values
which pointed into the middle of an instruction: the -1 trick is
necessary for the address to resolve to the right function, but we
should still be reporting a more realistic PC value -- I say "realistic"
and not "real", because it's very debatable what should be the correct
PC value for frames like this.
This patch achieves that my moving the -1 from SymbolFileDWARF into the
stack frame computation code. The idea is that SymbolFileDWARF will
merely report whether it has provided an address of the instruction
after the tail call, or the address of the call instruction itself. The
StackFrameList machinery uses this information to set the "behaves like
frame zero" property of the artificial frames (the main thing this flag
does is it controls the -1 subtraction when looking up the function
address).
This required a moderate refactor of the CallEdge class, because it was
implicitly assuming that edges pointing after the call were real calls
and those pointing the the call insn were tail calls. The class now
carries this information explicitly -- it carries three mostly
independent pieces of information:
- an address of interest in the caller
- a bit saying whether this address points to the call insn or after it
- whether this is a tail call
Reviewers: vsk, dblaikie
Subscribers: aprantl, mgrang, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D81010
SBTarget::AddModule currently handles the UUID parameter in a very
weird way: UUIDs with more than 16 bytes are trimmed to 16 bytes. On
the other hand, shorter-than-16-bytes UUIDs are completely ignored. In
this patch, we change the parsing code to handle UUIDs of arbitrary
size.
To support arbitrary size UUIDs in SBTarget::AddModule, this patch
changes UUID::SetFromStringRef to parse UUIDs of arbitrary length. We
subtly change the semantics of SetFromStringRef - SetFromStringRef now
only succeeds if the entire input is consumed to prevent some
prefix-parsing confusion. This is up for discussion, but I believe
this is more consistent - we always return false for invalid UUIDs
rather than sometimes truncating to a valid prefix. Also, all the
call-sites except the API and interpreter seem to expect to consume
the entire input.
This also adds tests for adding existing modules 4-, 16-, and 20-byte
build-ids. Finally, we took the liberty of testing the minidump
scenario we care about - removing placeholder module from minidump and
replacing it with the real module.
Reviewed By: labath, friss
Differential Revision: https://reviews.llvm.org/D80755
The printf expression crashes with the message:
Attempted to dereference an invalid pointer
Someone who knows more about Windows should suggest how to fix this.
Support printing strings which contain invalid utf8 sub-sequences, e.g.
strings like "hello world \xfe", instead of bailing out with "Summary
Unavailable".
I took the opportunity here to delete some hand-rolled utf8 -> utf32
conversion code and replace it with calls into llvm's Support library.
rdar://61554346
Summary:
The code changes are very straight-forward -- just handle both DW_AT_GNU
and DW_AT_call versions of all tags and attributes. There is just one
small gotcha: in the GNU version, DW_AT_low_pc was used both for the
"return pc" and the "call pc" values, depending on whether the tag was
describing a tail call, while the official scheme uses different
attributes for the two things.
Reviewers: vsk, dblaikie
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D80519
Commit 0800529fe6 adds a runtime error which triggers when using
SBAddress properties that use the current process/target from a
non-interactive session. TestThreadPlanCommands.py was doing exactly
this and this patch fixes that by use GetLoadAddress instead.
Summary:
This patch adds two new arguments to the MakeInlineTest function. The
main motivation is a follow-up patch I'm preparing, but they seem
generally useful.
The first argument allows the user to specify the "build dictionary".
With this argument one can avoid the need to provide a custom Makefile
if all he needs is to override a couple of make variables. This hooks in
neatly into the existing dictionary support for non-inline tests.
The second argument specifies the name of the test. This could be used
to provide better names to the generated test classes, but it's mainly
useful in conjuction with the first argument: now that we can specify a
custom build dictionary, it may sometimes make sense to run the same
test twice with different build configurations. To achieve that, we need
to give the two tests different names, and this argument achieves that.
The usage of the arguments is demonstrated via TestBasicEntryValues.py.
Reviewers: vsk, JDevlieghere
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D80518
After this patch all remaining tests should pass on macOS when replayed
from a reproducer.
To capture the reproducers:
./bin/llvm-lit ../llvm-project/lldb/test/ --param lldb-run-with-repro=capture
To replay the reproducers:
./bin/llvm-lit ../llvm-project/lldb/test/ --param lldb-run-with-repro=replay
Although it's not entirely clear to me why, this test was generating its
binary in the source directory instead of the build directory. This
patch fixes that following the same approach as other tests.
Summary:
A struct argument can be passed-by-value to a callee via a pointer to a
temporary stack copy. Add support for emitting an entry value DBG_VALUE
when an indirect parameter DBG_VALUE becomes unavailable. This is done
by omitting DW_OP_stack_value from the entry value expression, to make
the expression describe the location of an object.
rdar://63373691
Reviewers: djtodoro, aprantl, dstenb
Subscribers: hiraditya, lldb-commits, llvm-commits
Tags: #lldb, #llvm
Differential Revision: https://reviews.llvm.org/D80345
Many tests use (commented out) print statement for debugging the test
itself. This patch adds a new trace method to lldbtest to reuse the
existing tracing infrastructure and replace these print statements.
Differential revision: https://reviews.llvm.org/D80448
Summary:
This is an attempt to fix https://bugs.llvm.org/show_bug.cgi?id=45988,
where SBValue::GetNumChildren returns 2, but SBValue::GetChildAtIndex(1) returns
an invalid value sentinel.
The root cause of this seems to be that GetNumChildren can return the number of
children of a wrong value. In particular, for pointers GetNumChildren just
recursively calls itself on the pointee type, so it effectively walks chains of
pointers. This is different from the logic of GetChildAtIndex, which only
recurses if pointee.IsAggregateType() returns true (IsAggregateType is false for
pointers and references), so it never follows chain of pointers.
This patch aims to make GetNumChildren (more) consistent with GetChildAtIndex by
only recursively calling GetNumChildren for aggregate types.
Ideally, GetNumChildren and GetChildAtIndex would share the code that decides
which pointers/references are followed, but that is a bit more invasive change.
Reviewers: teemperor, jingham, clayborg
Reviewed By: teemperor, clayborg
Subscribers: clayborg, labath, shafik, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D80254
200 microseconds is not enough time for any expression to execute
reliably. On linux, calling pthread_exit can result in call to dlopen,
which cannot complete in that time, particularly when running under a
debugger.
On linux, this test failed all the time, on macos, about two thirds of
runs were failing. This patch increases the timeout to 100ms, which is
enough to get it passing reliably on linux, though I wouldn't be
surprised if an even bigger timeout would be needed for remote test
runs.
