One considers it integer division, the other doesn't.
Move to `//` (floor division) so that this test passes
independently from the version.
llvm-svn: 352706
Summary:
When we are creating a ClassTemplateSpecializationDecl in ParseTypeFromDWARF(...) we are not handling the case where variadic pack is empty in the specialization. This patch handles that case and adds a test to prevent future regressions.
Differential Revision: https://reviews.llvm.org/D57363
llvm-svn: 352677
This fixes most references to the paths:
llvm.org/svn/
llvm.org/git/
llvm.org/viewvc/
github.com/llvm-mirror/
github.com/llvm-project/
reviews.llvm.org/diffusion/
to instead point to https://github.com/llvm/llvm-project.
This is *not* a trivial substitution, because additionally, all the
checkout instructions had to be migrated to instruct users on how to
use the monorepo layout, setting LLVM_ENABLE_PROJECTS instead of
checking out various projects into various subdirectories.
I've attempted to not change any scripts here, only documentation. The
scripts will have to be addressed separately.
Additionally, I've deleted one document which appeared to be outdated
and unneeded:
lldb/docs/building-with-debug-llvm.txt
Differential Revision: https://reviews.llvm.org/D57330
llvm-svn: 352514
This makes it easier to exclude the test n bots that test earlier
DWARF formats, also it feels like this is the better decision for this
testcase anyway.
llvm-svn: 352111
We figured out the issue so the logging is no longer necessary. It turns
out we were using a session format that was not unique for inline tests.
llvm-svn: 351902
The new LLVM header is one line shorter than the old one, which lead to
some test failures. Ideally tests should rely on line numbers for
breakpoints or output, but that's a different discussion. Hopefully this
turns the bots green again.
llvm-svn: 351779
to reflect the new license.
We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.
Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.
llvm-svn: 351636
We're seeing an odd issue on GreenDragon's lldb-cmake-matrix. Dotest is
unable to move a log file (OSError: [Errno 2] No such file or
directory). The os.rename call is guarded with a check that the source
file and destination directory exist.
This wraps the call in a try-except that prints the source and
destination path to see which component seemingly doesn't exist.
llvm-svn: 351611
This patch changes the behavior when printing C++ function references:
where we previously would get a <could not determine size>, there is
now a <no summary available>. It's not clear to me whether this is a
bug or an omission, but it's one step further than LLDB previously
got.
Differential Revision: https://reviews.llvm.org/D56798
llvm-svn: 351376
Summary:
This patch allows to retrieve an address object for `ValueObject`'s children
retrieved through e.g. `GetChildAtIndex` or `GetChildMemberWithName`. It just
uses the corresponding method of the implementation object `m_impl` to achieve
that.
Reviewers: zturner, JDevlieghere, clayborg, labath, serge-sans-paille
Reviewed By: clayborg
Subscribers: leonid.mashinskiy, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D56147
llvm-svn: 351065
Summary:
In python 2, strings and bytes are the same, but they're not in
python 3, hence the return of read() needs an explicit conversion.
While I'm around, rename the return of Popen() from `pipe` to
`process`, as that's what Popen returns.
Reviewers: JDevlieghere, friss, zturner, aprantl, serge-sans-paille
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D56517
llvm-svn: 350788
There is already in use:
lit/lit-lldb-init:
settings set symbols.enable-external-lookup false
packages/Python/lldbsuite/test/lldbtest.py:
self.runCmd('settings set symbols.enable-external-lookup false')
But those are not in effect during MI part of the testsuite. Another problem is
that symbols.enable-external-lookup (read by GetEnableExternalLookup) has been
currently read only by LocateMacOSXFilesUsingDebugSymbols and therefore it had
no effect on Linux.
On Red Hat platforms (Fedoras, RHEL-7) there is DWZ in use and so
MiSyntaxTestCase-test_lldbmi_output_grammar FAILs due to:
AssertionError: error: inconsistent pattern ''^.+?\n'' for state 0x5f
(matched string: warning: (x86_64) /lib64/libstdc++.so.6 unsupported
DW_FORM values: 0x1f20 0x1f21
It is the only testcase with this error. It happens due to:
(lldb) target create "/lib64/libstdc++.so.6"
Current executable set to '/lib64/libstdc++.so.6' (x86_64).
(lldb) b main
warning: (x86_64) /lib64/libstdc++.so.6 unsupported DW_FORM values: 0x1f20 0x1f21
Breakpoint 1: no locations (pending).
WARNING: Unable to resolve breakpoint to any actual locations.
which happens only with gcc-base-debuginfo rpm installed (similarly for other packages).
It should also speed up the testsuite as it no longer needs to read
/usr/lib/debug symbols which have no effect (and should not have any effect) on
the testsuite results.
Differential Revision: https://reviews.llvm.org/D55859
llvm-svn: 350368
TestQueues is failing randomly on green dragon and I suspect it is
because the enqueued threads haven't executed by the time we expect
them. This patch adds file-based synchronization to the queues.
Differential Revision: https://reviews.llvm.org/D56208
llvm-svn: 350247
python 3.7 removes re._pattern_type. Fix the one place where we were
depending on the type of regular expressions to compute the type
dynamically.
llvm-svn: 350093
They both run the same command, and people get used to typing the shortest
string they can, so we should support alias info on shortened strings as well.
<rdar://problem/46859207>
llvm-svn: 349874
These are tests that found actual, but hard to fix, bugs that are
tracked elsewhere. Leaving them red only distracts from new failures
this bot finds.
llvm-svn: 349851
This is a set of tests that were all marked as failing becuse of pr24764. The bug is not fixed (as in more of the tests that were marked this way are failing), but this set is passing. It is possible that some of them are false positives, but there's a large number of unexpectedly passing tests on Windows, so I am doing a bulk un-xfail to get the buildbot to green.
llvm-svn: 349719
This builds on https://reviews.llvm.org/D43884 and https://reviews.llvm.org/D43886 and extends LLDB support of Obj-C exceptions to also look for a "current exception" for a thread in the C++ exception handling runtime metadata (via call to __cxa_current_exception_type). We also construct an actual historical SBThread/ThreadSP that contains frames from the backtrace in the Obj-C exception object.
The high level goal this achieves is that when we're already crashed (because an unhandled exception occurred), we can still access the exception object and retrieve the backtrace from the throw point. In Obj-C, this is particularly useful because a catch+rethrow is very common and in those cases you currently don't have any access to the throw point backtrace.
Differential Revision: https://reviews.llvm.org/D44072
llvm-svn: 349718
This is a set of tests that were all marked as failing becuse of several different bugs. A couple of the bugs are now resolved as fixed since all the tests that were failing associated with the bug are now passing. It is possible that some of them are false positives, but there's a large number of unexpectedly passing tests on Windows, so I am doing a bulk un-xfail to get the buildbot to green.
llvm-svn: 349713
This is a set of tests that were all marked as failing becuse of several different bugs. A couple of the bugs are now resolved as fixed since all the tests that were failing associated with the bug are now passing. It is possible that some of them are false positives, but there's a large number of unexpectedly passing tests on Windows, so I am doing a bulk un-xfail to get the buildbot to green.
llvm-svn: 349711
This is a set of tests that were all marked as failing becuse of pr21765. The bug is not fixed (as in more of the tests that were marked this way are failing), but this set is passing. It is possible that some of them are false positives, but there's a large number of unexpectedly passing tests on Windows, so I am doing a bulk un-xfail to get the buildbot to green.
llvm-svn: 349668
This is a set of tests that were all marked as failing becuse of pr24489. The bug is not fixed (as in more of the tests that were marked this way are failing), but this set is passing. It is possible that some of them are false positives, but there's a large number of unexpectedly passing tests on Windows, so I am doing a bulk un-xfail to get the buildbot to green.
llvm-svn: 349665
Prior to this change we would show the name of the section that a memory region belonged to but not its actual region name. Now we show this,. Added a test that reuses the regions-linux-map.dmp minidump file to test this and verify the correct region names for various memory regions.
Differential Revision: https://reviews.llvm.org/D55854
llvm-svn: 349658
Currently spawnLldbMi accepts both lldb-mi options and executable to debug as
a single parameter. Split them.
As in D55859 we will need to execute one lldb-mi command before loading the
exe. Therefore we can no longer use the exe as lldb-mi command-line parameter
as then there is no way to execute a command before loading exe specified as
lldb-mi command-line parameter.
LocateExecutableSymbolFileDsym should be static, that is also a little
refactorization.
Differential Revision: https://reviews.llvm.org/D55858
llvm-svn: 349607
the "self.assertEqual(thread.GetStopReason(), lldb.eStopReasonSignal)"
was occasionally failing because the stop reason would come out as
"trace" this happened if we issued the interrupt just as the processed
stopped due to single-stepping over the breakpoint (i.e., the it was not
necessary to send any signal).
Fix this by removing the breakpoint before resuming the process. This
ensures the process can run unobstructed.
After this, the test passed 200 consecutive runs successfully for me,
even while the system was under heavy load.
llvm-svn: 349491
This test was disabled in r326756 as a part of "upstreaming debugserver
support for AVX-512 (zmm register set)". This looks like an error
because both register set and remote stubs are different.
In any case, the test passes now.
llvm-svn: 349485
This test is passing now on linux. The same test is claimed to be flaky
on darwin, so it's possible that's true on linux too. If that's the case
we'll have to skip it here too (or fix it).
I mark the test as not-debug-info-dependent as a drive-by.
llvm-svn: 349482
These tests are now passing on linux, at least with top-of-tree clang,
clang-6 and gcc-7.3. It's possible it may still be failing with some
older compilers, but I don't have those around to test.
llvm-svn: 349478
make the executable name more unique.
This test is failing sporadically on some bots. By removing the sleep
synchronisation, I'm hoping to get it to fail more reproducibly so I
can investigate what is going on.
llvm-svn: 349397
While I was out hunting for remaining pexpect-based tests, I came
across these tests that can't possibly work an any modern system, as
they rely on having gdb available in /Developer.
This patch simply removes the test without replacement.
Differential Revision: https://reviews.llvm.org/D55559
llvm-svn: 349194
This re-commits r348592, which was reverted due to a failing test on
macos.
The issue was that I was passing a null pointer for the
"CreateMemoryInstance" callback when registering ObjectFileBreakpad,
which caused crashes when attemping to load modules from memory. The
correct thing to do is to pass a callback which always returns a null
pointer (as breakpad files are never loaded in inferior memory).
It turns out that there is only one test which exercises this code path,
and it's mac-only, so I've create a new test which should run everywhere
(except windows, as one cannot delete an executable which is being run).
Unfortunately, this test still fails on linux for other reasons, but at
least it gives us something to aim for.
The original commit message was:
This patch adds the scaffolding necessary for lldb to recognise symbol
files generated by breakpad. These (textual) files contain just enough
information to be able to produce a backtrace from a crash
dump. This information includes:
- UUID, architecture and name of the module
- line tables
- list of symbols
- unwind information
A minimal breakpad file could look like this:
MODULE Linux x86_64 0000000024B5D199F0F766FFFFFF5DC30 a.out
INFO CODE_ID 00000000B52499D1F0F766FFFFFF5DC3
FILE 0 /tmp/a.c
FUNC 1010 10 0 _start
1010 4 4 0
1014 5 5 0
1019 5 6 0
101e 2 7 0
PUBLIC 1010 0 _start
STACK CFI INIT 1010 10 .cfa: $rsp 8 + .ra: .cfa -8 + ^
STACK CFI 1011 $rbp: .cfa -16 + ^ .cfa: $rsp 16 +
STACK CFI 1014 .cfa: $rbp 16 +
Even though this data would normally be considered "symbol" information,
in the current lldb infrastructure it is assumed every SymbolFile object
is backed by an ObjectFile instance. So, in order to better interoperate
with the rest of the code (particularly symbol vendors).
In this patch I just parse the breakpad header, which is enough to
populate the UUID and architecture fields of the ObjectFile interface.
The rough plan for followup patches is to expose the individual parts of
the breakpad file as ObjectFile "sections", which can then be used by
other parts of the codebase (SymbolFileBreakpad ?) to vend the necessary
information.
Reviewers: clayborg, zturner, lemo, amccarth
Subscribers: mgorny, fedor.sergeev, markmentovai, lldb-commits
Differential Revision: https://reviews.llvm.org/D55214
llvm-svn: 348773
Summary:
r348240 assumes that an expression contains the Objective C option if
Objective C Runtime is found. But on MacOS X it seems that the test application
process always contains Objective C Runtime, so the test fails when it assumes
that the language is C++ only. Skip this part on Darwin.
llvm-svn: 348250
Summary:
This patch adds the check of the language before ignoring names like `id` or
`Class`, which are reserved in Objective C, but are allowed in C++. It is needed
to make it possible to evaluate expressions in a C++ program containing names
like `id` or `Class`.
Reviewers: jingham, zturner, labath, clayborg
Reviewed By: jingham, clayborg
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D54843
llvm-svn: 348240
This patch changes the way the reproducer is initialized. Rather than
making changes at run time we now do everything at initialization time.
To make this happen we had to introduce initializer options and their SB
variant. This allows us to tell the initializer that we're running in
reproducer capture/replay mode.
Because of this change we also had to alter our testing strategy. We
cannot reinitialize LLDB when using the dotest infrastructure. Instead
we use lit and invoke two instances of the driver.
Another consequence is that we can no longer enable capture or replay
through commands. This was bound to go away form the beginning, but I
had something in mind where you could enable/disable specific providers.
However this seems like it adds very little value right now so the
corresponding commands were removed.
Finally this change also means you now have to control this through the
driver, for which I replaced --reproducer with --capture and --replay to
differentiate between the two modes.
Differential revision: https://reviews.llvm.org/D55038
llvm-svn: 348152
Summary:
This patch contains several small fixes, which makes it possible to evaluate
expressions on Windows using information from PDB. The changes are:
- several sanitize checks;
- make IRExecutionUnit::MemoryManager::getSymbolAddress to not return a magic
value on a failure, because callers wait 0 in this case;
- entry point required to be a file address, not RVA, in the ObjectFilePECOFF;
- do not crash on a debuggee second chance exception - it may be an expression
evaluation crash. Also fix detection of "crushed" threads in tests;
- create parameter declarations for functions in AST to make it possible to call
debugee functions from expressions;
- relax name searching rules for variables, functions, namespaces and types. Now
it works just like in the DWARF plugin;
- fix endless recursion in SymbolFilePDB::ParseCompileUnitFunctionForPDBFunc.
Reviewers: zturner, asmith, stella.stamenova
Reviewed By: stella.stamenova, asmith
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D53759
llvm-svn: 348136
The test assumes that HW breakpoints are not implemented by the debug
server. Windows doesn't use these and might actually support HW
breakpoints so these tests are expected fail because they don't raise
the expected error.
llvm-svn: 348010
Summary:
This patch fixes the next situation. On Windows clang-cl makes no stub before
the main function, so the main function is located exactly on module entry
point. May be it is the same on other platforms. So consider the following
sequence:
- set a breakpoint on main and stop there;
- try to evaluate expression, which requires a code execution on the debuggee
side. Such an execution always returns to the module entry, and the plan waits
for it there;
- the plan understands that it is complete now and removes its breakpoint. But
the breakpoint site is still there, because we also have a breakpoint on
entry;
- StopInfo analyzes a situation. It sees that we have stopped on the breakpoint
site, and it sees that the breakpoint site has owners, and no one logical
breakpoint is internal (because the plan is already completed and it have
removed its breakpoint);
- StopInfo thinks that it's a user breakpoint and skips it to avoid recursive
computations;
- the program continues.
So in this situation the program continues without a stop right after
the expression evaluation. To avoid this an additional check that
the plan was completed was added.
Reviewers: jingham, zturner, boris.ulasevich
Reviewed by: jingham
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D53761
llvm-svn: 347974
Earlier this month there was a change in clang that defaulted to using codeview rather than dwarf on Windows. Since all the tests rely on dwarf, we need to explicitly request dwarf when building on Windows.
llvm-svn: 347924
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
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
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
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
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
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
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
Jonas Devlieghere