Summary:
This patch aims to remove multiple copies of GetByteOrder() and ConvertRegisterKindToRegisterNumber used in various versions of RegisterContextPOSIX_*.
Both register implementations are move to RegisterContext class which is parent of RegisterContextPOSIX_* classes.
Built and tested on x86_64-linux-gnu, aarch64-linux-gnu and arm-linux-gnueabihf targets.
Reviewers: labath
Reviewed By: labath
Subscribers: wuzish, nemanjai, kristof.beyls, kbarton, atanasyan, lldb-commits
Differential Revision: https://reviews.llvm.org/D80104
Executing commands below will get you bombarded by a wall of Python
command prompts (>>> ).
$ echo 'foo' | ./bin/lldb -o script
$ cat /tmp/script
script
print("foo")
$ lldb --source /tmp/script
The issue is that our custom input reader doesn't handle EOF. According
to the Python documentation, file.readline always includes a trailing
newline character unless the file ends with an incomplete line. An empty
string signals EOF. This patch raises an EOFError when that happens.
[1] https://docs.python.org/2/library/stdtypes.html#file.readline
Differential revision: https://reviews.llvm.org/D81898
This patch remove the indentation before the command help output.
Supposedly it was meant to be aligned with the different subcommands.
Differential revision: https://reviews.llvm.org/D81783
The reproducer intentionally leak every object allocated during replay,
which means that modules never get orphaned. If this were to happen for
another reason, we might not be testing what we think we are. Assert
that there are no targets left at the end of a test and that the global
module cache is empty in the non-reproducer scenario.
Differential revision: https://reviews.llvm.org/D81612
Prior to my patch of using the LLVM line table parsing code,
SymbolFileDWARF::ParseSupportFiles would only parse the line table
prologues to get the file list for any files that could be in the line
table.
With the old behavior, if we found the file that someone is setting the
breakpoint in in the support files list, we would get a valid index. If
we didn't, we would not look any further. So someone sets a breakpoint
one "MyFile.cpp:12" and if we find "MyFile.cpp" in the support file list
for the compile unit, then and only then would we get the entire line
table for that compile unit.
With the current behavior, no matter what, we always fully parse the
line table for all compile units any time any file and line breakpoint
is set. This creates a serious problem when debugging a large DWARF in
.o file project.
This patch re-instates the old behavior. Unfortunately it means we might
end up parsing to prologue twice, but I don't think that outweighs the
cost of trying to cache/reuse it.
Differential revision: https://reviews.llvm.org/D81589
Summary:
When we get an error back from IRForTarget we directly print that error to the
debugger output stream instead of putting it in the result object. The result
object only gets a vague "The expression could not be prepared to run in the
target" error message that doesn't actually tell the user what went wrong.
This patch just puts the IRForTarget errors into the status object that is
returned to the caller instead of directly printing it to the debugger. Also
updates one test that now can actually check for the error message it is
supposed to check for (instead of the default error which is all we had before).
Reviewers: JDevlieghere
Reviewed By: JDevlieghere
Differential Revision: https://reviews.llvm.org/D81654
The Python 3 interpreter in Xcode has a relative RPATH and dyld fails to
load it when we copy it into the build directory.
This patch adds an additional check that the copied binary can be
executed. If it doesn't, we assume we're dealing with the Xcode python
interpreter and return the path to the real executable. That is
sufficient for the sanitizers because only system binaries need to be
copied to work around SIP.
This patch also moves all that logic out of LLDBTest and into the lit
configuration so that it's executed only once per test run, instead of
once for every test. Although I didn't benchmark the difference this
should result in a mild speedup.
Differential revision: https://reviews.llvm.org/D81696
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
Inline tests have one method named 'test' which means that multiple
inline tests in the same file end up sharing the same build directory
per variant.
This patch overrides the getBuildDirBasename method for the InlineTest
class to include the test name.
Differential revision: https://reviews.llvm.org/D81516
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
Muhammad Omair Javaid