A skeleton compilation unit may contain the DW_AT_str_offsets_base attribute
that points to the first string offset of the CU contribution to the
.debug_str_offsets. At the same time, when we use split dwarf,
the corresponding split debug unit also
may use DW_FORM_strx* forms pointing to its own .debug_str_offsets.dwo.
In that case, DWO does not contain DW_AT_str_offsets_base, but LLDB
still need to know and skip the .debug_str_offsets.dwo section header to
access the offsets.
The patch implements the support of DW_AT_str_offsets_base.
Differential revision: https://reviews.llvm.org/D54844
llvm-svn: 347859
The changed order of includes caused compile errors on MSVC due to
snprintf macro definition. snprintf should available since VS2015, and
the rest of the code seems to be able to use snprintf just fine without
this macro, so this removes it from the lldb driver as well.
llvm-svn: 347855
They are not needed now that we use LLVMOption for command-line parsing
thank you, Jonas). This also allows us to avoid linking of lldbHost
into the driver which was breaking liblldb encapsulation.
(Technically, there is still a lldb/Host/windows/windows.h include which
is needed on windows, but this is a header-only wrapper for <windows.h>,
so it is not necessary to link lldbHost for that. But ideally, that
should go away too.)
llvm-svn: 347846
The issue happens because starting from DWARF v5
DW_AT_addr_base attribute should be used
instead of DW_AT_GNU_addr_base. LLDB does not do that and
we end up reading the .debug_addr header as section content
(as addresses) instead of skipping it and reading the real addresses.
Then LLDB is unable to match 2 similar locations and
thinks they are different.
Differential revision: https://reviews.llvm.org/D54751
llvm-svn: 347842
Because the optarg variable was shadowed we didn't notice we weren't
extracting the value from the option. This patch fixes that and renames
the variable to prevent this from happening in the future.
I also added two tests to check the error output for --core and --file
when the given value doesn't exist.
llvm-svn: 347821
This adds new APIs and a command to deal with exceptions (mostly Obj-C exceptions): SBThread and Thread get GetCurrentException API, which returns an SBValue/ValueObjectSP with the current exception for a thread. "Current" means an exception that is currently being thrown, caught or otherwise processed. In this patch, we only know about the exception when in objc_exception_throw, but subsequent patches will expand this (and add GetCurrentExceptionBacktrace, which will return an SBThread/ThreadSP containing a historical thread backtrace retrieved from the exception object. Currently unimplemented, subsequent patches will implement this).
Extracting the exception from objc_exception_throw is implemented by adding a frame recognizer.
This also add a new sub-command "thread exception", which prints the current exception.
Differential Revision: https://reviews.llvm.org/D43886
llvm-svn: 347813
Two of the file system tests are failing on Windows - this updates them to expect the correct values after the refactor of the file system code.
llvm-svn: 347796
A couple of new tests have been added that use existing class names. This causes failures on Windows if the tests run at the same time and on any platform it results in the logs being overwritten.
llvm-svn: 347717
When I landed the initial reproducer framework I knew there were some
things that needed improvement. Rather than bundling it with a patch
that adds more functionality I split it off into this patch. I also
think the API is stable enough to add unit testing, which is included in
this patch as well.
Other improvements include:
- Refactor how we initialize the loader and generator.
- Improve naming consistency: capture and replay seems the least ambiguous.
- Index providers by name and make sure there's only one of each.
- Add convenience methods for creating and accessing providers.
Differential revision: https://reviews.llvm.org/D54616
llvm-svn: 347716
On Windows, when using the VFS without going through FileSpec, the
absolute path to `/foo` is `\\foo`. This updates the unittest to expect
that.
llvm-svn: 347712
This patch modifies the lldb driver to use libOption for option parsing.
It allows us to decouple option parsing from option processing which is
important when arguments affect initialization. This was previously not
possible because the debugger need to be initialized as some option
interpretation (like the scripting language etc) was handled by the
debugger, rather than in the driver.
Differential revision: https://reviews.llvm.org/D54692
llvm-svn: 347709
When trying to fix the bots we expected that the cast would be needed in
different places. Ultimately it turned out only the
SymbolFileDWARFDebugMap was affected so, as Pavel correctly notes, it
makes more sense to do the cast just there instead of in teh FS.
llvm-svn: 347660
Summary:
This change adds eLanguageTypeDylan to the set of languages supported
by ClangASTContext. Debug info generated by the Open Dylan compiler's
LLVM back-end was designed to be compatible with C debug info.
Patch by Peter Housel.
Reviewers: clayborg
Reviewed By: clayborg
Subscribers: brucem, lldb-commits, aprantl
Differential Revision: https://reviews.llvm.org/D54886
llvm-svn: 347637
After a recent change in LLVM the TimePoint encoding become more
precise, exceeding the precision of the TimePoint obtained from the
DebugMap. This patch adds a flag to the GetModificationTime helper in
the FileSystem to return the modification time with less precision.
Thanks to Davide for bisecting this failure on the LLDB bots.
llvm-svn: 347615
Summary: SetMustBuildLookupTable() must always be called on a primary context.
Reviewers: labath, shafik, a.sidorin
Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411
Differential Revision: https://reviews.llvm.org/D54863
llvm-svn: 347575
Summary: Right now only some platforms add pthread to the compilation, however, at least one of the tests requires the pthread library on Linux as well. Since the library is available, this change adds it by default on Linux.
Reviewers: labath, zturner, asmith
Subscribers: stella.stamenova, jfb, lldb-commits
Differential Revision: https://reviews.llvm.org/D54808
llvm-svn: 347412
If we just invoke clang-cl without specifying the linker, the tests fail on Windows because they cannot find the correct linker to use, so it needs to be specified explicitly
llvm-svn: 347323
Summary:
Use llvm_codesign to sign debugserver with entitlements.
Set global LLVM_CODESIGNING_IDENTITY from LLDB_CODESIGN_IDENTITY (if given).
Pass through ENTITLEMENTS from add_lldb_executable to add_llvm_executable.
Handle reconfigurations correctly.
We have a lot of cases, make them explicit:
(1) build and sign debugserver, if all conditions apply:
* LLDB_NO_DEBUGSERVER=OFF (default)
* On Darwin: LLDB_USE_SYSTEM_DEBUGSERVER=OFF (default)
* On Darwin: LLVM_CODESIGNING_IDENTITY == lldb_codesign
(2) use system debugserver, if on Darwin and any of:
* LLDB_USE_SYSTEM_DEBUGSERVER=ON and found on system (explicit case)
* LLVM_CODESIGNING_IDENTITY != lldb_codesign and found on system (fallback case)
(3) debugserver will not be available, in case of:
* LLDB_NO_DEBUGSERVER=ON
* On Darwin: LLVM_CODESIGNING_IDENTITY != lldb_codesign and not found on system
(4) error state, in case of:
* LLDB_USE_SYSTEM_DEBUGSERVER=ON and not found on system
* LLDB_USE_SYSTEM_DEBUGSERVER=ON and LLDB_NO_DEBUGSERVER=ON
Reviewers: xiaobai, beanz, vsk, JDevlieghere
Subscribers: mgorny, lldb-commits, llvm-commits
Differential Revision: https://reviews.llvm.org/D54476
llvm-svn: 347305
Otherwise, the clang analyzer tests fail on Windows when attempting to
unpickle AnalyzerTest objects in the worker processes. The pattern of,
add to path, import, remove from path, serialize, deserialize, doesn't
work. Once something gets added to the path, if we want to move it
across the wire for multiprocessing, we need to keep the module on
sys.path.
llvm-svn: 347254
Summary: In order to invoke sed on Windows, we need to quote the command correctly. Since we already have commands which do that, move the definitions at the beginning of the file and then re-use them for each command.
Reviewers: aprantl, zturner
Subscribers: teemperor, lldb-commits
Differential Revision: https://reviews.llvm.org/D54709
llvm-svn: 347243
Recently I tried to port LLDB's lit configuration files over to use a
on the surface, but broke some cases that weren't broken before and also
exposed some additional problems with the old approach that we were just
getting lucky with.
When we set up a lit environment, the goal is to make it as hermetic as
possible. We should not be relying on PATH and enabling the use of
arbitrary shell commands. Instead, only whitelisted commands should be
allowed. These are, generally speaking, the lit builtins such as echo,
cd, etc, as well as anything for which substitutions have been
explicitly set up for. These substitutions should map to the build
output directory, but in some cases it's useful to be able to override
this (for example to point to an installed tools directory).
This is, of course, how it's supposed to work. What was actually
happening is that we were bringing in PATH and LD_LIBRARY_PATH and then
just running the given run line as a shell command. This led to problems
such as finding the wrong version of clang-cl on PATH since it wasn't
even a substitution, and flakiness / non-determinism since the
environment the tests were running in would change per-machine. On the
other hand, it also made other things possible. For example, we had some
tests that were explicitly running cl.exe and link.exe instead of
clang-cl and lld-link and the only reason it worked at all is because it
was finding them on PATH. Unfortunately we can't entirely get rid of
these tests, because they support a few things in debug info that
clang-cl and lld-link don't (notably, the LF_UDT_MOD_SRC_LINE record
which makes some of the tests fail.
The high level changes introduced in this patch are:
1. Removal of functionality - The lit test suite no longer respects
LLDB_TEST_C_COMPILER and LLDB_TEST_CXX_COMPILER. This means there is no
more support for gcc, but nobody was using this anyway (note: The
functionality is still there for the dotest suite, just not the lit test
suite). There is no longer a single substitution %cxx and %cc which maps
to <arbitrary-compiler>, you now explicitly specify the compiler with a
substitution like %clang or %clangxx or %clang_cl. We can revisit this
in the future when someone needs gcc.
2. Introduction of the LLDB_LIT_TOOLS_DIR directory. This does in spirit
what LLDB_TEST_C_COMPILER and LLDB_TEST_CXX_COMPILER used to do, but now
more friendly. If this is not specified, all tools are expected to be
the just-built tools. If it is specified, the tools which are not
themselves being tested but are being used to construct and run checks
(e.g. clang, FileCheck, llvm-mc, etc) will be searched for in this
directory first, then the build output directory.
3. Changes to core llvm lit files. The use_lld() and use_clang()
functions were introduced long ago in anticipation of using them in
lldb, but since they were never actually used anywhere but their
respective problems, there were some issues to be resolved regarding
generality and ability to use them outside their project.
4. Changes to .test files - These are all just replacing things like
clang-cl with %clang_cl and %cxx with %clangxx, etc.
5. Changes to lit.cfg.py - Previously we would load up some system
environment variables and then add some new things to them. Then do a
bunch of work building out our own substitutions. First, we delete the
system environment variable code, making the environment hermetic. Then,
we refactor the substitution logic into two separate helper functions,
one which sets up substitutions for the tools we want to test (which
must come from the build output directory), and another which sets up
substitutions for support tools (like compilers, etc).
6. New substitutions for MSVC -- Previously we relied on location of
MSVC by bringing in the entire parent's PATH and letting
subprocess.Popen just run the command line. Now we set up real
substitutions that should have the same effect. We use PATH to find
them, and then look for INCLUDE and LIB to construct a substitution
command line with appropriate /I and /LIBPATH: arguments. The nice thing
about this is that it opens the door to having separate %msvc-cl32 and
%msvc-cl64 substitutions, rather than only requiring the user to run
vcvars first. Because we can deduce the path to 32-bit libraries from
64-bit library directories, and vice versa. Without these substitutions
this would have been impossible.
Differential Revision: https://reviews.llvm.org/D54567
llvm-svn: 347216
Because of different shell quoting rules, and the fact that LLDB
commands often contain spaces, -O is not portable for writing command
lines. Instead, we should use explicit lldbinit files.
Differential Revision: https://reviews.llvm.org/D54680
llvm-svn: 347213
Those tests were using pexpect and being flaky on some of ours bots.
This patch reimplmeents the tests usinf FileCheck, and it also
extends the test coverage to a few more stop-hook options.
llvm-svn: 347109
This saves about 3 redundant gigabytes from the Objective-C test build
directories. Tests that must do unsavory things with the LLDB clang
module cache, already specify a per-test module cache in their .py
test instructions.
<rdar://problem/36002081>
Differential Revision: https://reviews.llvm.org/D54602
llvm-svn: 347057
Just to be safe, up until now each test used its own Clang module
cache directory. Since the compiler within one testsuite doesn't
change it is just as safe to share a clang module directory inside the
LLDB test build directory. This saves us from compiling tens of
gigabytes of redundant Darwin and Foundation .pcm files and also
speeds up running the test suite quite significantly.
rdar://problem/36002081
Differential Revision: https://reviews.llvm.org/D54601
llvm-svn: 347056
Originally we created our 64-bit UID scheme by using the first byte as
sort of a "tag" to represent what kind of symbol this was, and we
re-used the PDB_SymType enumeration for this. For native pdb support,
this is not really the right abstraction layer, because what we really
want is something that tells us *how* to find the symbol. This means,
specifically, is in the globals stream / public stream / module stream /
TPI stream / etc, and for whichever one it is in, where is it within
that stream?
A good example of why the old namespacing scheme was insufficient is
that it is more or less impossible to create a uid for a field list
member of a class/struction/union/enum that tells you how to locate
the original record.
With this new scheme, the first byte is no longer a PDB_SymType enum
but a new enum created specifically to identify where in the PDB
this record lives. This gives us much better flexibility in
what kinds of symbols the uids can identify.
llvm-svn: 347018
Summary:
This commit implements basic DidAttach and DidLaunch for the windows
DynamicLoader plugin which allow us to load shared libraries from the
inferior.
Reviewers: sas, zturner
Reviewed By: zturner
Differential Revision: https://reviews.llvm.org/D54544
llvm-svn: 346994
Summary:
Windows make will search for other shells and choose those over cmd
if available (e.g. C:\cygdrive\bin\sh.exe). This shell has numerous
issues with path handling (/ vs \\ vs \ and C:). So default to using
cmd.exe which is known to work.
Reviewers: zturner, sas, xiaobai
Reviewed By: zturner
Differential Revision: https://reviews.llvm.org/D54510
llvm-svn: 346993
Summary:
Highlighing junk data on VSCode can send a query for evaluate which
fails. In particular cases on Windows, this the error message can end
up as a c-string of [-35,-35,-35,-35,...]. Attempting to emplace this
as the error message causes an assert failure.
Prior to emplacing the error message, confirm that it is valid UTF8 to
eliminate errors such as mentione above.
Reviewers: xiaobai, clayborg
Reviewed By: clayborg
Differential Revision: https://reviews.llvm.org/D53008
llvm-svn: 346988
Xcode 10 doesn't ship with an i386 SDK any more. This patch ports the
testcase from an i386/x86_64 -> x86_64/x86_64h universal binary.
rdar://problem/46099343
llvm-svn: 346981
This was introduced in r346775. Previously the ABI shared_ptr
was declared as a function local static meaning it would live
forever. After the change, someone has to create a strong
reference to it or it will go away. In this code, we were
calling ABI::FindPlugin(...).get(), so it was being immediately
destroyed and we were holding onto a dangling pointer.
llvm-svn: 346932
When debugging read-only memory we cannot use software breakpoint. We
already have support for hardware breakpoints and users can specify them
with `-H`. However, there's no option to force LLDB to use hardware
breakpoints internally, for example while stepping.
This patch adds a setting target.require-hardware-breakpoint that forces
LLDB to always use hardware breakpoints. Because hardware breakpoints
are a limited resource and can fail to resolve, this patch also extends
error handling in thread plans, where breakpoints are used for stepping.
Differential revision: https://reviews.llvm.org/D54221
llvm-svn: 346920
After committing the initial reproducer feature I noticed a few small
issues which warranted addressing here. It fixes incorrect documentation
in the command object and extract some duplicated code into the debugger
object.
llvm-svn: 346919
This fixes two compilation failures:
1) Designated initializers are C++20. We can't use them in LLVM.
2) thread_result_t is not a pointer type on all platforms, so
returning nullptr is an error.
llvm-svn: 346873
The DataExtractor class itself was moved to Utility some time ago, but
it seems this was not reflected in the location of the test code. Fix
that.
llvm-svn: 346867
Test cases were updated to not use the local compilation dir which
is different between development pc and build bots.
Original commit message:
[LLDB] - Support the single file split DWARF.
DWARF5 spec describes a single file split dwarf case
(when .dwo sections are in the .o files).
Problem is that LLDB does not work correctly in that case.
The issue is that, for example, both .debug_info and .debug_info.dwo
has the same type: eSectionTypeDWARFDebugInfo. And when code searches
section by type it might find the regular debug section
and not the .dwo one.
The patch fixes that. With it, LLDB is able to work with
output compiled with -gsplit-dwarf=single flag correctly.
Differential revision: https://reviews.llvm.org/D52403
llvm-svn: 346855
Summary:
While parsing a childless compile unit DIE we could crash if the DIE was
followed by any extra data (such as a superfluous end-of-children
marker). This happened because the break-on-depth=0 check was performed
only when parsing the null DIE, which was not correct because with a
childless root DIE, we could reach the end of the unit without ever
encountering the null DIE.
If the compile unit contribution ended directly after the CU DIE,
everything would be fine as we would terminate parsing due to reaching
EOF. However, if the contribution contained extra data (perhaps a
superfluous end-of-children marker), we would crash because we would
treat that data as the begging of another compile unit.
This fixes the crash by moving the depth=0 check to a more generic
place, and also adds a regression test.
Reviewers: clayborg, jankratochvil, JDevlieghere
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D54417
llvm-svn: 346849
DWARF5 spec describes a single file split dwarf case
(when .dwo sections are in the .o files).
Problem is that LLDB does not work correctly in that case.
The issue is that, for example, both .debug_info and .debug_info.dwo
has the same type: eSectionTypeDWARFDebugInfo. And when code searches
section by type it might find the regular debug section
and not the .dwo one.
The patch fixes that. With it, LLDB is able to work with
output compiled with -gsplit-dwarf=single flag correctly.
Differential revision: https://reviews.llvm.org/D52296
llvm-svn: 346848
error: implicit conversion from 'double' to 'uint64_t' (aka 'unsigned long') changes value from -0 to 0 [-Werror,-Wliteral-conversion]
llvm-svn: 346841
LC_BUILD_VERSION records are of variable length. The original code
would use uninitialized memory when the size of a record was exactly 24.
rdar://problem/46032185
llvm-svn: 346812
clang-cl does not emit these, but MSVC does, so we need to be able to
handle them.
Because clang-cl does not generate them, it was a bit hard to write a
test. So what I had to do was get an PDB file with some S_CONSTANT
records in using cl and link, dump it using llvm-pdbutil dump -globals
-sym-data to get the bytes of the records, generate the same object file
using clang-cl but with -S to emit an assembly file, and replace all the
S_LDATA32 records with the bytes of the S_CONSTANT records. This way, we
can compile the file using llvm-mc and link it with lld-link.
Differential Revision: https://reviews.llvm.org/D54452
llvm-svn: 346787
In a previous patch, we pre-processed the TPI stream in order to build
the reverse mapping from nested type -> parent type so that we could
accurately reconstruct a DeclContext hierarchy.
However, there were some issues. An LF_NESTTYPE record is really just a
typedef, so although it happens to be used to indicate the name of the
nested type and referring to the global record which defines the type,
it is also used for every other kind of nested typedef. When we rebuild
the DeclContext hierarchy, we want it to be as accurate as possible,
which means that if we have something like:
struct A {
struct B {};
using C = B;
};
We don't want to create two CXXRecordDecls in the AST each with the
exact same definition. We just want to create one for B and then
define C as an alias to B. Previously, however, it would not be able
to distinguish between the two cases and it would treat A::B and
A::C as being two classes each with separate definitions. We address
the first half of improving the pre-processing logic so that only
actual definitions are treated this way.
Later, in a followup patch, we can handle the case of nested
typedefs since we're already going to be enumerating the field list
anyway and this patch introduces the general framework for
distinguishing between the two cases.
Differential Revision: https://reviews.llvm.org/D54357
llvm-svn: 346786
An Obj-C array type _NSCallStackArray is used in NSException backtraces. This patch adds a synthetic frontend for _NSCallStackArray, which now correctly returns frame PCs.
Differential Revision: https://reviews.llvm.org/D44081
llvm-svn: 346708
This patch teaches LLDB about more fields on NSException Obj-C objects, specifically we can now retrieve the "name" and "reason" of an NSException. The goal is to eventually be able to have SB API that can provide details about the currently thrown/caught/processed exception.
Differential Revision: https://reviews.llvm.org/D43884
llvm-svn: 346695
- Refactor reading of NSException fields into ExtractFields method to avoid code duplication.
- Remove "m_child_ptr" field, as it's not used anywhere.
- Clang-format.
Differential Revision: https://reviews.llvm.org/D44073
llvm-svn: 346679
This patch processes the case of retrieving a virtual base when the object is
already read from the debuggee memory.
To achieve that ValueObject::GetCPPVTableAddress was removed and was
reimplemented in ClangASTContext (because access to the process is needed to
retrieve the VTable pointer in general, and because this is the only place that
used old version of ValueObject::GetCPPVTableAddress).
This patch allows to use real object's VTable instead of searching virtual bases
by offsets restored by MicrosoftRecordLayoutBuilder. PDB has no enough info to
restore VBase offsets properly, so we have to read real VTable instead.
Differential revision: https://reviews.llvm.org/D53506
llvm-svn: 346669
Summary:
This follows the approach in Clang. If no overrides are given, LLDB_VERSION_* is inferred from LLVM_VERSION_*. This mimics the current behaviour (PACKAGE_VERSION itself is generated from LLVM_VERSION_*).
For in-tree builds LLVM_VERSION_* will be defined at this point already. For standalone builds, LLDBConfig.cmake is included after LLDBStandalone.cmake which includes LLVMConfig.cmake.
Reviewers: labath, xiaobai
Subscribers: mgorny, friss, aprantl, lldb-commits
Differential Revision: https://reviews.llvm.org/D54333
llvm-svn: 346668
This patch removes the comments grouping header includes. They were
added after running IWYU over the LLDB codebase. However they add little
value, are often outdates and burdensome to maintain.
llvm-svn: 346626
This patch removes the comments following the header includes. They were
added after running IWYU over the LLDB codebase. However they add little
value, are often outdates and burdensome to maintain.
Differential revision: https://reviews.llvm.org/D54385
llvm-svn: 346625
This moves construction of data buffers into the FileSystem class. Like
some of the previous refactorings we don't translate the path yet
because the functionality hasn't been landed in LLVM yet.
Differential revision: https://reviews.llvm.org/D54272
llvm-svn: 346598
some of the macros from mach/exc_resource.h to decode EXC_RESOURCE,
but that header doesn't exist on non-apple platforms and
StopInfoMachException.cpp needs to build on those systems.
EXC_RESOURCE won't be decoded when lldb is built on non-darwin systems.
llvm-svn: 346573
event as a thread stop reason if we receive one, using
some macros to decode the payload.
Patch originally written by Fred Riss, with a few small changes
by myself.
Writing a test for this is a little tricky because the
mach exception data interpretation relies on header macros
or function calls - it may change over time and writing
a gdb_remote_client test for this would break as older
encoding interpretation is changed. I'll tak with Fred
about this more, but neither of us has been thrilled with
the kind of tests we could write for it.
<rdar://problem/13097323>, <rdar://problem/40144456>
llvm-svn: 346571
qWatchpointSupportInfo packet correctly.
In GDBRemoteCommunicationClient::GetWatchpointSupportInfo,
if the response to qWatchpointSupportInfo does not
include the 'num' field, then we did not get an answer
we understood, mark this target as not supporting that
packet.
In Target.cpp, rename the very confusingly named
CheckIfWatchpointsExhausted to CheckIfWatchpointsSupported,
and check the error status returned by
Process::GetWatchpointSupportInfo. If we cannot determine
what the number of supported watchpoints are, assume that
they will work. We'll handle the failure
later when we try to create/enable the watchpoint if the
Z2 packet isn't supported.
Add a gdb_remote_client test case.
<rdar://problem/42621432>
llvm-svn: 346561
This was originally submitted in a patch which fixed two unrelated
bugs at the same time. This portion of the fix was reverted because
it broke several other things. However, the fix employed originally
was totally wrong, and attempted to change something in the ValueObject
printer when actually the bug was in the NativePDB plugin. We need
to mark forward enum decls as having external storage, otherwise
we won't be asked to complete them when the time comes. This patch
implements the proper fix, and updates tests accordingly.
llvm-svn: 346517
Bitfields are represented as LF_MEMBER records whose TypeIndex
points to an LF_BITFIELD record that describes the bit width,
bit offset, and underlying type of the bitfield. All we need to
do is resolve these when resolving record types.
llvm-svn: 346511
The original commit was actually 2 unrelated bug fixes, but it turns
out the second bug fix wasn't quite correct, so the entire patch was
reverted. Resubmitting this half of the patch by itself, then will
follow up with a new patch which fixes the rest of the issue in a
more appropriate way.
llvm-svn: 346505
The whole point of this change was making it possible to resolve paths
without depending on the FileSystem, which is not what I did here. Not
sure what I was thinking...
llvm-svn: 346466
A previous commit fixed an issue with our AST generation where
we were outputting enum decls incorrectly. But we forgot to
update the test output. This patch updates the test output
accordingly.
llvm-svn: 346459
In order to call real_path from the TildeExpressionResolver we need
access to the FileSystem. Since the resolver lives under utility we have
to pass in the FS.
llvm-svn: 346457
The warning was introduced by r346392, which introduces new builtin
types (to support cl_intel_device_side_avc_motion_estimation OpenCL
extension).
Note that this patch only inserts empty cases to silence the warning and
unblock our integrate, does not aim to add support for the new types in
lldb.
llvm-svn: 346441
Moved the declaration of m_kind below the declaration of cvclass,
cvunion and cvenum. This order is necessary because in one of the
constructors the initialization of m_kind depends on the value of
cvclass.
third_party/llvm/llvm/tools/lldb/source/Plugins/SymbolFile/NativePDB/PdbUtil.cpp:50:7: error: field 'cvclass' will be initialized after field 'm_kind' [-Werror,-Wreorder]
: cvclass(std::move(c)),
^
third_party/llvm/llvm/tools/lldb/source/Plugins/SymbolFile/NativePDB/PdbUtil.cpp:51:14: error: field 'cvclass' is uninitialized when used here [-Werror,-Wuninitialized]
m_kind(cvclass.Kind == TypeRecordKind::Struct ? Struct : Class) {}
llvm-svn: 346435
There are two bugs here. The first is that MSVC and clang-cl
emit their bss section under the name '.data' instead of '.bss'
but with the size and file offset set to 0. ObjectFilePECOFF
didn't handle this, and would only recognize a section as bss
if it was actually called '.bss'. The effect of this is that
if we tried to print the value of a variable that lived in BSS
we would fail.
The second bug is that ValueObjectVariable was only returning
the forward type, which is insufficient to print the value of an
enum. So we bump this up to the layout type.
Differential Revision: https://reviews.llvm.org/D54241
llvm-svn: 346430
In order to accurately put a type into the correct location in the AST
we construct from debug info, we need to be able to determine what
DeclContext (namespace, global, nested class, etc) that it goes into.
PDB doesn't contain this mapping. It does, however, contain the reverse
mapping. That is, for a given class type T, you can determine all
classes Q1, Q2, ..., Qn that are nested inside of T. We need to know,
for a given class type Q, what type T is it nested inside of.
This patch builds this map as a pre-processing step when we first
load the PDB by scanning every type. Initial tests show that while
this can be slow in debug builds of LLDB, it is quite fast in release
builds (less than 2 seconds for a ~1GB PDB, and it only needs to happen
once).
Furthermore, having this pre-processing step in place allows us to
repurpose it for building up other kinds of indexing to it down the
line. For the time being, this gives us very accurate reconstruction
of the DeclContext hierarchy.
Differential Revision: https://reviews.llvm.org/D54216
llvm-svn: 346429
Replace calls to LLVM's is_directory with calls to LLDB's FileSytem
class. For this I introduced a new convenience method that, like the
other methods, takes either a path or filespec. This still uses the LLVM
functions under the hood.
Differential revision: https://reviews.llvm.org/D54135
llvm-svn: 346375
Summary:
The DAP on vscode uses a JavaScript `number` for identifiers while the
Visual Studio version uses a C# `Int` for identifiers. lldb-vscode is
bit shifting identifiers 32 bits and then bitwise ORing another 32 bit
identifier into a 64 bit id to form a unique ID. Change this to
a a partitioning of the 32 bits that makes sense for the data types.
Reviewers: clayborg
Differential Revision: https://reviews.llvm.org/D53599
llvm-svn: 346346
Summary:
LLVM puts output binaries in
`${CMAKE_CURRENT_BINARY_DIR}/${CMAKE_CFG_INTDIR}/bin`. This chunk of
code left out the `${CMAKE_CFG_INTDIR}`. Ultimately, the code signing target
does not need a working directory anyways, so it's safe to just remove it.
Reviewers: sas, xiaobai, beanz
Reviewed By: beanz
Subscribers: mgorny
Differential Revision: https://reviews.llvm.org/D53959
llvm-svn: 346281
Summary:
Now that llvm demangler supports more generic customization, we can
implement type substitution directly on top of this API. This will allow
us to remove the specialized hooks which were added to the demangler to
support this use case.
Reviewers: sgraenitz, erik.pilkington, JDevlieghere
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D54074
llvm-svn: 346233
This patch introduces the simple MSVCUndecoratedNameParser. It is needed for
parsing names of PDB symbols corresponding to template instantiations. For
example, for the name `operator<<A>'::`2'::B::operator> we can't just split the
name with :: (as it is implemented for now) to retrieve its scopes. This parser
processes such names in a more correct way.
Differential Revision: https://reviews.llvm.org/D52461
llvm-svn: 346213
Summary:
On rare occasions, the address, instruction and arguments of a line of
assembly in the CreateSource printout would reach > 60 characters. The
function would integer overflow and try to indent a line by `0xfff...`.
Change the calculated offset to be the maximum of 60 or
`line_strm.str().size()`
Reviewers: clayborg, xiaobai
Reviewed By: clayborg
Differential Revision: https://reviews.llvm.org/D52745
llvm-svn: 346179
Summary:
A file opened in text mode on Windows will have `\n` automatically changed to `13,10` while Darwin and Linux leave it as `10`.
Set the file to binary mode to avoid this automatic conversion so that Darwin, Linux and Windows have equivalent treatment of `\r`.
Reviewers: clayborg, xiaobai
Reviewed By: clayborg
Subscribers: emaste, ki.stfu, mgorny, eraman, JDevlieghere, mgrang
Differential Revision: https://reviews.llvm.org/D52672
llvm-svn: 346174
Summary:
pcm files can end up being processed by lldb with relocations to be
made for the .debug_info section. When a R_AARCH64_ABS64 relocation
was required lldb would hit an `assert(false)` and die.
Add R_AARCH64_ABS64 relocations to the S+A 64 bit width code path. Add
a test for R_AARCH64_ABS64 and R_AARCH64_ABS32 .rela.debug_info
relocations in a pcm file.
Reviewers: sas, xiaobai, davide, javed.absar, espindola
Reviewed By: davide
Subscribers: labath, zturner, emaste, mgorny, arichardson, kristof.beyls
Differential Revision: https://reviews.llvm.org/D51566
llvm-svn: 346171
Clang recently improved its DWARF support for C VLA types. The DWARF
now looks like this:
0x00000051: DW_TAG_variable [4]
DW_AT_location( fbreg -32 )
DW_AT_name( "__vla_expr" )
DW_AT_type( {0x000000d3} ( long unsigned int ) )
DW_AT_artificial( true )
...
0x000000da: DW_TAG_array_type [10] *
DW_AT_type( {0x000000cc} ( int ) )
0x000000df: DW_TAG_subrange_type [11]
DW_AT_type( {0x000000e9} ( __ARRAY_SIZE_TYPE__ ) )
DW_AT_count( {0x00000051} )
Without this patch LLDB will naively interpret the DIE offset 0x51 as
the static size of the array, which is clearly wrong. This patch
extends ValueObject::GetNumChildren to query the dynamic properties of
incomplete array types.
See the testcase for an example:
4 int foo(int a) {
5 int vla[a];
6 for (int i = 0; i < a; ++i)
7 vla[i] = i;
8
-> 9 pause(); // break here
10 return vla[a-1];
11 }
(lldb) fr v vla
(int []) vla = ([0] = 0, [1] = 1, [2] = 2, [3] = 3)
(lldb) quit
rdar://problem/21814005
Differential Revision: https://reviews.llvm.org/D53530
llvm-svn: 346165
In January Davide sent an e-mail to the mailing list to suggest removing
unmaintained language plugins such as Go and Java. The plan was to have
some cool down period to allow users to speak up, however after that the
plugins were never actually removed.
This patch removes the OCaml debugger plugin.
The plugin can be added again in the future if it is mature enough both
in terms of testing and maintenance commitment.
Discussion on the mailing list:
http://lists.llvm.org/pipermail/lldb-dev/2018-January/013171.html
Differential revision: https://reviews.llvm.org/D54060
llvm-svn: 346159
In January Davide sent an e-mail to the mailing list to suggest removing
unmaintained language plugins such as Go and Java. The plan was to have
some cool down period to allow users to speak up, however after that the
plugins were never actually removed.
This patch removes the Java debugger plugin.
The plugin can be added again in the future if it is mature enough both
in terms of testing and maintenance commitment.
Discussion on the mailing list:
http://lists.llvm.org/pipermail/lldb-dev/2018-January/013171.html
Differential revision: https://reviews.llvm.org/D54059
llvm-svn: 346158
In January Davide sent an e-mail to the mailing list to suggest removing
unmaintained language plugins such as Go and Java. The plan was to have
some cool down period to allow users to speak up, however after that the
plugins were never actually removed.
This patch removes the Go debugger plugin.
The plugin can be added again in the future if it is mature enough both
in terms of testing and maintenance commitment.
Discussion on the mailing list:
http://lists.llvm.org/pipermail/lldb-dev/2018-January/013171.html
Differential revision: https://reviews.llvm.org/D54057
llvm-svn: 346157
This is useful for investigating the clang ast as you reconstruct
it via by parsing debug info. It can also be used to write tests
against.
Differential Revision: https://reviews.llvm.org/D54072
llvm-svn: 346149
Summary:
There are 2 changes here:
1. Use system sed instead of the sed found in the user's path. This
fixes this script in the case the user has gnu-sed in their $PATH before
bsd sed since `-i ''` isn't compatible and you need `-i` instead.
2. `set -e` in this script so it fails as soon as one of these commands
fail instead of throwing errors for each file if they fail
Since this is only ran on macOS, and we're already using this
absolute path below, this seems like a safe addition
Reviewers: kastiglione, beanz
Reviewed By: kastiglione
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D49776
llvm-svn: 346099
Summary:
A fairly simple operation as setting a breakpoint (writing a breakpoint
opcode) at a given address was going through three classes:
NativeProcessProtocol which called NativeBreakpointList, which then
called SoftwareBrekpoint, only to end up again in NativeProcessProtocol
to do the actual writing itself. This is unnecessarily complex and can
be simplified by moving all of the logic into NativeProcessProtocol
class itself, removing a lot of boilerplate.
One of the reeasons for this complexity was that (it seems)
NativeBreakpointList class was meant to hold both software and hardware
breakpoints. However, that never materialized, and hardware breakpoints
are stored in a separate map holding only hardware breakpoints.
Essentially, this patch makes software breakpoints follow that approach
by replacing the heavy SoftwareBraekpoint with a light struct of the
same name, which holds only the data necessary to describe one
breakpoint. The rest of the logic is in the main class. As, at the
lldb-server level, handling software and hardware breakpoints is very
different, this seems like a reasonable state of things.
Reviewers: krytarowski, zturner, clayborg
Subscribers: mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D52941
llvm-svn: 346093
dotest.py started reporting:
Exception: Found multiple tests with the name TestSampleTest.py
After the commit of:
https://reviews.llvm.org/D54056
llvm-svn: 346089
For the lldb unit test suite, we forgot to add the mapping from
site config to main config, so when it found the main config in
the source tree, it wasn't going and loading the configured version
in the build tree first, so the required properties weren't getting
set up properly.
llvm-svn: 346057
This patch modifies how we open File instances in LLDB. Rather than
passing a path or FileSpec to the constructor, we now go through the
virtual file system. This is needed in order to make things work with
the VFS in the future.
Differential revision: https://reviews.llvm.org/D54020
llvm-svn: 346049
I'm not sure why this has to be CMAKE_CURRENT_SOURCE_DIR, but
it causes all kinds of strange cmake generation errors when it's
the binary dir.
llvm-svn: 346035
A year or so ago, I re-wrote most of the lit infrastructure in LLVM so
that it wasn't so boilerplate-y. I added lots of common helper type
stuff, simplifed usage patterns, and made the code more elegant and
maintainable.
We migrated to this in LLVM, clang, and lld's lit files, but not in
LLDBs. This started to bite me recently, as the 4 most recent times I
tried to run the lit test suite in LLDB on a fresh checkout the first
thing that would happen is that python would just start crashing with
unhelpful backtraces and I would have to spend time investigating.
You can reproduce this today by doing a fresh cmake generation, doing
ninja lldb and then python bin/llvm-lit.py -sv ~/lldb/lit/SymbolFile at
which point you'll get a segfault that tells you nothing about what your
problem is.
I started trying to fix the issues with bandaids, but it became clear
that the proper solution was to just bring in the work I did in the rest
of the projects. The side benefit of this is that the lit configuration
files become much cleaner and more understandable as a result.
Differential Revision: https://reviews.llvm.org/D54009
llvm-svn: 346008
Summary:
This patch fixes the NativePDB tests to make them work from x86 command line too
Reviewers: zturner, stella.stamenova
Subscribers: aleksandr.urakov, teemperor, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D54031
llvm-svn: 345974
This adds support for DW_RLE_base_addressx, DW_RLE_startx_endx,
DW_RLE_startx_length, DW_FORM_rnglistx.
Differential revision: https://reviews.llvm.org/D53929
llvm-svn: 345958
Summary:
This patch adds possibility of searching a public symbol with name and type in a
symbol file. It is helpful when working with PE, because PE's symtabs contain
only imported / exported symbols only. Such a search is required for e.g.
evaluation of an expression that calls some function of the debuggee.
Reviewers: zturner, asmith, labath, clayborg, espindola
Reviewed By: clayborg
Subscribers: emaste, arichardson, aleksandr.urakov, jingham, lldb-commits, stella.stamenova
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D53368
llvm-svn: 345957
This patch removes the static accessor in File to get a file's
permissions. Permissions should be checked through the FileSystem class.
llvm-svn: 345901
This patch removes the logic for resolving paths out of FileSpec and
updates call sites to rely on the FileSystem class instead.
Differential revision: https://reviews.llvm.org/D53915
llvm-svn: 345890
This patch should not introduce any behavior changes. It consists of
mostly one of two changes:
1. Replacing fall through comments with the LLVM_FALLTHROUGH macro
2. Inserting 'break' before falling through into a case block consisting
of only 'break'.
We were already using this warning with GCC, but its warning behaves
slightly differently. In this patch, the following differences are
relevant:
1. GCC recognizes comments that say "fall through" as annotations, clang
doesn't
2. GCC doesn't warn on "case N: foo(); default: break;", clang does
3. GCC doesn't warn when the case contains a switch, but falls through
the outer case.
I will enable the warning separately in a follow-up patch so that it can
be cleanly reverted if necessary.
Reviewers: alexfh, rsmith, lattner, rtrieu, EricWF, bollu
Differential Revision: https://reviews.llvm.org/D53950
llvm-svn: 345882
There were some calls left to Exists() on non-darwin platforms (Windows,
Linux and FreeBSD) that weren't yet updated to use the FileSystem.
llvm-svn: 345857
This patch removes the Exists method from FileSpec and updates its uses
with calls to the FileSystem.
Differential revision: https://reviews.llvm.org/D53845
llvm-svn: 345854
This patch removes the ResolveExecutableLocation method from FileSpec
and updates its uses with calls to the FileSystem.
Differential revision: https://reviews.llvm.org/D53834
llvm-svn: 345853
Speculative fix for the Xcode bots where we were seeing the assertion
being triggered because we would re-initialize the FileSystem without
terminating it.
llvm-svn: 345849
This adds basic support for getting function signature types
into LLDB's type system, including into clang's AST. There are
a few edge cases which are not correctly handled, mostly dealing
with nested classes, but this isn't specific to functions and
apply equally to variable types. Note that no attempt has been
made yet to deal with member function types, which will happen
in subsequent patches.
Differential Revision: https://reviews.llvm.org/D53951
llvm-svn: 345848
This patch removes the GetPermissions and GetReadable methods from
FileSpec and updates its uses with calls to the FileSystem.
Differential revision: https://reviews.llvm.org/D53831
llvm-svn: 345843
Summary:
This patch adds a basic implementation of `DoAllocateMemory` and
`DoDeallocateMemory` for Windows processes. For now it considers only the
executable permission (and always allows reads and writes).
Reviewers: zturner, asmith, stella.stamenova, labath, clayborg
Reviewed By: zturner
Subscribers: Hui, vsk, jingham, aleksandr.urakov, clayborg, abidh, teemperor, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D52618
llvm-svn: 345815
This patch removes the GetByteSize method from FileSpec and updates its
uses with calls to the FileSystem.
Differential revision: https://reviews.llvm.org/D53788
llvm-svn: 345812
This patch moves the EnumerateDirectory functionality and related enum
and typedef from FileSpec to FileSystem.
This is part of a set of patches that extracts file system related
convenience methods from FileSpec. The long term goal is to remove this
method altogether and use the iterators directly, but for introducing
the VFS into LLDB this change is sufficient.
Differential revision: https://reviews.llvm.org/D53785
llvm-svn: 345800
The new implementation of EnumerateDirectory relies on `::no_push()`
being implemented for the VFS recursive directory iterators. However
this patch (D53465) hasn't been landed yet.
llvm-svn: 345787
This patch extends the FileSystem class with a bunch of functions that
are currently implemented as methods of the FileSpec class. These
methods will be removed in future commits and replaced by calls to the
file system.
The new functions are operated in terms of the virtual file system which
was recently moved from clang into LLVM so it could be reused in lldb.
Because the VFS is stateful, we turned the FileSystem class into a
singleton.
Differential revision: https://reviews.llvm.org/D53532
llvm-svn: 345783
This is NFC to clean up the `DWARFFormValue::ExtractValue`.
It groups similar `DW_FORM_*` and removes an excessive
assignment of `ref_addr_size` (it was assigned right after in any case).
llvm-svn: 345733
We need the install-liblldb-stripped target to depend on the
lldb-framework target in order for the installation to be guaranteed to
behave correctly, otherwise it's possible for the lldb-framework and
install-liblldb-stripped targets to run in parallel, resulting in
temporary or partially processed files being copied into the framework.
install-liblldb already depends on lldb-framework for this reason.
Differential Revision: https://reviews.llvm.org/D53917
llvm-svn: 345711
This adds the support for DW_FORM_addrx, DW_FORM_addrx1,
DW_FORM_addrx2, DW_FORM_addrx3, DW_FORM_addrx4 forms.
Differential revision: https://reviews.llvm.org/D53813
llvm-svn: 345706
This patch introduces a concept of "frame recognizer" and "recognized frame". This should be an extensible mechanism that retrieves information about special frames based on ABI, arguments or other special properties of that frame, even without source code. A few examples where that could be useful could be 1) objc_exception_throw, where we'd like to get the current exception, 2) terminate_with_reason and extracting the current terminate string, 3) recognizing Objective-C frames and automatically extracting the receiver+selector, or perhaps all arguments (based on selector).
Differential Revision: https://reviews.llvm.org/D44603
llvm-svn: 345693
This patch introduces a concept of "frame recognizer" and "recognized frame". This should be an extensible mechanism that retrieves information about special frames based on ABI, arguments or other special properties of that frame, even without source code. A few examples where that could be useful could be 1) objc_exception_throw, where we'd like to get the current exception, 2) terminate_with_reason and extracting the current terminate string, 3) recognizing Objective-C frames and automatically extracting the receiver+selector, or perhaps all arguments (based on selector).
Differential Revision: https://reviews.llvm.org/D44603
llvm-svn: 345686
This patch introduces a concept of "frame recognizer" and "recognized frame". This should be an extensible mechanism that retrieves information about special frames based on ABI, arguments or other special properties of that frame, even without source code. A few examples where that could be useful could be 1) objc_exception_throw, where we'd like to get the current exception, 2) terminate_with_reason and extracting the current terminate string, 3) recognizing Objective-C frames and automatically extracting the receiver+selector, or perhaps all arguments (based on selector).
Differential Revision: https://reviews.llvm.org/D44603
llvm-svn: 345678
Due to some libcxx changes to inlining, this now also crashes,
so it gets reported as "failure" by the bot. This commit doesn't
really change the status quo, just placates the bots.
llvm-svn: 345668
We haven't supported compiling ObjC1 for a long time (and never will again), so
there isn't any reason to keep these separate. This patch replaces
LangOpts::ObjC1 and LangOpts::ObjC2 with LangOpts::ObjC.
Differential revision: https://reviews.llvm.org/D53547
llvm-svn: 345637
Previous patches added support for dumping global variables of
primitive types, so we now do the same for class types.
For the most part, everything just worked, there was only one
minor bug needing fixed, which was that for variables of modified
types (e.g. const, volatile, etc) we can't resolve the forward
decl in CreateAndCacheType because the PdbSymUid must point to the
LF_MODIFIER which must point to the forward decl. So when it comes
time to call CompleteType, an assert was firing because we expected
to get a class, struct, union, or enum, but we were getting an
LF_MODIFIER instead.
The other issue is that one the newly added tests is for an array
member, which was not yet supported, so we add support for that
now in this patch.
There's probably room for other interesting layout test cases
here, but this at least should test the basics.
Differential Revision: https://reviews.llvm.org/D53822
llvm-svn: 345629
Summary:
This patch fixes issues with a stack realignment.
MSVC maintains two frame pointers (`ebx` and `ebp`) for a realigned stack - one
is used for access to function parameters, while another is used for access to
locals. To support this the patch:
- adds an alternative frame pointer (`ebx`);
- considers stack realignment instructions (e.g. `and esp, -32`);
- along with CFA (Canonical Frame Address) which point to the position next to
the saved return address (or to the first parameter on the stack) introduces
AFA (Aligned Frame Address) which points to the position of the stack pointer
right after realignment. AFA is used for access to registers saved after the
realignment (see the test);
Here is an example of the code with the realignment:
```
struct __declspec(align(256)) OverAligned {
char c;
};
void foo(int foo_arg) {
OverAligned oa_foo = { 1 };
auto aaa_foo = 1234;
}
void bar(int bar_arg) {
OverAligned oa_bar = { 2 };
auto aaa_bar = 5678;
foo(1111);
}
int main() {
bar(2222);
return 0;
}
```
and here is the `bar` disassembly:
```
push ebx
mov ebx, esp
sub esp, 8
and esp, -100h
add esp, 4
push ebp
mov ebp, [ebx+4]
mov [esp+4], ebp
mov ebp, esp
sub esp, 200h
mov byte ptr [ebp-200h], 2
mov dword ptr [ebp-4], 5678
push 1111 ; foo_arg
call j_?foo@@YAXH@Z ; foo(int)
add esp, 4
mov esp, ebp
pop ebp
mov esp, ebx
pop ebx
retn
```
Reviewers: labath, zturner, jasonmolenda, stella.stamenova
Reviewed By: jasonmolenda
Subscribers: abidh, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D53435
llvm-svn: 345577
Only attempt to link against Backtrace if it is found. Without this,
trying to cross-compile to Windows would try to link against
"Backtrace_LIBRARY-NOTFOUND.lib".
llvm-svn: 345569
Summary:
This allows creating pending breakpoint automatically when a location is not found.
This is used by some front-ends instead of doing "-break-insert -f" every time.
See also https://sourceware.org/gdb/onlinedocs/gdb/Set-Breaks.html
Signed-off-by: Marc-Andre Laperle <malaperle@gmail.com>
Subscribers: MaskRay, llvm-commits, lldb-commits, ki.stfu
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D52953
llvm-svn: 345563
I committed this test without updating the old `settings export` to
settings write. Since the functionality was renamed I also renamed the
test case.
llvm-svn: 345435
was added as a part of D52604 / r343348. If the
lldb driver is run without any arguments, .lldbinit
file reading was not enabled.
<rdar://problem/45570242>
llvm-svn: 345422
Summary:
When evaluating expressions the generic arguments registers are required by ABI.
This patch defines them.
Reviewers: zturner, stella.stamenova, labath
Subscribers: aleksandr.urakov, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D53753
llvm-svn: 345385
LLDB has the ability to display global variables, even without a running
process, via the target variable command. This is because global
variables are linker initialized, so their values are embedded directly
into the executables. This gives us great power for testing native PDB
functionality in a cross-platform manner, because we don't actually need
a running process. We can just create a target using an EXE file, and
display global variables. And global variables can have arbitrarily
complex types, so in theory we can fully exercise the type system,
record layout, and data formatters for native PDB files and PE/COFF
executables on any host platform, as long as our type does not require a
dynamic initializer.
This patch adds basic support for finding variables by name, and adds an
exhaustive test for fundamental data types and pointers / references to
fundamental data types.
Subsequent patches will extend this to typedefs, classes, pointers to
functions, and other cases.
Differential Revision: https://reviews.llvm.org/D53731
llvm-svn: 345373
For the reproducer feature I need to be able to export and import the
current LLDB configuration. To realize this I've extended the existing
functionality to print settings. With the help of a new formatting
option, we can now write the settings and their values to a file
structured as regular commands.
Concretely the functionality works as follows:
(lldb) settings export -f /path/to/file
This file contains a bunch of settings set commands, followed by the
setting's name and value.
...
settings set use-external-editor false
settings set use-color true
settings set auto-one-line-summaries true
settings set auto-indent true
...
You can import the settings again by either sourcing the file or using
the settings read command.
(lldb) settings read -f /path/to/file
Differential revision: https://reviews.llvm.org/D52651
llvm-svn: 345346
This is similar to D53597, but following up with 2 more enums.
After this, all flag enums should be strongly typed all the way
through to the symbol files plugins.
Differential Revision: https://reviews.llvm.org/D53616
llvm-svn: 345314
When we get the `resolve_scope` parameter from the SB API, it's a
`uint32_t`. We then pass it through all of LLDB this way, as a uint32.
This is unfortunate, because it means the user of an API never actually
knows what they're dealing with. We can call it something like
`resolve_scope` and have comments saying "this is a value from the
`SymbolContextItem` enumeration, but it makes more sense to just have it
actually *be* the correct type in the actual C++ type system to begin
with. This way the person reading the code just knows what it is.
The reason to use integers instead of enumerations for flags is because
when you do bitwise operations on enumerations they get promoted to
integers, so it makes it tedious to constantly be casting them back
to the enumeration types, so I've introduced a macro to make this
happen magically. By writing LLDB_MARK_AS_BITMASK_ENUM after defining
an enumeration, it will define overloaded operators so that the
returned type will be the original enum. This should address all
the mechanical issues surrounding using rich enum types directly.
This way, we get a better debugger experience, and new users to
the codebase can get more easily acquainted with the codebase because
their IDE features can help them understand what the types mean.
Differential Revision: https://reviews.llvm.org/D53597
llvm-svn: 345313
We currently had a 2-step process where we had to call
SetBaseClassesForType and DeleteBaseClasses. Every single caller
followed this exact 2-step process, and there was manual memory
management going on with raw pointers. We can do better than this
by storing a vector of unique_ptrs and passing this around.
This makes for a cleaner API, and we only need to call one method
so there is no possibility of a user forgetting to call
DeleteBaseClassSpecifiers.
In addition to this, it also makes for a *simpler* API. Part of
why I wanted to do this is because when I was implementing the native
PDB interface I had to spend some time understanding exactly what I
was deleting and why. ClangAST has significant mental overhead
associated with it, and reducing the API surface can go along
way to making it simpler for people to understand.
Differential Revision: https://reviews.llvm.org/D53590
llvm-svn: 345312
This fixes a bug PlatformDarwin::SDKSupportsModule introduced by
https://reviews.llvm.org/D47889. VersionTuple::tryParse() can deal
with an optional third (micro) component, but the parse will fail when
there are extra characters after the version number (e.g.: trying to
parse the substring "12.0.sdk" out of "iPhoneSimulator12.0.sdk" fails
after that patch). Fixed here by stripping the ".sdk" suffix first.
(Part of) rdar://problem/45041492
Differential Revision https://reviews.llvm.org/D53677
llvm-svn: 345274
With the fix: do not forget to hanlde the DW_RLE_start_end, which seems was
omited/forgotten/removed by mistake.
Original commit message:
The patch implements the support for DW_RLE_base_address and DW_RLE_offset_pair
.debug_rnglists entries
Differential revision: https://reviews.llvm.org/D53140
----
Added : /lldb/trunk/lit/Breakpoint/Inputs/debug_rnglist_offset_pair.yaml
Added : /lldb/trunk/lit/Breakpoint/debug_rnglist_offset_pair.test
Modified : /lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFDebugInfoEntry.cpp
Modified : /lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFDebugRanges.cpp
Modified : /lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFDebugRanges.h
Modified : /lldb/trunk/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
Modified : /lldb/trunk/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.h
llvm-svn: 345251
Currently, we always parse the length field of DW_LLE_startx_length entry as U32.
That is correct for pre-standard definition:
https://gcc.gnu.org/wiki/DebugFission - "A start/length entry contains one unsigned LEB128 number
and a 4-byte unsigned value (as would be represented by the form code DW_FORM_const4u). The first
number is an index into the .debug_addr section that selects the beginning offset, and the second
number is the length of the range. ")
But DWARF v5 says: "This is a form of bounded location description that has two unsigned ULEB operands.
The first value is an address index (into the .debug_addr section) that indicates the beginning of the address
range over which the location is valid. The second value is the length of the range."
Fortunately, we can easily handle the difference. No test case because it seems impossible to test
until we will be ready to use DWARF v5 in tests that need to run the executables.
Differential revision: https://reviews.llvm.org/D53646
llvm-svn: 345249
The -force option allows you to pass an empty value to settings set to
reset the value to its default. This means that the following operations
are equivalent:
settings set -f <setting>
settings clear <setting>
The motivation for this change is the ability to export and import
settings from LLDB. Because of the way the dumpers work, we don't know
whether a value is going to be the default or not. Hence we cannot use
settings clear and use settings set -f, potentially providing an empty
value.
Differential revision: https://reviews.llvm.org/D52772
llvm-svn: 345207
The patch implements the support for DW_RLE_base_address and DW_RLE_offset_pair
.debug_rnglists entries
Differential revision: https://reviews.llvm.org/D53140
llvm-svn: 345127
Add support in ProcessGDBRemote::GetGDBServerRegisterInfo
for recognizing a generic "arm" architecture that will be used if
nothing better is available so that we don't ignore the register
definitions if we didn't already have an architecture set.
Also in ProcessGDBRemote::DoConnectRemote don't set the target
arch unless we have a valid architecture to set it to.
Platform::ConnectProcess will try to get the current target's
architecture, or the default architecture, when creating the
target for the connection to be attempted. If lldb was started
with a target binary, we want to create this target with that
architecture in case the remote gdb stub doesn't supply a
qHostInfo arch.
Add logging to Target::MergeArchitecture.
<rdar://problem/34916465>
llvm-svn: 345106
This adds support to LLDB for named types (class, struct, union, and
enum). This is true cross platform support, and hits the PDB file
directly without a dependency on Windows. Tests are added which
compile a program with certain interesting types and then use
load the target in LLDB and use "type lookup -- <TypeName>" to
dump the layout of the type in LLDB without a running process.
Currently only fields are parsed -- we do not parse methods. Also
we don't deal with bitfields or virtual bases correctly. Those
will make good followups.
Differential Revision: https://reviews.llvm.org/D53511
llvm-svn: 345047
This implements the support for .debug_loclists section, which is
DWARF 5 version of .debug_loc.
Currently, clang is able to emit it with the use of D53365.
Differential revision: https://reviews.llvm.org/D53436
llvm-svn: 345016
Summary:
This patch improves performance of `SymbolFilePDB` on huge executables
in two ways:
- cache names of public symbols by address. When creating variables we are
trying to get a mangled name for each one, and in `GetMangledForPDBData`
we are enumerating all public symbols, which takes O(n) for each variable.
With the cache we can retrieve a mangled name in O(log(n));
- cache section contributions. When parsing variables for context we are
enumerating all variables and check if the current one is belonging
to the current compiland. So we are retrieving a compiland ID
for the variable. But in `PDBSymbolData::getCompilandId` for almost every
variable we are enumerating all section contributions to check if the variable
is belonging to it, and get a compiland ID from the section contribution
if so. It takes O(n) for each variable, but with caching it takes about
O(log(n)). I've placed the cache in `SymbolFilePDB` and have created
`GetCompilandId` there. It actually duplicates `PDBSymbolData::getCompilandId`
except for the cache part. Another option is to support caching
in `PDBSymbolData::getCompilandId` and to place cache in `DIASession`, but it
seems that the last one doesn't imply such functionality, because
it's a lightweight wrapper over DIA and whole its state is only a COM pointer
to the DIA session. Moreover, `PDBSymbolData::getCompilandId` is used only
inside of `SymbolFilePDB`, so I think that it's not a bad place to do such
things. With this patch `PDBSymbolData::getCompilandId` is not used at all.
This bottlenecks were found with profiling. I've discovered these on a simple
demo project of Unreal Engine (x86 executable ~72M, PDB ~82M).
This patch doesn't change external behavior of the plugin, so I think that
there's no need for additional testing (already existing tests should warn us
about regress, if any).
Reviewers: zturner, asmith, labath
Reviewed By: asmith
Subscribers: Hui, lldb-commits, stella.stamenova
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D53375
llvm-svn: 345013
Some backends might violate this assumption. No test case
upstream unfortunately as this is not the case with C++,
but I'm going to add a test in swift language support.
<rdar://problem/40962410>
llvm-svn: 344982
Logs provided by @stella.stamenova indicate that on Linux, lldb adds a
spurious slide offset to the return PC it loads from AT_call_return_pc
attributes (see the list thread: "[PATCH] D50478: Add support for
artificial tail call frames").
This patch side-steps the issue by getting rid of the load address
calculation in lldb's CallEdge::GetReturnPCAddress.
The idea is to have the DWARF writer emit function-local offsets to the
instruction after a call. I.e. return-pc = label-after-call-insn -
function-entry. LLDB can simply add this offset to the base address of a
function to get the return PC.
Differential Revision: https://reviews.llvm.org/D53469
llvm-svn: 344960
As discussed with Greg at the dev meeting, we need to ensure we have the
module lock in the SymbolFile. Usually the symbol file is accessed
through the symbol vendor which ensures that the necessary locks are
taken. However, there are a few methods that are accessed by the
expression parser and were lacking the lock.
This patch adds the locking where necessary and everywhere else asserts
that we actually already own the lock.
Differential revision: https://reviews.llvm.org/D52543
llvm-svn: 344945
This is mostly some cleanup done in the process of implementing
some basic support for types. I tried to split up the patch a
bit to get some of the NFC portion of the patch out into a separate
commit, and this is the result of that. It moves some code around,
deletes some spurious namespace qualifications, removes some
unnecessary header includes, forward declarations, etc.
llvm-svn: 344913
Summary: These tests fail on Windows because of known limitations (a.k.a. bugs) with the current implementation of GetFrameAtIndex
Reviewers: asmith, vsk
Reviewed By: vsk
Subscribers: abidh, lldb-commits
Differential Revision: https://reviews.llvm.org/D53415
llvm-svn: 344788
Summary: They fail similarly to some of the other breakpoint tests on Windows, so I suspect the cause is the same. I've linked to the same bug.
Reviewers: asmith, zturner, jingham
Subscribers: abidh, lldb-commits
Differential Revision: https://reviews.llvm.org/D53331
llvm-svn: 344744
Summary:
This patch makes Windows threads to compare by a thread ID, not by a handle.
It's because the same thread can have different handles on Windows
(for example, `GetCurrentThread` always returns the fake handle `-2`).
This leads to some incorrect behavior. For example, in `Process::GetRunLock`
always `m_public_run_lock` is returned without this patch.
Reviewers: zturner, clayborg, stella.stamenova
Reviewed By: stella.stamenova
Subscribers: stella.stamenova, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D53357
llvm-svn: 344729
This reverts commit r344647.
This causes build failures with [-Werror, -Wswitch]. Some cases where the newly
introduced enum value is not handled in particular are in:
lldb/source/Expression/REPL.cpp:350
lldb/source/Interpreter/CommandInterpreter.cpp:1529
(maybe there could be more)
As I don't understand lldb to make sure the likely trivial fixes are
correct and also as they might need additional tests, leaving to the
author to resolve.
llvm-svn: 344722
DWARF5 describes DW_RLE_start_end as:
This is a form of bounded range entry that has two target address operands.
Each operand is the same size as used in DW_FORM_addr. These indicate
the starting and ending addresses, respectively, that define the address range
for which the following location is valid.
The patch implements the support.
Differential revision: https://reviews.llvm.org/D53193
llvm-svn: 344674
Before we returned an error that was not exposed in the SB API and no useful
error message. This change returns eExpressionProducedNoResult and an
appropriate error string.
<rdar://problem/44539514>
Differential Revision: https://reviews.llvm.org/D53309
llvm-svn: 344647
in r344626 & recommitting. Original commit msg:
Simplify LocateDSYMInVincinityOfExecutable by moving
some redundant code into a separate function,
LookForDsymNextToExecutablePath, and having that function
also look for .dSYM.yaa files in addition to .dSYM
bundles.
Differential Revision: https://reviews.llvm.org/D53305
<rdar://problem/40406580>
llvm-svn: 344646
It merges DWARFDebugInfoEntry's m_empty_children into m_has_children.
m_empty_children was implemented by rL144983.
As Greg confirmed m_has_children was used to represent what was in the DWARF in
the byte that follows the DW_TAG. m_empty_children was used for DIEs that said
they had children but actually only contain a single NULL tag. It is fine to
not differentiate between the two.
Also changed assert()->lldbassert() for m_abbr_idx 16-bit overflow check as
that could be a tough bug to catch if it ever happens.
I have checked all calls of HasChildren() that this change should not matter to
them. The code even wants to know if there are any children - it does not
matter how the children presence is coded in the binary.
Patch written based on suggestions by Greg Clayton.
Differential Revision: https://reviews.llvm.org/D53321
llvm-svn: 344644
tests when targetting a device. Add an include to
safe-to-call-func to work around a modules issue with
a certain combination of header files. Add rules for
Darwin systems to ad-hoc codesign binaries that the
testsuite builds.
llvm-svn: 344635
The TestTailCallFrameSBAPI.py test checks that function names in a
backtrace are equal to an expected value.
Use a relaxed substring check because function dislpay names are
platform-dependent. E.g we see "void sink(void)" on Windows, but "sink()" on
Darwin. This seems like a bug -- just work around it for now.
llvm-svn: 344634
which PlatformRemoteDarwinDevice::UpdateSDKDirectoryInfosIfNeeded
which examine for any additional SDK directories when it is
constructing its list.
<rdar://problem/42984340>
<rdar://problem/41351223>
llvm-svn: 344628
some redundant code into a separate function,
LookForDsymNextToExecutablePath, and having that function
also look for .dSYM.yaa files in addition to .dSYM
bundles.
Differential Revision: https://reviews.llvm.org/D53305
<rdar://problem/40406580>
llvm-svn: 344626
Summary: On non-mac platforms, mac_ver returns an empty string which when converted to LooseVersion has no "version" property. This causes a failure when the decorator executes. Instead, check whether the value returned from mac_ver is an empty string and avoid the LooseVersion comparison.
Reviewers: labath, davide, asmith, shafik, jingham
Reviewed By: jingham
Subscribers: jingham, lldb-commits
Differential Revision: https://reviews.llvm.org/D53208
llvm-svn: 344623
xbolva00 bugreported $subj in: https://reviews.llvm.org/D46810#1247410
It can happen only from the line:
m_die_array.back().SetEmptyChildren(true);
In the case DW_TAG_compile_unit has DW_CHILDREN_yes but there is only 0 (end of
list, no children present). Therefore the assertion can fortunately happen only
with a hand-crafted DWARF or with DWARF from some suboptimal compilers.
Differential Revision: https://reviews.llvm.org/D53255
llvm-svn: 344605
Some tests in test/functionalities/tail_call_frames are failing on
non-Darwin platforms. Use assertEqual to improve logging on failure.
llvm-svn: 344581
Summary:
If the names are not unique, the tests overwrite each other's results and logs. This also causes failures on platforms where the files are locked for writing.
The names of the class/test pairs *have to* always be unique. The easiest way to achieve that is to name each class differently (usually the same as the file name).
Reviewers: jasonmolenda, asmith
Subscribers: clayborg, nemanjai, kbarton, lldb-commits
Differential Revision: https://reviews.llvm.org/D53297
llvm-svn: 344547
Summary: This test is failing on Windows because lldb does not support JIT on Windows.
Reviewers: davide, asmith
Reviewed By: davide
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D53226
llvm-svn: 344543
Fix llvm.org/pr39054:
- Register _lldb as a built-in module during initialization of script interpreter,
- Reverse the order of imports in __init__.py: first try to import by absolute name, which will find the built-in module in the context of lldb (and other hosts that embed liblldb), then try relative import, in case the module is being imported from Python interpreter.
This works for SWIG>=3.0.11; before that, SWIG did not support custom module import code.
Differential revision: https://reviews.llvm.org/D52404
llvm-svn: 344474
This adds -- before any filenames, so that /U doesn't get interpreted
as a command line.
It also adds better error checking, so that we don't get assertions
on the failure path when a file fails to parse as a PDB.
llvm-svn: 344429
If the path was not specified (and it's None), lexists throws an exception rather than returning False. get_filecheck_path now checks whether filecheck is set before calling lexists
llvm-svn: 344410
This was originally reverted due to some test failures on
Linux. Those problems turned out to require several additional
patches to lld and clang in order to fix, which have since been
submitted. This patch is resubmitted unchanged. All tests now
pass on both Linux and Windows.
llvm-svn: 344409
This allows bots which haven't updated to pass in --filecheck to
dotest.py to run more tests. FileCheck-dependent tests will continue to
fail.
Differential Revision: https://reviews.llvm.org/D53175
llvm-svn: 344401
Summary: This is another string/byte conversion issue between Python 2 and 3. In Python 2, the subprocess communication expects a byte string, but in Python 3, it expects bytes. Since both versions are capable of using strings when universal_newlines is set to True AND filecheck operates on strings, force the use of strings.
Reviewers: zturner, asmith, vsk
Reviewed By: zturner
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D53166
llvm-svn: 344386
LLDB does not support this DWARF5 form atm.
At least gcc emits it in some cases when doing optimization
for abbreviations.
As far I can tell, clang does not support it yet, though
the rest LLVM code already knows about it.
The patch adds the support.
Differential revision: https://reviews.llvm.org/D52689
llvm-svn: 344328
This was originally causing some test failures on non-Windows
platforms, which required fixes in the compiler and linker. After
those fixes, however, other tests started failing. Reverting
temporarily until I can address everything.
llvm-svn: 344279
While it doesn't make a *ton* of sense for POSIX paths to be
in PDBs, it's possible to occur in real scenarios involving
cross compilation.
The tools need to be able to handle this, because certain types
of debugging scenarios are possible without a running process
and so don't necessarily require you to be on a Windows system.
These include post-mortem debugging and binary forensics (e.g.
using a debugger to disassemble functions and examine symbols
without running the process).
There's changes in clang, LLD, and lldb in this patch. After
this the cross-platform disassembly and source-list tests pass
on Linux.
Furthermore, the behavior of LLD can now be summarized by a much
simpler rule than before: Unless you specify /pdbsourcepath and
/pdbaltpath, the PDB ends up with paths that are valid within
the context of the machine that the link is performed on.
Differential Revision: https://reviews.llvm.org/D53149
llvm-svn: 344269
LC_BUILD_VERSION load command handling - this
commit is a combination of patches by Adrian
Prantl and myself. llvm::Triple::BridgeOS
isn't defined yet, so all references to that
are currently commented out.
Also update Xcode project file to build the
NativePDB etc plugins.
<rdar://problem/43353615>
llvm-svn: 344209
Summary:
If the process exits before any initial stop then notify the debugger
of the error otherwise WaitForDebuggerConnection() will be blocked.
An example of this issue is when a process fails to load a dependent DLL.
In addition to the fix, remove a duplicate call to FreeProcessHandles() in
DebuggerThread::HandleExitProcessEvent() and use decimal format
for all thread IDs.
Reviewers: rnk, zturner, aleksandr.urakov
Reviewed By: zturner
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D53090
llvm-svn: 344168
The existing SymbolFilePDB only works on Windows, as it is written
against a closed-source Microsoft SDK that ships with their debugging
tools.
There are several reasons we want to bypass this and go straight to the
bits of the PDB, but just to list a few:
More room for optimization. We can't see inside the implementation of
the Microsoft SDK, so we don't always know if we're doing things in the
most efficient way possible. For example, setting a breakpoint on main
of a big program currently takes several seconds. With the
implementation here, the time is unnoticeable.
We want to be able to symbolize Windows minidumps even if not on
Windows. Someone should be able to debug Windows minidumps as if they
were on Windows, given that no running process is necessary.
This patch is a very crude first attempt at filling out some of the
basic pieces.
I've implemented FindFunctions, ParseCompileUnitLineTable, and
ResolveSymbolContext for a limited subset of possible parameter values,
which is just enough to get it to display something nice for the
breakpoint location.
I've added several tests exercising this functionality which are limited
enough to work on all platforms but still exercise this functionality.
I'll try to add as many tests of this nature as I can, but at some
point we'll need a live process.
For now, this plugin is enabled always on non-Windows, and by setting
the environment variable LLDB_USE_NATIVE_PDB_READER=1 on Windows.
Eventually, once it's at parity with the Windows implementation, we'll
delete the Windows DIA-based implementation.
Differential Revision: https://reviews.llvm.org/D53002
llvm-svn: 344154
There are several places that call `FindRanges`,
all of them use `Slide` to adjust the ranges found
by the base address.
All except one, which does the same manually in a loop.
Patch updates it to use `Slide` for consistency.
llvm-svn: 344122
This adds a basic support of the .debug_rnglists section.
Only the DW_RLE_start_length and DW_RLE_end_of_list entries are supported.
Differential revision: https://reviews.llvm.org/D52981
llvm-svn: 344119
This patch teaches lldb to detect when there are missing frames in a
backtrace due to a sequence of tail calls, and to fill in the backtrace
with artificial tail call frames when this happens. This is only done
when the execution history can be determined from the call graph and
from the return PC addresses of calls on the stack. Ambiguous sequences
of tail calls (e.g anything involving tail calls and recursion) are
detected and ignored.
Depends on D49887.
Differential Revision: https://reviews.llvm.org/D50478
llvm-svn: 343900
Before inspecting the contents of a list, make sure that we've stepped
past the push_back() that inserts the element we're interested in.
llvm-svn: 343899
Summary:
When LLDB successfully parses a command (like "expression" in this case) and determines incomplete input, the user can continue typing on multiple lines (in this case "2+3"). This should provide the correct result.
Note that LLDB reverts input from the additional lines, so they are not present in the output.
Reviewers: vsk, davide, aprantl
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D52270
llvm-svn: 343860
Summary:
Add settings to control command echoing:
```
(lldb) settings set interpreter.echo-commands true
(lldb) settings set interpreter.echo-comment-commands true
```
Both settings default to true, which keeps LLDB's existing behavior in non-interactive mode (echo all command inputs to the output).
So far the only way to change this behavior was the `--source-quietly` flag, which disables all output including evaluation results.
Now `echo-commands` allows to turn off echoing for commands, while evaluation results are still printed. No effect if `--source-quietly` was present.
`echo-comment-commands` allows to turn off echoing for commands in case they are pure comment lines. No effect if `echo-commands` is false.
Note that the behavior does not change immediately! The new settings take effect only with the next command source.
LLDB lit test are the main motivation for this feature. So far incoming `#CHECK` line have always been echoed to the output and so they could never fail. Now we can disable it in lit-lldb-init.
Todos: Finish test for this feature. Add to lit-lldb-init. Check for failing lit tests.
Reviewers: aprantl, jasonmolenda, JDevlieghere
Subscribers: friss, lldb-commits
Differential Revision: https://reviews.llvm.org/D52788
llvm-svn: 343859
With buildbot slave under test - I get after rL339929:
http://lab.llvm.org:8014/builders/lldb-x86_64-fedora-28-cmake/builds/243/steps/test1/logs/stdio
File "/home/buildbot/lldbroot/lldb-x86_64-fedora-28-cmake/scripts/../llvm/tools/lldb/test/dotest.py", line 7, in <module>
lldbsuite.test.run_suite()
File "/quad/home/buildbot/lldbroot/lldb-x86_64-fedora-28-cmake/llvm/tools/lldb/packages/Python/lldbsuite/test/dotest.py", line 1177, in run_suite
configuration.results_formatter_object)
File "/quad/home/buildbot/lldbroot/lldb-x86_64-fedora-28-cmake/llvm/tools/lldb/packages/Python/lldbsuite/test/dosep.py", line 1692, in main
dst = core.replace(test_directory, "")[1:]
NameError: global name 'test_directory' is not defined
Patch by Vedant Kumar.
Differential Revision: https://reviews.llvm.org/D51874
llvm-svn: 343726
Summary:
This function existed (with identical code) in both NativeProcessLinux
and NativeProcessNetBSD, and it is likely that it would be useful to any
future implementation of NativeProcessProtocol.
Therefore I move it to the base class.
Reviewers: krytarowski
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D52719
llvm-svn: 343683
This is a follow-up to https://reviews.llvm.org/D46362.
When evaluating a complex expression in DWARFExpression::Evaluate,
file addresses must be resolved to load addresses before we can
perform operations such as DW_OP_deref on them.
For this the address goes through three steps
1. Read the file address as stored in the DWARF
2. Link/relocate the file address (when reading from a .dSYM, this is a no-op)
3. Convert the file address to a load address.
D46362 implemented step (3) by resolving the file address using the
Module that the original DWARF came from. In the case of a dSYM that
is correct, but when reading from .o files, we need to look up
relocated/linked addresses, so the right place to look them up is the
current frame's module. This patch fixes that by setting the
expression's Module to point to the linked debugmap object.
A word a bout the unorthodox testcase: The motivating testcase for
this fix is in Swift, but I managed to hand-modify LLVM-IR for a
trivial C program to exhibit the same problem, so we can fix this in
llvm.org.
rdar://problem/44689915
Differential Revision: https://reviews.llvm.org/D52678
llvm-svn: 343612
Summary:
If there is no newline the "lldb" prompt could be on the wrong line. To reproduce the missing newline you can do 'image dump smytab' on any binary.
Previously
Symtab, file = D:\upstream\build\Debug\bin\clang-diff.exe, num_symbols = 0(lldb)
Now
Symtab, file = D:\upstream\build\Debug\bin\clang-diff.exe, num_symbols = 0
(lldb)
Reviewers: zturner, aleksandr.urakov, lldb-commits
Subscribers: abidh
Differential Revision: https://reviews.llvm.org/D52627
llvm-svn: 343497
Currently we reject our own default disassembly-format string because it
contains two backticks which causes everything in between to be
interpreter as an expression by the command interpreter. This patch
fixes that by escaping backticks when dumping format strings.
llvm-svn: 343471
Summary:
This function encodes the knowledge of whether the PC points to the
breakpoint instruction of the one following it after the breakpoint is
"hit". This behavior mainly(*) depends on the architecture and not on the
OS, so it makes sense for it to be implemented in the base class, where
it can be shared between different implementations (Linux and NetBSD
atm).
(*) It is possible for an OS to expose a different API, perhaps by doing
some fixups in the kernel. In this case, the implementation can override
this function to implement custom behavior.
Reviewers: krytarowski, zturner
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D52532
llvm-svn: 343409
Summary: A RichManglingContext constructed with an invalid demangled name or with a demangled function name without any context will have an empty context. This triggers an assertion in RichManglingContext::GetBufferRef() when debugging a native Windows process on x86 when it shouldn't. Remove the assertion.
Reviewers: aleksandr.urakov, zturner, lldb-commits
Reviewed By: zturner
Subscribers: erik.pilkington
Differential Revision: https://reviews.llvm.org/D52626
llvm-svn: 343292
- Add latency timings to GDB packet log summary if timestamps are on log
- Add the ability to plot the latencies for each packet type with --plot
- Don't crash the script when target xml register info is in wierd format
llvm-svn: 343243
Summary:
The `ClangUserExpression::GetLanguageForExpr` method is currently a big
source of sadness, as it's name implies that it's an accessor method, but it actually
is also initializing some variables that we need for parsing. This caused that we
currently call this getter just for it's side effects while ignoring it's return value,
which is confusing for the reader.
This patch renames it to `UpdateLanguageForExpr` and merges all calls to the
method into a single call in `ClangUserExpression::PrepareForParsing` (as calling
this method is anyway mandatory for parsing to succeed)
While looking at the code, I also found that we actually have two language
variables in this class hierarchy. The normal `Language` from the UserExpression
class and the `LanguageForExpr` that we implemented in this subclass. Both
don't seem to actually contain the same value, so we probably should look at this
next.
Reviewers: xbolva00
Reviewed By: xbolva00
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D52561
llvm-svn: 343191
Summary:
This patch implements restoring of the calling convention from PDB.
It is necessary for expressions evaluation, if we want to call a function
of the debuggee process with a calling convention other than ccall.
Reviewers: clayborg, zturner, labath, asmith
Reviewed By: clayborg
Subscribers: teemperor, lldb-commits, stella.stamenova
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D52501
llvm-svn: 343084
NativeProcessProtocol::ReadMemoryWithoutTrap had a bug, where it failed
to properly remove inserted breakpoint opcodes if the memory read
partially overlapped the trap opcode. This could not happen on x86
because it has a one-byte breakpoint instruction, but it could happen on
arm, which has a 4-byte breakpoint instruction (in arm mode).
Since triggerring this condition would only be possible on an arm
machine (and even then it would be a bit tricky). I test this using a
NativeProcessProtocol unit test.
llvm-svn: 343076
Summary:
* This patch fixes hanging of the test in case of using python3, changes callback
function that will be called if the timer ends, changes python interpreter to
`%python` that is set up by llvm-lit.
* Also, the test didn't work properly since it didn't contain a call of
filecheck_proc.communicate(), that means that filecheck didn't run and its
return code was equal to 0 in all cases.
Reviewers: teemperor, labath, tatyana-krasnukha, aprantl
Reviewed By: teemperor, labath
Subscribers: ki.stfu, lldb-commits
Differential Revision: https://reviews.llvm.org/D52498
llvm-svn: 343033
max number of stack frames to backtrace, make it a setting,
target.process.thread.max-backtrace-depth.
Add a test case for the setting.
<rdar://problem/28759559>
llvm-svn: 343029
Set the "mydir" attribute of an inline test on the test-specific class,
instead of on the base InlineTest class.
This makes it possible to run dotest.py on a directory containing inline
tests. This wasn't really possible prior to this patch, because what
would happen is that one test would just run over and over again, even
though the test infrastructure would claim that different tests were
being run.
Example:
The test infrastructure claimed that all of these different tests were passing,
which couldn't be true --
$ ./bin/lldb-dotest /Users/vsk/src/tailcall/lldb/test/testcases/functionalities/tail_call_frames/ -G dwarf -t 2>&1 | grep PASS
PASS: LLDB (/Users/vsk/src/builds/tailcall-RA/bin/clang-8-x86_64) :: test_dwarf (lldbsuite.test.lldbtest.TestDisambiguateTailCallSeq)
PASS: LLDB (/Users/vsk/src/builds/tailcall-RA/bin/clang-8-x86_64) :: test_dwarf (lldbsuite.test.lldbtest.TestArtificialFrameStepOutMessage)
PASS: LLDB (/Users/vsk/src/builds/tailcall-RA/bin/clang-8-x86_64) :: test_dwarf (lldbsuite.test.lldbtest.TestAmbiguousTailCallSeq1)
PASS: LLDB (/Users/vsk/src/builds/tailcall-RA/bin/clang-8-x86_64) :: test_dwarf (lldbsuite.test.lldbtest.TestDisambiguatePathsToCommonSink)
PASS: LLDB (/Users/vsk/src/builds/tailcall-RA/bin/clang-8-x86_64) :: test_dwarf (lldbsuite.test.lldbtest.TestDisambiguateCallSite)
PASS: LLDB (/Users/vsk/src/builds/tailcall-RA/bin/clang-8-x86_64) :: test_dwarf (lldbsuite.test.lldbtest.TestUnambiguousTailCalls)
PASS: LLDB (/Users/vsk/src/builds/tailcall-RA/bin/clang-8-x86_64) :: test_dwarf (lldbsuite.test.lldbtest.TestAmbiguousTailCallSeq2)
RESULT: PASSED (7 passes, 0 failures, 0 errors, 24 skipped, 0 expected failures, 0 unexpected successes)
... because it wasn't even looking at some of these tests:
$ ./bin/lldb-dotest /Users/vsk/src/tailcall/lldb/test/testcases/functionalities/tail_call_frames/ -G dwarf -t 2>&1 | grep "Change dir"
Change dir to: /Users/vsk/src/tailcall/lldb/packages/Python/lldbsuite/test/functionalities/tail_call_frames/ambiguous_tail_call_seq2
Change dir to: /Users/vsk/src/tailcall/lldb/packages/Python/lldbsuite/test/functionalities/tail_call_frames/ambiguous_tail_call_seq2
Change dir to: /Users/vsk/src/tailcall/lldb/packages/Python/lldbsuite/test/functionalities/tail_call_frames/ambiguous_tail_call_seq2
Change dir to: /Users/vsk/src/tailcall/lldb/packages/Python/lldbsuite/test/functionalities/tail_call_frames/sbapi_support
Change dir to: /Users/vsk/src/tailcall/lldb/packages/Python/lldbsuite/test/functionalities/tail_call_frames/ambiguous_tail_call_seq2
Change dir to: /Users/vsk/src/tailcall/lldb/packages/Python/lldbsuite/test/functionalities/tail_call_frames/thread_step_out_or_return
Change dir to: /Users/vsk/src/tailcall/lldb/packages/Python/lldbsuite/test/functionalities/tail_call_frames/ambiguous_tail_call_seq2
Change dir to: /Users/vsk/src/tailcall/lldb/packages/Python/lldbsuite/test/functionalities/tail_call_frames/ambiguous_tail_call_seq2
Change dir to: /Users/vsk/src/tailcall/lldb/packages/Python/lldbsuite/test/functionalities/tail_call_frames/ambiguous_tail_call_seq2
E.g it was only building one of them:
$ ls lldb-test-build.noindex/functionalities/tail_call_frames/
ambiguous_tail_call_seq2
Differential Revision: https://reviews.llvm.org/D52516
llvm-svn: 343023
On linux, we do not support automatic loading of dependent modules, so
the module list will always contain just one module (until the target is
launched).
llvm-svn: 343016
George Rimar