| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 331270
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 331242
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
| |
type that must exist at root level
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
|
|
|
|
|
|
| |
llvm.org/pr37194
llvm-svn: 330504
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 328721
|
|
|
|
|
|
|
| |
For some reason on one of our bots subprocess wasn't already
imported. Do so explicitly.
llvm-svn: 328715
|
|
|
|
|
|
| |
<rdar://problem/36035075>, <rdar://problem/36035039>
llvm-svn: 328389
|
|
|
|
|
|
|
|
|
|
|
|
| |
- 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
|
|
|
|
|
|
|
|
| |
New tests should run the make syntax voodoo $@ and $<
instead of hardcoding the names. We should also document
how to write one, it's on my list.
llvm-svn: 328062
|
|
|
|
|
|
|
|
|
|
|
|
| |
Instead of applying the sledgehammer of refusing to insert any
C++ symbol in the ASTContext, try to validate the decl if what
we have is an operator. There was other code in lldb which was
responsible for this, just not really exposed (or used) in this
codepath. Also, add a better/more comprehensive test.
<rdar://problem/35645893>
llvm-svn: 328025
|
|
|
|
| |
llvm-svn: 327924
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
decl context.
Summary:
When in a gmodules-like debugging scenario, you can have a parent decl context
that gets imported from an external AST. When this happens, we must be careful
to complete this type before adding children to it, otherwise it sometimes
results in a crash.
Reviewers: clayborg, jingham
Subscribers: aprantl, JDevlieghere, lldb-commits
Differential Revision: https://reviews.llvm.org/D43592
llvm-svn: 327750
|
|
|
|
| |
llvm-svn: 327729
|
|
|
|
| |
llvm-svn: 327644
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Until we have a better story for putting commands and check lines
in the same file (they're currently ignored), it seems that inline
tests are actually more concise and easier to understand.
Too bad we have still some python boilerplate, but that's not
really substantial so we can live with it.
Thanks to Fred for pointing out and Jim for explaining me how
to use the inline test format.
<rdar://problem/34806516>
llvm-svn: 327592
|
|
|
|
|
|
|
| |
This removes around 10 references to Apple-internal radars. I've filed
fresh bugs on bugs.llvm.org as appropriate for open issues.
llvm-svn: 327463
|
|
|
|
|
|
|
|
| |
I want to extend the properties on ModuleList to also contain other
more general settings and renaming the settings category to symbols
seems to be the least bad of choices.
llvm-svn: 327193
|
|
|
|
|
|
|
|
| |
There is a mailing list discussion re: r325927 about why this test fails
in the dsym variant. I've marked it skipped for now, until the issue is
resolved.
llvm-svn: 327089
|
|
|
|
| |
llvm-svn: 326640
|
|
|
|
|
|
|
| |
It isn't actually necessary for what we are testing here and should
fix the test on the Linux bots.
llvm-svn: 326634
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It turns out that setting the clang module cache after LLDB has a
Target can be too late. In particular, the Swift language plugin needs
to know the setting without having access to a Target. This patch
moves the setting into the *LLDB* module cache, where it is a global
setting that is available before any Target is created and more
importantly, is shared between all Targets.
rdar://problem/37944432
Differential Revision: https://reviews.llvm.org/D43984
llvm-svn: 326628
|
|
|
|
|
|
|
|
|
|
| |
gcc will say that the type of "this" is "T * const", clang "T *".
Compare the unqualified type names to erase the difference between the
two, as the constness is not a part of this test.
FWIW, I think that the gcc behavior makes more sense here.
llvm-svn: 326449
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
same basename.
There's a bug in FindTypes, it ignores the exact flag if you pass a name that doesn't begin with
:: and pass eTypeClassAny for the type.
In this case we always know that the name we get from the vtable name is absolute so we can
work around the bug by prepending the "::". This doesn't fix the FindTypes bug.
<rdar://problem/38010986>
llvm-svn: 326412
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Merge branch 'master' into adaptPPC64tests
Reviewers: clayborg, alexandreyy, labath
Reviewed By: clayborg, alexandreyy
Subscribers: luporl, lbianc, alexandreyy, lldb-commits
Differential Revision: https://reviews.llvm.org/D42917
Patch by Ana Julia Caetano <ana.caetano@eldorado.org.br>.
llvm-svn: 326369
|
|
|
|
|
|
|
|
|
|
|
|
| |
Further investigation required; tests will be enabled on the buildbot
worker soon. Marking failing tests for now in order to start with a
green buildbot while investigation takes place.
This is a recommit of r326134, with the required import added.
llvm.org/pr36527
llvm-svn: 326166
|
|
|
|
|
|
|
|
|
|
|
| |
When writing an inline test, there is no way to make sure that any of
the inline commands are actually executed, so this patch adds a sanity
check that at least one breakpoint was hit. This avoids a test with no
breakpoints being hit passing.
Differential Revision: https://reviews.llvm.org/D43694
llvm-svn: 326140
|
|
|
|
| |
llvm-svn: 326139
|
|
|
|
|
|
|
|
|
|
| |
Further investigation required; tests will be enabled on the buildbot
worker soon. Marking failing tests for now in order to start with a
green buildbot while investigation takes place.
llvm.org/pr36527
llvm-svn: 326134
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Without this fix, the test ERRORs because the link of the inferior fails. This
patch adds the LLDB_TEST_API macro where needed and uses the new -2 magic
value for num_expected_locations to account for lazy-loading of module symbols
on Windows.
With this fix, the test itself still fails: conflicting_symbol isn't in the
debug info nor the export table, and Windows binaries don't have an equivalent
of the ELF .symtab. We need to understand why the test works to keep the
symbol out of the debug info. In the mean time, having the test fail at this
point is a better indication of the remaining problem than a build error.
Differential Revision: https://reviews.llvm.org/D43688
llvm-svn: 326130
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D43705
llvm-svn: 326095
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The llvm function is equivalent to this one. Where possible I tried to
replace const char* with llvm::StringRef to avoid extra strlen
computations. In most places, I was able to track the c string back to
the ConstString it was created from.
I also create a test that verifies we are able to lookup names with
unicode characters, as a bug in the llvm compiler (it accidentally used
a different hash function) meant this was not working until recently.
This also removes the unused ExportTable class.
Reviewers: aprantl, davide
Subscribers: JDevlieghere, lldb-commits
Differential Revision: https://reviews.llvm.org/D43596
llvm-svn: 325927
|
|
|
|
|
|
|
|
| |
The reason this test was disabled is no longer relevant. However, it
didn't turn into an unexpected success because of a syntax error in the
test itself. This commit fixes that and re-enables the test.
llvm-svn: 325339
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Update makefiles to specify -fPIC in Makefile.rules and only throw -fPIC when building a shared library. This change is necessary to allow building the lldb tests on Windows where -fPIC is not a valid option.
Update a few places to Python 3.x syntax
Reviewers: zturner, lldb-commits
Reviewed By: zturner
Subscribers: stella.stamenova, labath, llvm-commits
Differential Revision: https://reviews.llvm.org/D42994
llvm-svn: 324671
|
|
|
|
|
|
|
|
| |
TODO: Add a separate testcase testing *only* Foundation implementation details!
<rdar://problem/37252738>
llvm-svn: 324655
|
|
|
|
| |
llvm-svn: 324293
|
|
|
|
|
|
|
|
| |
(a while ago).
<rdar://problem/20416388>
llvm-svn: 324280
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch is the result of a discussion on lldb-dev, see
http://lists.llvm.org/pipermail/lldb-dev/2018-January/013111.html for
background.
For each test (should be eventually: each test configuration) a
separate build directory is created and we execute
make VPATH=$srcdir/path/to/test -C $builddir/path/to/test -f $srcdir/path/to/test/Makefile -I $srcdir/path/to/test
In order to make this work all LLDB tests need to be updated to find
the executable in the test build directory, since CWD still points at
the test's source directory, which is a requirement for unittest2.
Although we have done extensive testing, I'm expecting that this first
attempt will break a few bots. Please DO NOT HESITATE TO REVERT this
patch in order to get the bots green again. We will likely have to
iterate on this some more.
Differential Revision: https://reviews.llvm.org/D42281
llvm-svn: 323803
|
|
|
|
|
|
| |
It fails due to an assertion (if these are enabled).
llvm-svn: 323736
|
|
|
|
|
|
|
|
|
|
|
| |
TestLibcxxListLoop - fails because the evil "define private public"
trick does not work with gmodules. The purpose of the test is not to
test debug info parsing so I just mark it as no_debug_info_testcase.
In the long term it may be interesting to write a mock std::list which
will allow us to test bad inputs to data formatters more easily.
TestGModules - seems to be a genuine bug. Filed pr36107 and xfailed.
llvm-svn: 323520
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Stale global module caches cause problems for the bots. The modules
become invalid when clang headers are updated by version control, and
tests which use these modules fail to compile, e.g:
fatal error: file '.../__stddef_max_align_t.h' has been modified since the module file '/var/.../Darwin.pcm' was built
note: please rebuild precompiled header '/var/.../Darwin.pcm'
Eventually we should transition to having just a single module cache to speed
tests up. This patch should be just enough to fix the spurious bot failures due
to stale caches.
rdar://36479805, also related to llvm.org/PR36048
Differential Revision: https://reviews.llvm.org/D42277
llvm-svn: 323450
|
|
|
|
|
|
|
|
|
| |
in TestBase::getBuildArtifact(). This NFC commit is in preparation for
https://reviews.llvm.org/D42281 (compile the LLDB tests out-of-tree).
Differential Revision: https://reviews.llvm.org/D42280
llvm-svn: 323007
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Due to an unfortunate difference between the open source test harness
and our internal harness, applying two @skip... decorators to this test
works in the internal build but not in the open source build.
I've tried another approach to skipping this test and tested it out with
the open source harness. Hopefully this sticks!
rdar://36417163
llvm-svn: 322756
|
|
|
|
|
|
| |
rdar://36417163
llvm-svn: 322740
|
|
|
|
|
|
|
|
|
|
| |
This test frequently times out on our bots. While we're investigating
the issue, mark the test as skipped so the builds aren't impacted as
much.
rdar://36417163
llvm-svn: 322728
|