This provides an efficient (at least on Posix platforms) way to offload to the
target process the search & loading of a library when all we have are the
library name and a set of potential candidate locations.
<rdar://problem/40905971>
llvm-svn: 335912
Summary: On Windows, the newer DIA SDKs end up producing function names that contain the return type as well. This means that the function name returned in the test will contain the return type (int) in addition to the name of the function and the type of the input (a(int)). To account for the possibility of both, the test should pass if the function name matches either pattern.
Reviewers: zturner, asmith
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D48654
llvm-svn: 335906
Summary:
To successfully open a core file, we need to have LLVM built with
support for the relevant target. Right now, if one does not have the
appropriate targets configured, the tests will fail.
This patch uses the GetBuildConfiguration SB API to inform the test (and
anyone else who cares) about the list of supported LLVM targets. The
test then uses this information to approriately skip the tests.
Reviewers: clayborg, jingham
Subscribers: martong, lldb-commits
Differential Revision: https://reviews.llvm.org/D48641
llvm-svn: 335859
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
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
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
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
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
The second makefile that was added has implicit rules which meant
that secondprog.cpp would be built once into a secondprog binary,
but it would also be compiled as a.out overwriting the main binary.
This lead to spurious failures.
This commit simplifies the Makefile to build only once with the correct
executable name.
llvm-svn: 334861
on darwin systems and re-execing itself, to creating two
separate test programs; lldb runs the first program and it
exec's the second.
Support for compiling for i386 is going away.
llvm-svn: 334783
Summary:
test_set_working_dir was testing two scenario: failure to set the working dir because of a non existent directory and succeeding to set the working directory. Since the negative case fails on both Linux and Windows, the positive case was never tested. I split the test into two which allows us to always run both the negative and positive cases. The positive case now succeeds on Linux and the negative case still fails.
During the investigation, it turned out that lldbtest.py will try to execute a process launch command up to 3 times if the command failed. This means that we could be covering up intermittent failures by running any test that does process launch multiple times without ever realizing it. I've changed the counter to 1 (though it can still be overwritten with the environment variable).
This change also fixes both the positive and negative cases on Windows. There were a few issues:
1) In ProcessLauncherWindows::LaunchProcess, the error was not retrieved until CloseHandle was possibly called. Since CloseHandle is also a system API, its success would overwrite any existing error that could be retrieved using GetLastError. So by the time the error was retrieved, it was now a success.
2) In DebuggerThread::StopDebugging TerminateProcess was called on the process handle regardless of whether it was a valid handle. This was causing the process to crash when the handle was LLDB_INVALID_PROCESS (0xFFFFFFFF).
3) In ProcessWindows::DoLaunch we need to check that the working directory exists before launching the process to have the same behavior as other platforms which first check the directory and then launch process. This way we also control the exact error string.
Reviewers: labath, zturner, asmith, jingham
Reviewed By: labath
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D48050
llvm-svn: 334642
This patch adds a data formatter for NSDecimalNumber. The latter is a
Foundation object used for representing and performing arithmetic on
base-10 numbers that bridges to Decimal.
Differential revision: https://reviews.llvm.org/D48114
llvm-svn: 334638
This method is used to find complete definitions of a type when one
parses a compile unit with only forward declaration available.
Since it is only accessed from DWARFASTParserClang, it was not
possible/easy to trigger this codepath from lldb-test. Therefore, I
adapt add a debug-names variant to an existing dotest test to cover this
scenario.
llvm-svn: 334516
Apparently some compilers generate incomplete debug information which
caused the updated test to fail. Therefore I've extracted the new check
into a separate test case with the necessary decorators.
llvm-svn: 334456
Before Pavel's change in r334181, we were printing too many global
variables. This patch updates the test suite to ensure we don't regress
again in the future.
rdar://problem/29180927
llvm-svn: 334454
There was no way to find out what's wrong if SBProcess SBTarget::LoadCore(const char *core_file) failed.
Additionally, the implementation was unconditionally setting sb_process, so it wasn't even possible to check if the return SBProcess is valid.
This change adds a new overload which surfaces the errors and also returns a valid SBProcess only if the core load succeeds:
SBProcess SBTarget::LoadCore(const char *core_file, SBError &error);
Differential Revision: https://reviews.llvm.org/D48049
llvm-svn: 334439
Summary: Check case when _M_t child member is not present.
Reviewers: labath, tberghammer
Reviewed By: labath, tberghammer
Differential Revision: https://reviews.llvm.org/D47932
Patch by Aleksandr Urakov <aleksandr.urakov@jetbrains.com>.
llvm-svn: 334411
r334215 changed the error message the tool prints for invalid thread
arguments to -exec-next command. This adjust the test to match that.
llvm-svn: 334279
Summary: They all correspond to bugs that are already logged and I've added the appropriate (or most appropriate) bug numbers. This leaves only a handful of failing tests.
Reviewers: asmith, zturner, labath
Reviewed By: zturner
Subscribers: eraman, llvm-commits
Differential Revision: https://reviews.llvm.org/D47892
llvm-svn: 334210
Summary:
This is split off from D47265 where I needed to be able to invoke every test
with -f. That patch is kinda dead now, but this part seems like a good
cleanup anyway.
The problem with inline tests was in the way we were adding methods to
the class, which left them with an incorrect __name__ property. This
prevented dotest from finding them with -f.
I fix this with (what I think is) the correct way of dynamically
creating classes -- passing the list of methods during type construction
instead of fixing up the class afterwards. Among other things this has
the advantage of not needing to do anything special for debug info
variants. As our test method will be visible to the metaclass, it will
automagically do the multiplication for us.
Reviewers: JDevlieghere, aprantl, tberghammer
Subscribers: eraman, lldb-commits
Differential Revision: https://reviews.llvm.org/D47579
llvm-svn: 334009
Add OpenBSD python module in order to support unit tests.
Reviewers: labath, zturner
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D47692
llvm-svn: 333888
On Darwin, the binary's symbol table points to debug info in object
files -- potentially object files within a static library. Such a
library may have multiple entries with the same name, distinguished
only by timestamp.
The code was already _attempting_ to handle this case (see the code in
ObjectContainerBSDArchive::Archive::FindObject which disambiguates via
timestamp). But, unfortunately, while the timestamp was taken into
account on the _first_ lookup, the result was then cached in a map
keyed only off of the path.
Added the timestamp to the cache, and added a test case.
Differential Revision: https://reviews.llvm.org/D47660
llvm-svn: 333813
In r331719, I changed Module::FindTypes not to limit the amount
of types returned by the Symbol provider, because we want all
possible matches to be able to filter them. In one code path,
the filtering was applied to the TypeList without changing the
number of types that gets returned. This is turn could cause
consumers to access beyond the end of the TypeList.
This patch fixes this case and also adds an assertion to
TypeList::GetTypeAtIndex to catch those obvious programming
mistakes.
Triggering the condition in which we performed the incorrect
access was not easy. It happened a lot in mixed Swift/ObjectiveC
code, but I was able to trigger it in pure Objective C++ although
in a contrieved way.
rdar://problem/40254997
llvm-svn: 333786
This test was using unittest (not unittest2) as the test framework, and
it worked with dotest only by accident. Remove it as we have a much more
realistic example test in test/testcases/sample_test.
llvm-svn: 333640
It's been failing since I enabled the test for non-darwin targets. I
made it reference the same bug as the linux core, as it's likely that
the root cause is the same.
llvm-svn: 333401
Summary:
The plugin already builds fine on other platforms (linux, at least). All
that was necessary was to revitalize the hack in PlatformDarwinKernel
(not a very pretty hack, but it gets us going at least).
I haven't done a thorough investigation of the state of the plugin on
other platforms, but at least the two core file tests we have seem to
pass, so I enable them.
Reviewers: JDevlieghere, jasonmolenda
Subscribers: lldb-commits, mgorny
Differential Revision: https://reviews.llvm.org/D47133
llvm-svn: 332997
In r265181 the test for the NSCFBoolean data formatter was removed.
Later, in r279353 and r279446 a new implementation was provided for the
formatter, which I believe never worked (and this wasn't caught because
the test was never re-enabled).
This commit fixes the bug and re-enables the old test case.
Differential revision: https://reviews.llvm.org/D47014
llvm-svn: 332700
Summary: These three tests are failing on Windows and looking into the failures, they could be mapped to pr21765 and pr24489
Reviewers: asmith, labath, zturner
Reviewed By: zturner
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D47018
llvm-svn: 332629
Summary:
1) In logtest.cpp, the name of the file that is reported is not always capitalized, so split the comparison to validate the file (case insensitive) and function (case sensitive) separately
2) Update the gdb remote client tests to work with Python 3. In Python 3, socket sends/receives data as bytes rather than byte strings. This also updates the usage of .hex() - this is no longer available in Python 3, so use hexlify instead
Reviewers: asmith, labath, zturner
Reviewed By: labath
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D46773
llvm-svn: 332293
This reverts commit r332162 as it breaks the bots (Ubuntu 14.04)
with the following message:
Build Command Output:
objcopy: option '--compress-debug-sections' doesn't allow an argument
llvm-svn: 332165
Summary:
1) In TestLinuxCore rather than skipping the tests on Windows, mark them as expected failures and add a bug reference
2) In dotest.py replace the undefined property in the exceptions with the actual property causing the exception
Reviewers: asmith, labath, zturner
Reviewed By: labath, zturner
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D46590
llvm-svn: 331886
Re-enable TestUnicodeSymbols now that we use the in-tree dsymutil. This
was disabled because the hashing of unicode symbols was out of sync
between llvm (dsymutil) and lldb.
llvm-svn: 331764
Summary:
... and fix one bug found this way. Currently, the test works not because
types are looked up correctly, but because by injecting local variables
we also materialize the types for Clang. If we disable the local variable
injection, then one check fails.
The reason of the failure is that FindTypes is run with max_matches==1
and this value is passed down to the symbol lookup functions. When the
search is performed only on the basename (like it's the case for an
entity defined in the root namespace), then the search will stop after
having found one match on the basename. But that match might be in a
namespace, we were really just looking up the basename in the accelerator
tables.
The solution is to not pass max_matches down, but to search without a
limit and let RemoveMismatchedTypes do its job afterwards. Note the
patch includes 2 hunks with the same change, but only the latter is
tested. I couldn't find a way to create a testcase for the other
branch of the if ('image lookup -t' allows me to get there, but it
only ever returns one type anyway).
Reviewers: clayborg, jingham
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D46548
llvm-svn: 331719
Summary:
In decorators.py, when opening streams, open them in text mode. In Py3, if they are not opened in text mode, the data is also expected to be binary, but we always use text data.
In TestLinuxCore, skip the tests that are not applicable on Windows
In the python api main.c, update the code to be compilable on Windows
Reviewers: asmith, zturner
Reviewed By: zturner
Subscribers: zturner
Differential Revision: https://reviews.llvm.org/D46440
llvm-svn: 331686
This change adds support for two types of Minidump CodeView records:
PDB70 (reference: https://crashpad.chromium.org/doxygen/structcrashpad_1_1CodeViewRecordPDB70.html)
This is by far the most common record type.
ELF BuildID (found in Breakpad/Crashpad generated minidumps)
This would set a proper UUID for placeholder modules, in turn enabling
an accurate match with local module images.
Differential Revision: https://reviews.llvm.org/D46292
llvm-svn: 331394
if an experimental setting has been removed/is missing.
Add tests for the .experimental. settings behaviors -- that they correctly
forward through to the real setting if it has become a real setting,
that they don't generate errors when a settig has been removed.
As Pavel notes in https://reviews.llvm.org/D45348, the way I'm suppressing
errors in the setting is not completely correct - if any of the setting
path components include "experimental", a missing setting would be declared
a non-error. So
settings set target.experimental.setting-that-does-not-exist true
would not generate an error, which is correct. But as Pavel notes,
settings set setting-does-not-exist.experimental.run-stopped true
should generate an error because the unknown name occurs before the
"experimental". The amount of change to do this correctly hasn't
thrilled me, so I'm leaving this as-is for now.
<rdar://problem/39223054>
Differential Revision: https://reviews.llvm.org/D45348
llvm-svn: 331315
Displaying of global pointer variables is not working on arm64 linux
(pr37301).
I've moved this part into a separate test, so it can be xfailed
separately. I then move the "show-variables-with-process-available"
check before the "show-all-variables" command to presrve the intent of
checking that global variable caching works correctly. (I've verified
that the new arrangement still fails when I revert the fix from
r331230.)
llvm-svn: 331250
This fixes a bug where
(lldb) target var g_ptr
would populate the global variables list with exactly one entry
because SymbolFileDWARF::ParseVariables() was invoked with a list of
DIEs pre-filtered by name, such that a subsequent call to
(lldb) fr var --show-globals
would only list that one variable, because CompileUnit::m_variables
was already initialized, fooling CompileUnit::GetVariableList().
CompileUnit::GetVariableList() grabs the *complete* list of variables
via (SymbolFileDWARF, ...)::ParseVariablesForContext and that still
calls CompileUnit::SetVariableList(variables) which acts as the
caching mechanism.
Differential Revision: https://reviews.llvm.org/D46220
llvm-svn: 331230
This patch fixes an issue where we weren't looking for exact matches in the expression parser and also fixed the type lookup logic in the Module.cpp. Tests added to make sure we don't regress.
Differential Revision: https://reviews.llvm.org/D46128
llvm-svn: 331227
ObjectFileELF assumes that code section has ".text" name. There is an
exception for kalimba toolchain that can use arbitrary names, but other
toolchains also could use arbitrary names for code sections. For
example, corert uses separate section for compiled managed code. As lldb
doesn't recognize such section it leads to problem with breakpoints on
arm, because debugger cannot determine instruction set (arm/thumb) and
uses incorrect breakpoint opcode that breaks program execution.
This change allows debugger to correctly handle such code sections. We
assume that section is a code section if it has SHF_EXECINSTR flag set
and has SHT_PROGBITS type.
Patch by Konstantin Baladurin <k.baladurin@partner.samsung.com>.
Differential Revision: https://reviews.llvm.org/D44998
llvm-svn: 331173
A typo in the patch (using syntax instead of m_syntax) resulted in the
normalization not working properly for windows filespecs when the syntax
was passed as host-native. This did not affect the unit tests, as all of
those pass an explicity syntax, but failed gloriously when running the
full test suite.
I also fix an expectation in an lldb-mi test, which was now failing
because it was expecting a path to be echoed verbatim, but we were now
normalizing it.
As a drive-by, this also fixes the default-in-fully-covered-switch
warning and removes an unused argument from the NeedsNormalization
function.
llvm-svn: 331172
LLDB doesn't use this packet so we never hit this, but it looks like
some other projects talk to debugserver and are hitting an assert
(https://github.com/derekparker/delve/issues/1015).
We had an off by 1 in the accounting of the FPU structure sizes.
I added a test that basically just check that 'g' doesn't return
an error (currently it assert in debug builds). I didn't make
it an lldb-server test because it looks like lldb-server doesn't
implement the g packet.
llvm-svn: 331004
When I merged the 2 codepaths that return an OS type, I hade
checked that the places accepting 'iphoneos' would also accept
'ios', but then I got it backwards and return 'iphoneos'.
We use this value to build triples, and there 'iphoneos' is
invalid.
This also makes the test slightly simpler.
llvm-svn: 330877
Summary:
The new script to run the lldbtests as part of lit invokes each test by calling dotest.py, however, we cannot rely on the system to always correctly interpret the script as python causing the tests to be unresolved on windows (at least). To fix this, we need to make sure that the first parameter in the command line is the python executable itself.
In Makefile.rules, there are a number of windows specific definitions that rely on the HOST_OS being set as Windows_NT but the logic detecting the OS currently does not detect server versions of windows correctly. This change updates the logic to detect windows server as well.
Reviewers: asmith, labath, JDevlieghere, zturner
Reviewed By: JDevlieghere, zturner
Subscribers: zturner, llvm-commits
Differential Revision: https://reviews.llvm.org/D46020
llvm-svn: 330740
Summary:
In the magic test duplicator, we were making the decision whether to
create a test variant based on the compiler and the target platform.
This meant that the set of known tests was different for each test
configuration.
This patch makes the set of generated test variants static and handles
the skipping via runtime checks instead. This is more consistent with
how we do other test-skipping decision (e.g. for libc++ tests), and
makes it easier to expose the full set of tests to lit, which now does
not need to know anything about what things can potentially cause tests
to appear or disappear.
Reviewers: JDevlieghere, aprantl
Subscribers: eraman, lldb-commits
Differential Revision: https://reviews.llvm.org/D45949
llvm-svn: 330708
The isOverload() method needs to account for situations where the two
methods being compared don't have the same number of arguments.
rdar://problem/39542960
llvm-svn: 330450
It was failing because the modules names were coming out as
C:\Windows\System32/MSVCP120D.dll (last separator is a forward slash) on
windows.
There are two issues at play here:
- the first problem is that the paths in minidump were being parsed as a
host path. This meant that on posix systems the whole path was
interpreted as a file name.
- on windows the path was split into a directory-filename pair
correctly, but then when it was reconsituted, the last separator ended
up being a forward slash because SBFileSpec.fullpath was joining them
with '/' unconditionally.
I fix the first issue by parsing the minidump paths according to the
path syntax of the host which produced the dump, which should make the
test behavior on posix&windows identical. The last path will still be a
forward slash because of the second issue. We should probably fix the
"fullpath" property to do something smarter in the future.
llvm-svn: 330314
Normally, LLDB is creating a high-fidelity representation of a live
process, including a list of modules and sections, with the
associated memory address ranges. In order to build the module and
section map LLDB tries to locate the local module image (object file)
and will parse it.
This does not work for postmortem debugging scenarios where the crash
dump (minidump in this case) was captured on a different machine.
Fortunately the minidump format encodes enough information about
each module's memory range to allow us to create placeholder modules.
This enables most LLDB functionality involving address-to-module
translations.
Also, we may want to completly disable the search for matching
local object files if we load minidumps unless we can prove that the
local image matches the one from the crash origin.
(not part of this change, see: llvm.org/pr35193)
Example: Identify the module from a stack frame PC:
Before:
thread #1, stop reason = Exception 0xc0000005 encountered at address 0x164d14
frame #0: 0x00164d14
frame #1: 0x00167c79
frame #2: 0x00167e6d
frame #3: 0x7510336a
frame #4: 0x77759882
frame #5: 0x77759855
After:
thread #1, stop reason = Exception 0xc0000005 encountered at address 0x164d14
frame #0: 0x00164d14 C:\Users\amccarth\Documents\Visual Studio 2013\Projects\fizzbuzz\Debug\fizzbuzz.exe
frame #1: 0x00167c79 C:\Users\amccarth\Documents\Visual Studio 2013\Projects\fizzbuzz\Debug\fizzbuzz.exe
frame #2: 0x00167e6d C:\Users\amccarth\Documents\Visual Studio 2013\Projects\fizzbuzz\Debug\fizzbuzz.exe
frame #3: 0x7510336a C:\Windows\SysWOW64\kernel32.dll
frame #4: 0x77759882 C:\Windows\SysWOW64\ntdll.dll
frame #5: 0x77759855 C:\Windows\SysWOW64\ntdll.dll
Example: target modules list
Before:
error: the target has no associated executable images
After:
[ 0] C:\Windows\System32\MSVCP120D.dll
[ 1] C:\Windows\SysWOW64\kernel32.dll
[ 2] C:\Users\amccarth\Documents\Visual Studio 2013\Projects\fizzbuzz\Debug\fizzbuzz.exe
[ 3] C:\Windows\System32\MSVCR120D.dll
[ 4] C:\Windows\SysWOW64\KERNELBASE.dll
[ 5] C:\Windows\SysWOW64\ntdll.dll
NOTE: the minidump format also includes the debug info GUID, so we can
fill-in the module UUID from it, but this part was excluded from this change
to keep the changes simple (the LLDB UUID is hardcoded to be either 16 or
20 bytes, while the CodeView GUIDs are normally 24 bytes)
Differential Revision: https://reviews.llvm.org/D45700
llvm-svn: 330302
Summary:
If the remote stub sends a specific error message instead of just a E??
code, we can use this to display a more informative error message
instead of just the generic "unable to attach" message.
I write a test for this using the SB API.
On the console this will show up like:
(lldb) process attach ...
error: attach failed: <STUB-MESSAGE>
if the stub supports error messages, or:
error: attach failed: Error ??
if it doesn't.
Reviewers: jingham, JDevlieghere
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D45573
llvm-svn: 330247
We don't really care about the order as this is a dictionary.
It should be more resilient to changes (adding/shuffling stats
around).
Pointed out by Jason Molenda in a post-commit review (thanks Jason).
llvm-svn: 330170
This allows us to collect useful metrics about lldb debugging sessions.
I thought that an example would be better than a thousand words:
Process 19705 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = step in
frame #0: 0x0000000100000fb4 blah`main at blah.c:3
1 int main(void) {
2 int a = 6;
-> 3 return 0;
4 }
(lldb) statistics enable
(lldb) frame var a
(int) a = 6
(lldb) expr a
(int) $1 = 6
(lldb) statistics disable
(lldb) statistics dump
Number of expr evaluation successes : 1
Number of expr evaluation failures : 0
Number of frame var successes : 1
Number of frame var failures : 0
Future improvements might include:
1. Passing a file, or implementing categories. The way this patch has
been implemented is generic enough to allow this to be extended
easily without breaking the grammar.
2. Adding an SBAPI and Python API for use in scripts.
Thanks to Jim Ingham for discussing the design with me.
<rdar://problem/36555975>
Differential Revision: https://reviews.llvm.org/D45547
llvm-svn: 330043
Many IDEs set breakpoints using absolute paths and this causes problems when the full path of the source file path doesn't match what is in the debug info. This can be due to different build systems and do or do not resolve symlinks. This patch allows relative breakpoint to be set correctly without needing to do any target.source-map tricks. If IDEs want to, they can send down relative paths like:
./main.c
./src/main.c
src/main.c
foo/bar/src/main.c
I used the breakpoint resolver to match on the file basename and then we weed out anything whose relative paths don't match. This will be a huge improvement for IDEs as they can specify as much of a relative path as desired to uniquely identify a source file in the current project.
Differential Revision: https://reviews.llvm.org/D45592
llvm-svn: 330028
When we're dealing with virtual (memory) threads created by the OS
plugins, there's no guarantee that the real thread and the backing
thread share a protocol ID. Instead, we should iterate over the memory
threads to find the virtual thread that is backed by the current real
thread.
Differential revision: https://reviews.llvm.org/D45497
rdar://36485830
The original revision (r329891) was reverted because the associated
tests ran into a deadlock on the Linux bots. That problem was resolved
by r330002.
llvm-svn: 330005
When we're dealing with virtual (memory) threads created by the OS
plugins, there's no guarantee that the real thread and the backing
thread share a protocol ID. Instead, we should iterate over the memory
threads to find the virtual thread that is backed by the current real
thread.
Differential revision: https://reviews.llvm.org/D45497
rdar://36485830
llvm-svn: 329891
Summary:
With the upstream implementation of dsymutil containing almost all
functionality from the one shipped with Xcode, we want to use the
in-tree version for running the test suite.
This will also allow us to re-enable TestUnicodeSymbols which was
failing because of the discrepancy in how Unicode symbols were hashed in
lldb and older versions of dsymutil.
Reviewers: aprantl, davide, jingham, labath
Subscribers: mgorny, llvm-commits, lldb-commits
Differential Revision: https://reviews.llvm.org/D45518
llvm-svn: 329889
Summary:
In one of the 2 places the LC_BUILD_VERSION load command is handled, there
is a bug preventing us from actually handling them (the address where to
read the load command was not updated). This patch factors reading the
deployment target load commands into a helper and adds testing for the 2
code paths calling the helper.
The testing is a little bit complicated because the only times those load
commands matter is when debugging a simulator process. I added a new
decorator to check that a specific SDK is available. The actual testing was
fairly easy once I knew how to run a simulated process.
Reviewers: jasonmolenda, labath
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D45298
llvm-svn: 329374
Summary:
We would fail to resolve (and thus display the value of) any
templated type which contained a template template argument even
though we don't really use template arguments.
This patch adds minimal support for template template arguments,
but I doubt we need any more than that.
Reviewers: clayborg, jingham
Subscribers: JDevlieghere, lldb-commits
Differential Revision: https://reviews.llvm.org/D44613
llvm-svn: 328984
When importing C++ methods into clang AST nodes from the DWARF symbol
table, preserve the DW_AT_linkage_name and use it as the linker
("asm") name for the symbol.
Concretely, this enables `expression` to call into names that use the
GNU `abi_tag` extension, and enables lldb to call into code using
std::string or std::list from recent versions of libstdc++. See
https://bugs.llvm.org/show_bug.cgi?id=35310 . It also seems broadly
more robust than relying on the DWARF->clang->codegen pipeline to
roundtrip properly, but I'm not immediately aware of any other cases
in which it makes a difference.
Patch by Nelson Elhage!
Differential Revision: https://reviews.llvm.org/D40283
llvm-svn: 328658
The first issue was that the test was capturing the "before" disassembly
before launching, and the "after" after. This is a problem because some
of the disassembly will change after we know the load address (e.g. PCs
in call instructions). I fix this by capturing both disassemblies with
the process running.
The second issue was that the refactor in r328488 accidentaly changed
the meaning of the test, as it was no longer disassembling the function
which contained the breakpoint.
While inside, I also modernize the test to use
lldbutil.run_to_source_breakpoint and prevent debug-info replication.
llvm-svn: 328504
- close_fds is not compatible with stdin/out redirection on windows. I
just remove it, as this is not required for correct operation.
- the command string was assuming a posix shell. I rewrite the Popen
invocation to avoid the need for passing the arguments through a shell.
llvm-svn: 328489
Summary:
TestExprsChar.py
Char is unsigned char by default in PowerPC.
TestDisassembleBreakpoint.py
Modify disassemble testcase to consider multiple architectures.
TestThreadJump.py
Jumping directly to the return line on PowerPC architecture dos not
means returning the value that is seen on the code. The last test fails,
because it needs the execution of some assembly in the beginning of the
function. Avoiding this test for this architecture.
TestEhFrameUnwind.py
Implement func for ppc64le test case.
TestWatchLocation.py
TestStepOverWatchpoint.py
PowerPC currently supports only one H/W watchpoint.
TestDisassembleRawData.py
Add PowerPC opcode and instruction for disassemble testcase.
Reviewers: labath
Reviewed By: labath
Subscribers: davide, labath, alexandreyy, lldb-commits, luporl, lbianc
Differential Revision: https://reviews.llvm.org/D44472
Patch by Alexandre Yukio Yamashita <alexandre.yamashita@eldorado.org.br>.
llvm-svn: 328488
Summary: PPC64's auxvec has a special key that must be ignored.
Reviewers: clayborg, labath
Reviewed By: clayborg, labath
Subscribers: alexandreyy, lbianc
Differential Revision: https://reviews.llvm.org/D43771
Patch by Leandro Lupori <leandro.lupori@gmail.com>.
llvm-svn: 328486
Summary:
First attempt at landing D42145 was reverted because it caused test
failures on some android devices. It turned out this was because these
devices had vdso modules with differing physical and virtual addresses.
This was not caught earlier because all of the modules in our tests
either lack physical addresses or have them identical to virtual ones.
In the discussion on the patch, we came to the conclusion that in the
scenario where we are merely setting a load address of a module (for
example from a dynamic loader plugin), we should always use virtual
addresses (i.e., preserve status quo). This patch adds a test to make
sure we don't regress in that direction.
Reviewers: owenpshaw
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D44738
llvm-svn: 328485
- postmortem tests: make sure the core files are created in the build
folder
- TestSourceManager: copy the .c file into the build dir before
modifying it
- TestLogging: create log files in the build folder
After these changes I get a clean test run (on linux) even if I set the
source tree to be read only. It's possible some of the skipped/xfailed
tests are still creating files in the source tree, but at the moment, I
don't have plans to go hunting for those.
llvm-svn: 328106
- use more goodies from Makefile.rules to correctly build a 32-bit
binary.
- avoid hardcoding typeof(nil) in the test.
This should partially fix the linux bot. There is still one assertion
failure remaining, which I'll have to investigate separately, as I am
not experiencing it locally.
llvm-svn: 328083
Pavel Labath