Summary:
This patch fixes a problem with retrieving a function symbol by an
address in a nested block. In the current implementation of
ResolveSymbolContext function it retrieves a symbol with
PDB_SymType::None and then checks if found symbol's tag equals to
PDB_SymType::Function. So, if nested block's symbol was found,
ResolveSymbolContext does not resolve a function.
Reviewers: asmith, labath, zturner
Reviewed By: asmith, labath
Differential Revision: https://reviews.llvm.org/D47939
Patch by Aleksandr Urakov <aleksandr.urakov@jetbrains.com>
llvm-svn: 335822
When running the test suite with .debug_names a bunch of tests were
failing because GetCompleteObjCClass was not yet implemented for
DebugNamesDWARFIndex. This patch adds the required logic.
We use the .debug_names to find the Objective-C class and then rely on
DW_AT_APPLE_objc_complete_type to find the complete type. If we can't
find it or the attribute is not supported, we return a list of potential
complete types.
Differential revision: https://reviews.llvm.org/D48596
llvm-svn: 335776
This change allows to make AddressClass strongly typed enum and not to have issues with old versions of SWIG that don't support enum classes.
llvm-svn: 335710
Summary:
During the previous attempt to generalize the UUID class, it was
suggested that we represent invalid UUIDs as length zero (previously, we
used an all-zero UUID for that). This meant that some valid build-ids
could not be represented (it's possible however unlikely that a checksum of
some file would be zero) and complicated adding support for variable
length build-ids (should a 16-byte empty UUID compare equal to a 20-byte
empty UUID?).
This patch resolves these issues by introducing a canonical
representation for an invalid UUID. The slight complication here is that
some clients (MachO) actually use the all-zero notation to mean "no UUID
has been set". To keep this use case working (while making it very
explicit about which construction semantices are wanted), replaced the
UUID constructors and the SetBytes functions with named factory methods.
- "fromData" creates a UUID from the given data, and it treats all bytes
equally.
- "fromOptionalData" first checks the data contents - if all bytes are
zero, it treats this as an invalid/empty UUID.
Reviewers: clayborg, sas, lemo, davide, espindola
Subscribers: emaste, lldb-commits, arichardson
Differential Revision: https://reviews.llvm.org/D48479
llvm-svn: 335612
If we have a function with signature f(addr_t, AddressClass), it is easy to muddle up the order of arguments without any warnings from compiler. 'enum class' prevents passing integer in place of AddressClass and vice versa.
llvm-svn: 335599
This method does one of two things:
1. finds a minimum os deployment version # in a Mach-O load
command and saves the three parts in the m_sdk_version, or
2. finds no valid min os version # load command, pushes a
sentinel value on the m_sdk_version vector so we don't search
the same load commands multiple times.
There was a little bug when we found a load command with
a version of 0.0.0 - the method would not add anything to
the m_sdk_version vector but would declare that a success.
It would not push the sentinel value to the vector.
There was code later in the method which assumed that
the vector always had a sentinel value, at least, and that
code could crash when this method was called back when
evaluating a Swift expression. (these version #'s are
fetched lazily so it wouldn't happen when the object file
was parsed, only when doing an expression that needed
the version #).
<rdar://problem/41372699>
llvm-svn: 335556
pseudo_barrier_wait() begins by decrementing an atomic variable. Since
these are always_inline in libc++, there is no line table anchor to
break on before we decrement it. This meant that on gcc we stopped after
the variable has been decremented, which meant that thread2 could have
exited, violating the test setup. On clang this wasn't a problem
because it generated some line table entries for the do{}while(0) loop
in the macro, so we still ended up stopping, before we touched the
variable.
I fix this by adding a dummy statement before the pseudo_barrier_wait()
command and setting the breakpoint there.
llvm-svn: 335476
This reverts r335432 because remove_dots() is expensive and measuring
its impact showed an observable performance regression
(https://reviews.llvm.org/D45977#1078510).
llvm-svn: 335448
Removing redundant components from the path seems pretty harmless.
Rather than checking whether this is necessary and then actually doing
so, always invoke remove_dots to start with a normalized path.
llvm-svn: 335432
Filenames with test results contain only the class name which makes it more
difficult to find it if the same class name is present in multiple *.py files.
packages/Python/lldbsuite/test/functionalities/step-avoids-no-debug/TestStepNoDebug.py
-class ReturnValueTestCase(TestBase):
+class StepAvoidsNoDebugTestCase(TestBase):
as ReturnValueTestCase is already present in:
packages/Python/lldbsuite/test/functionalities/return-value/TestReturnValue.py
packages/Python/lldbsuite/test/functionalities/thread/crash_during_step/TestCrashDuringStep.py
-class CreateDuringStepTestCase(TestBase):
+class CrashDuringStepTestCase(TestBase):
as CreateDuringStepTestCase is already present in:
packages/Python/lldbsuite/test/functionalities/thread/create_during_step/TestCreateDuringStep.py
packages/Python/lldbsuite/test/functionalities/thread/step_until/TestStepUntil.py
-class TestCStepping(TestBase):
+class StepUntilTestCase(TestBase):
as TestCStepping is already present in:
packages/Python/lldbsuite/test/lang/c/stepping/TestStepAndBreakpoints.py
llvm-svn: 335431
Replaces custom implementations of append and prepend with calls to
llvm's path library. This is part of a series of patches (started in
D48084) to delegate common operations to llvm::sys::path.
llvm-svn: 335430
Fixes include:
- fix all lint errors
- add code that will automatically register and LLDB command classes by detecting the classes and any classes that have a "register_lldb_command" function
- automatically fill in the correct module name when registering commands
- automatically fill in the class name when registering command
llvm-svn: 335401
libstdc++ will soon be dropped from the android NDK. This patch makes
sure we are prepared for that by using libc++ in tests by default (i.e.,
except for libstdc++ data formatter tests).
Only a couple of small tweaks were needed to make this work:
- Add the libc++ include paths to CXXFLAGS only. This was necessary to
make the tests compile with -fmodules. The modules tests have been
disabled, but this way, they will be ready for them if they are
enabled.
- in one test I had to add an explicit std::string copy to make sure the
copy constructor is there for the expression evaluator to find it.
llvm-svn: 335344
Our DWARF parsing code had a workaorund for Objective-C "self" not
being marked as artifial by the compiler. Clang has been doing this
since 2010, so let's just drop the workaround.
llvm-svn: 335313
Jim pointed out that XCode has build configurations that build without
python and removing the ifdefs around the python code breaks them.
This reverts the #ifdef part of the above patch, while keeping the cmake
parts.
llvm-svn: 335260
I've made the code accept only 16 byte UUIDs, which is technically not
NFC (previously it would also accept 20 byte ones, but use only the
first 16 bytes), but this should be more correct as mac UUIDs are always
16 byte long.
llvm-svn: 335247
Instead of a separate GetBytes + GetByteSize methods I introduce a
single GetBytes method returning an ArrayRef.
This is NFC cleanup now, but it should make handling arbitrarily-sized
UUIDs cleaner, should we choose to go that way. I also took the
opportunity to add some unit tests for this class.
llvm-svn: 335244
Instead of #ifdef-ing the contents of all files in the plugin for all
non-python builds, just disable the plugin at the cmake level. Also,
remove spurious extra linking of the Python plugin in liblldb. This
plugin is already included as a part of LLDB_ALL_PLUGINS variable.
llvm-svn: 335236
These tests are extremely environment-dependent. if the environment is
not module-enabled (which is the likely scenario), they won't test
anything. If one happens to have a module-enabled libc++, then the he
will start running into problems.
The first one is that the debug info in pcm file contains relocations
that ObjectFileELF doesn't handle (particularly on non-x86
architectures), but even after that is resolved, it seems we still are
unable to pull debug info out of the pcm file. I've filed pr37893 to
track that, and I am disabling gmodules tests on linux until these
issues are resolved.
llvm-svn: 335235
In a modules build, android is very picky about which symbols are
visible after including libc++ headers (e.g. <cstdio> defines only
std::printf and not ::printf).
This consolidates the tests where this was an issue to always include
the <c???> version of the headers and prefixes the symbols with std:: as
necessary.
Apart from that, there is no functional change in the tests.
llvm-svn: 335149
The problem was that with libc++ the std::unique_lock declaration was
completely inlined, so there was no line table entry in the main.cpp
file to set a breakpoint on. Therefore, the breakpoint got moved to the
next line, but that meant the test would deadlock as the thread would
stop with the lock already held.
I fix that issue by adding a dummy statement before the std::unique_lock
line to anchor the breakpoint.
I think this should fix the issue because of which this test was
disabled on darwin, but someone should verify that before enabling it.
llvm-svn: 335132
Sign-extension of small types (e.g. short) was not handled correctly.
The reason for that was that when we were assigning the a value to the
Scalar object, we would accidentally promote the type to int (even
though the assignment code in AssignTypeToMatch tried to cast the value
to the appropriate type, it would still invoke the "int" version of
operator=). Instead, I use the APInt version of operator=, where the
bitwidth is specified explicitly. Among other things, this allows us to
fold the individual size cases into one.
llvm-svn: 335114
Summary:
The only reason python was used in the Host module was to compute the
python path. I resolve this the same way as D47384 did for clang, by
moving the path computation into the python plugin and modifying
SBHostOS class to call into this module for ePathTypePythonDir.
Reviewers: zturner, jingham, davide
Subscribers: mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D48215
llvm-svn: 335104
passes to the recursive search function so we only recursively
search the kext bundle directory, instead of its parent directory.
<rdar://problem/41227170>
Differential Revision: https://reviews.llvm.org/D48302
llvm-svn: 335079
Summary:
OnExit ensures we call `ResetDeclMap` before this method ends. However,
we also have a few manual calls to ResetDeclMap in there that are actually unnecessary
because of this (calling the method multiple times has no effect). This patch also moves
the class out of the method that we can reuse it for the upcoming method that handles
parsing for completion.
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D48337
llvm-svn: 335078
StringConvert was the only non-Utility dependency of this class. Getting
rid of it means it will be easy to move this class to a lower layer.
While I was in there, I also added a couple of unit tests for the Scalar
string conversion function.
llvm-svn: 335060
Summary:
Instead of a function taking an enum value determining which path to
return, we now have a suite of functions, each returning a single path
kind. This makes it easy to move the python-path function into a
specific plugin in a follow-up commit.
All the users of GetLLDBPath were converted to call specific functions
instead. Most of them were hard-coding the enum value anyway, so this
conversion was simple. The only exception was SBHostOS, which I've
changed to use a switch on the incoming enum value.
Reviewers: clayborg, zturner
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D48272
llvm-svn: 335052
The issue was that there was no dependency from lldb-suite target to liblldb in
the no-framework scenario. This caused the finish-swig target to be executed
prematurely and fail (because it cannot copy liblldb to the python folder). On
other platforms this did not matter because there just creates a symlink.
The extra lldb-suite -> liblldb edge should fix this. Technically, I could add
this just to the !framework case as the framework target will take care of the
transitive dep, but it seemed more clear to make the dep unconditional.
llvm-svn: 335047
Pavel Labath