The are not needed as Scalar is implicitly constructible from all of
these types (so the compiler will use a combination of a constructor +
move assignment instead), and they make it very easy for implementations
of assignment and construction operations to diverge.
Summary:
`PlatformAppleSimulator::GetCoreSimulatorPath` currently checks if
`m_core_simulator_framework_path` wasn't set yet and then tries to calculate its
actual value. However, if `GetXcodeDeveloperDirectory` returns an invalid
FileSpec, `m_core_simulator_framework_path` is never assigned a value which
causes that the `return m_core_simulator_framework_path.getValue();` at the end
of the function will trigger an assert.
This patch just assigns an invalid FileSpec to `m_core_simulator_framework_path`
which seems what the calling code in `PlatformAppleSimulator::LoadCoreSimulator`
expects as an error value.
I assume this can be reproduces on machines that don't have an Xcode
installation, but this patch is mostly based on this backtrace I received from
someone else that tried to run the test suite:
```
Assertion failed: (hasVal), function getValue, file llvm/include/llvm/ADT/Optional.h, line 73.
[...]
3 libsystem_c.dylib 0x00007fff682a1ac6 __assert_rtn + 314
4 liblldb.11.0.0git.dylib 0x000000010b835931 PlatformAppleSimulator::GetCoreSimulatorPath() (.cold.1) + 33
5 liblldb.11.0.0git.dylib 0x0000000107e92f11 PlatformAppleSimulator::GetCoreSimulatorPath() + 369
6 liblldb.11.0.0git.dylib 0x0000000107e9383e void std::__1::__call_once_proxy<std::__1::tuple<PlatformAppleSimulator::LoadCoreSimulator()::$_1&&> >(void*) + 30
7 libc++.1.dylib 0x00007fff654d5bea std::__1::__call_once(unsigned long volatile&, void*, void (*)(void*)) + 139
8 liblldb.11.0.0git.dylib 0x0000000107e92019 PlatformAppleSimulator::LaunchProcess(lldb_private::ProcessLaunchInfo&) + 89
9 liblldb.11.0.0git.dylib 0x0000000107e92be5 PlatformAppleSimulator::DebugProcess(lldb_private::ProcessLaunchInfo&, lldb_private::Debugger&, lldb_private::Target*, lldb_private::Status&) + 101
10 liblldb.11.0.0git.dylib 0x0000000107cb044d lldb_private::Target::Launch(lldb_private::ProcessLaunchInfo&, lldb_private::Stream*) + 669
11 liblldb.11.0.0git.dylib 0x000000010792c9c5 lldb::SBTarget::Launch(lldb::SBLaunchInfo&, lldb::SBError&) + 1109
12 liblldb.11.0.0git.dylib 0x0000000107a92acd _wrap_SBTarget_Launch(_object*, _object*) + 477
13 org.python.python 0x000000010681076f PyCFunction_Call + 321
14 org.python.python 0x000000010689ee12 _PyEval_EvalFrameDefault + 7738
```
Reviewers: JDevlieghere, jasonmolenda
Reviewed By: JDevlieghere
Differential Revision: https://reviews.llvm.org/D80997
This replaces the (only) call to llvm::sys::fs::openFileForWrite with
FileSystem::Open. This guarantees that we include log files in the
reproducers.
Differential revision: https://reviews.llvm.org/D81499
These tests are flaky on the reproducer bot. I suspect it has something
to do with the module cache. Skipping the whole category while I
investigate the issue.
This brings over functionality from the xcodeproject that went missing during the CMake transition.
rdar://problem/63840635
Differential Revision: https://reviews.llvm.org/D81300
Before 539b47c9 this test was not actually using the debug_names section
because the -gdwarf added by Makefile.rules on windows overrode the
-gdwarf-5 flag from CFLAGS_EXTRAS. Now that -gdwarf-5 is respected, the
test is failing.
This field is unused (the only way to change its value is via a
constructor which is never called), and as far as I can tell it has been
unused since it was introduced in D12100. It also has some soundness
issues -- e.g. operator= does not reinitialize it, but uses the old
value from the overwritten object.
It sounds like this class should be able to support different floating
point semantics, but if that is needed, it would be better to start
afresh -- probably by passing in an APFloat::fltSemantics object instead
of a bool flag.
This makes it possible to conditionally override some of these flags via
CFLAGS_EXTRAS. It should be NFC right now, but this seems the logical
order in which to apply these things, and I am going to make use of this
in another patch.
In addition to having the default fallback from Python 3 to Python 2, it
should also be possible to build against Python 2 explicitly. This patch
makes that possible by setting LLDB_PYTHON_VERSION. The variable only
has effect with CMake 3.12 or later.
Differential revision: https://reviews.llvm.org/D81501
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
Color the error: and warning: part of the CommandReturnObject output,
similar to how an error is printed from the driver when colors are
enabled.
Differential revision: https://reviews.llvm.org/D81058
D80519 <https://reviews.llvm.org/D80519>
added support for `DW_TAG_GNU_call_site` but
Bug 45886 <https://bugs.llvm.org/show_bug.cgi?id=45886>
found one case did not work.
There is:
0x000000b1: DW_TAG_GNU_call_site
DW_AT_low_pc (0x000000000040111e)
DW_AT_abstract_origin (0x000000cc "a")
...
0x000000cc: DW_TAG_subprogram
DW_AT_name ("a")
DW_AT_prototyped (true)
DW_AT_low_pc (0x0000000000401109)
^^^^^^^^^^^^ - here it did overwrite the 'low_pc' variable containing value 0x40111e we wanted
DW_AT_high_pc (0x0000000000401114)
DW_AT_frame_base (DW_OP_call_frame_cfa)
DW_AT_GNU_all_call_sites (true)
DW_TAG_GNU_call_site attributes order as produced by GCC:
0x000000b1: DW_TAG_GNU_call_site
DW_AT_low_pc (0x000000000040111e)
DW_AT_abstract_origin (0x000000cc "a")
clang produces the attributes in opposite order:
0x00000064: DW_TAG_GNU_call_site
DW_AT_abstract_origin (0x0000002a "a")
DW_AT_low_pc (0x0000000000401146)
Differential Revision: https://reviews.llvm.org/D81334
Previously, we were simply ignoring them and continuing the evaluation.
This behavior does not seem useful, because the resulting value will
most likely be completely bogus.
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
trivial.
We previously took a shortcut by assuming that if a subobject had a
trivial copy assignment operator (with a few side-conditions), we would
always invoke it, and could avoid going through overload resolution.
That turns out to not be correct in the presenve of ref-qualifiers (and
also won't be the case for copy-assignments with requires-clauses
either). Use the same logic for lazy declaration of copy-assignments
that we use for all other special member functions.
Previously committed as c57f8a3a20. This
now also includes an extension of LLDB's workaround for handling special
members without the help of Sema to cover copy assignments.
Since FindXcodeContentsDirectoryInPath expects the *.app/Contents and
DEVELOPER_DIR is supposed to point to Xcode.app, we need to append the
Contents path first.
Differential Revision: https://reviews.llvm.org/D81290
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.
In the similar review D81128, Jonas pointed out some style errors that also
apply to D80775 (which is already committed). Also applying the changes
suggested there to this code.
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
The different tools constructing dotest invocations (lit and
lldb-dotest) already print the command invocation so there's no need to
print it again in the dotest output.
My motivation for removing it is that it doesn't include the Python
interpreter and every time I accidentally copy it, the command fails
with an `ImportError`.
Differential revision: https://reviews.llvm.org/D81032
Summary:
Assignment operator `operator=(long long)` currently allocates `sizeof(long)`.
On some platforms it works as they have `sizeof(long) == sizeof(long long)`,
but on others (e.g. Windows) it's not the case.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D80995
Pavel Labath