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).
Summary:
LLVM is using its own isPrint/isSpace implementation that doesn't change depending on the current locale. LLDB should do the same
to prevent that internal logic changes depending on the set locale.
Reviewers: JDevlieghere, labath, mib, totally_not_teemperor
Reviewed By: JDevlieghere
Differential Revision: https://reviews.llvm.org/D82175
Summary:
Since commit 7b3ef05a37 the Objective-C++ plugin is dead code.
That commit added Objective-C++ to the list of languages for which `Language::LanguageIsCPlusPlus`
returns true. As the C++ language plugin also uses that method to figure out if it is responsible for a
given language, the C++ plugin since then also became the plugin that we found when looking for
a language plugin for Objective-C++. The only real fallout from that is that the source highlighting
for Objective-C++ files never worked as we always found the C++ plugin which refuses to highlight
files with Objective-C++ extensions.
This patch just adds a special exception for Objective-C++ to the list of languages that are governed
by the C++ plugin. Also adds a test that makes sure that we find the right plugin for all C language
types and that the highlighting for `.mm` (Objective-C++) and `.m` (Objective-C) files works.
I didn't revert 7b3ef05a37 as it does make sense to return
true for Objective-C++ from `Language::LanguageIsCPlusPlus` (e.g., we currently check if we care about
ODR violations by doing `if (Language::LanguageIsCPlusPlus(...))` and this should also work for
Objective-C++).
Fixes rdar://64420183
Reviewers: aprantl
Reviewed By: aprantl
Subscribers: mgorny, abidh, JDevlieghere
Differential Revision: https://reviews.llvm.org/D82109
Summary:
TerminalSizeChanged is called from our SIGWINCH signal handler but the
IOHandlerEditline currently doesn't check if we are actually using the real
editline backend. If we're not using the real editline backend, `m_editline_up`
won't be set and `IOHandlerEditline::TerminalSizeChanged` will access
the empty unique_ptr. In a real use case we don't use the editline backend
when we for example read input from a file. We also create some temporary
IOHandlerEditline's during LLDB startup it seems that are also treated
as non-interactive (apparently to read startup commands).
This patch just adds a nullptr check for`m_editline_up` as we do in the rest of
IOHandlerEditline.
Fixes rdar://problem/63921950
Reviewers: labath, friss
Reviewed By: friss
Subscribers: abidh, JDevlieghere
Differential Revision: https://reviews.llvm.org/D81729
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
On the buildbot long and int have the same size but long and long long don't,
so the bug where we find the first type by size will produce a different error.
Make the test dynamic based on int/long/long long size to fix the bot.
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
Jonas Devlieghere