Starting with android ndk r15, clang much more tests are affected by the
-mstackrealign bugl (now nearly all functions are affected, and not just
the ones requiring 16-byte alignment). Due to their numbers, Xfailing
all of them is not a viable option, so we will just have to declare this
configuration unsupported, and wait until ndk ships a clang version that
has this bug fixed.
llvm-svn: 307252
to make a target, set a source regex breakpoint, run to
the breakpoint and find the thread that hit the breakpoint.
Start the process of replacing the boiler plate with this
routine.
llvm-svn: 307234
This adds a simple testcase for MainThreadCheckerRuntime. The tool (Main Thread Checker) is only available on Darwin, so the test also detects the presence of libMainThreadChecker.dylib and is skipped if the tool is not available.
llvm-svn: 307170
All android builds systems have switched to -mstackrealign for building
x86 binaries, so follow their cue with our mini build system.
This presently breaks just one test (TestReturnValue), and this is due
to a compiler bug, which has already been fixed in clang, but it hasn't
made it yet into the official NDK compiler. While I'm touching that
test, I also remove an android-specific XFAIL, which is not relevant
anymore.
llvm-svn: 306683
components to not depend on "." characters in the fileanme
(e.g. "Foundation.framework") but instead to just use path
separators. The names of the files themselves may have dots
in them ("com.apple.sbd") which would break the old scheme.
Also add a test case for this (macosx/find-dsym/bundle-with-dot-in-filename)
as well as a test case for r304520 (macosx/find-dsym/deep-bundle)
which needed a similar setup to test correctly on a single machine.
(both of these are really testing remote debug session situations
where the binary can't be found on the system where lldb is running,
complicating the test case a bit.)
<rdar://problem/31825940>
llvm-svn: 305441
NSString is loaded from the DWARF, which doesn't have the concept of protocols.
When this is used with the NSMutableDictionary type from Objective-C modules,
this produces errors of the form
error: cannot initialize a parameter of type 'id<NSCopying> _Nonnull' with an rvalue of type 'NSString *'
We're aware of these problems and have an internal bug report filed
(<rdar://problem/32777981>)
llvm-svn: 305424
The step count depends on code generated by compiler (GCC/Clang).
It will also vary for different MIPS arch variant. Hence skipping these test for MIPS.
Subscribers: jaydeep, bhushan, lldb-commits, slthakur
llvm-svn: 305383
Clang does not accept regparm attribute on these platforms.
Fortunately, the default calling convention passes arguments
in registers any way
Subscribers: jaydeep, bhushan, lldb-commits, slthakur
llvm-svn: 305378
This test started being flaky since r303848 (RunThreadPlan: Fix halting
logic in IgnoreBreakpoints = false). I am not reverting that, as I am
confident that actually fixed a problem. A more likely explanation is
that there is still one corner case that is not handled correctly there.
Marking the test as flaky until I get a chance to investigate. I also
mark the test as no-debug-info-dependend -- it stresses expression
evaluation, as far as debug info goes, the test if extremely simple.
llvm-svn: 305286
This patch introduces a new thread backtrace command "unique".
The command is based off of "thread backtrace all" but will instead
find all threads which share matching call stacks and de-duplicate
their output, listing call stack and all the threads which share it.
This is especially useful for apps which use thread/task pools
sitting around waiting for work and cause excessive duplicate output.
I needed this behavior recently when debugging a core with 700+ threads.
Differential Revision: https://reviews.llvm.org/D33426
Reviewers: clayborg, jingham
Patch by Brian Gianforcaro <b.gianfo@gmail.com>
llvm-svn: 305197
I was over-eager to unable this test in r304976. It still fails in this
combination, at there does not seem to be anything we can do about it,
as the generated code does not preserve the link register.
llvm-svn: 305062
Summary:
When a call instruction is the last instruction in a function, the
backtrace PC will point past the end of the function. We already had
special code to handle that, but we did not handle the case where the PC
ends up outside of the bounds of the module containing the function,
which is a situation that occured in TestNoreturnUnwind on android for
some arch/compiler combinations.
I fix this by adding an argument to Address resolution code which states
that we are ok with addresses pointing to the end of a module/section to
resolve to that module/section.
I create a reproducible test case for this situation by hand-crafting an
executable which has a noreturn function at the end of a module.
Reviewers: jasonmolenda, jingham
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D32022
llvm-svn: 304976
When parsing types originating in modules, it is possible to encounter AttributedTypes
(such as the type generated for NSString *_Nonnull). Some of LLDB's ClangASTContext
methods deal with them; others do not. In particular, one function that did not was
GetTypeInfo, causing TestObjCNewSyntax to fail.
This fixes that, treating AttributedType as essentially transparent and getting the
information for the modified type.
In addition, however, TestObjCNewSyntax is a monolithic test that verifies a bunch of
different things, all of which can break independently of one another. I broke it
apart into smaller tests so that we get more precise failures when something (like
this) breaks.
Differential Revision: https://reviews.llvm.org/D33812
llvm-svn: 304510
This works on SVN but is a bit fragile on the Swift branch.
I'm adding the test to both, so we have this path covered.
<rdar://problem/32372372>
llvm-svn: 304314
Summary:
- Added API to access data types
-- integer, double, array, string, boolean and dictionary data types
-- Earlier user had to parse through the string output to get these
values
- Added Test cases for API testing
- Added new StructuredDataType enum in public include file
-- Replaced locally-defined enum in StructuredData.h with this new
one
-- Modified other internal files using this locally-defined enum
Signed-off-by: Abhishek Aggarwal <abhishek.a.aggarwal@intel.com>
Reviewers: clayborg, lldb-commits
Reviewed By: clayborg
Subscribers: labath
Differential Revision: https://reviews.llvm.org/D33434
llvm-svn: 304138
This is a resubmit of r303732, which was reverted due to a regression.
The original patch caused a regression in TestLoadUnload, which has only showed
up when running the remote test suite. The problem there was that we interrupted
the target just as it has hit the rendezvous breakpoint in the dlopen call. This
meant that the stop reason was set to "breakpoint" even though the event would
not have been broadcast if we had not stopped the process. I fix this by
checking StopInfo->ShouldNotify() before stopping.
I also add a new test for the handling of conditional breakpoints in
expressions, which I noticed to be broken (pr33164)
Differential Revision: https://reviews.llvm.org/D33283
llvm-svn: 303848
Summary:
The function had logic to handle the case when the expression terminated
while we were trying to halt the process, but it failed to take into
account the possibility that the expression stopped because it hit a
breakpoint. This was caused by the fact that the handling of the stopped
events was duplicated for the "halting" and regular cases (the regular
case handled this situation correctly). I've tried to merge these two
cases into one to make sure they stay in sync.
I should call out that the two cases were checking whether the thread
plan has completed in slightly different ways. I am not sure what is the
difference between them, but I think the check should be the same in
both cases, whatever it is, so I just took the one from the regular
case, as that is probably more tested.
For the test, I modified TestUnwindExpression to run the expression with
a smaller timeout (this is how I found this bug originally). With a 1ms
one thread timeout, the test failed consistently without this patch.
Reviewers: jingham
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D33283
llvm-svn: 303732
For remote targets we need to call registerSharedLibrariesWithTarget to
make sure they are installed alongside main executable. This also
required a small fixup in the the mentioned function as in this case
"One" was both a directory name and a library name template. I fixed it
to make sure it checks that the string refers to a file before it
assumed it was a full library path.
llvm-svn: 303248
When it resolves symbol-only variables, the expression parser
currently looks only in the global module list. It should prefer
the current module.
I've fixed that behavior by making it search the current module
first, and only search globally if it finds nothing. I've also
added a test case.
After review, I moved the core of the lookup algorithm into
SymbolContext for use by other code that needs it.
Thanks to Greg Clayton and Pavel Labath for their help.
Differential Revision: https://reviews.llvm.org/D33083
llvm-svn: 303223
ptr_refs exposed a problem in ClangASTContext's implementation: it
uses an accessor to downcast a QualType to an
ObjCObjectPointerType, but the accessor is not fully general.
getAs() is the safer way to go.
I've added a test case that uses ptr_refs in a way that would
crash before the fix.
<rdar://problem/31363513>
llvm-svn: 303110
as described in pr33042, we cannot reliably retrieve the return value on
arm64 in cases it is returned via x8 pointer. I tried to do this as
surgically as possible and disabled it only on targets I know to be
affected, as the code is still useful, even though it can only work on
best-effort basis.
llvm-svn: 303076
Templates can end in parameter packs, like this
template <class T...> struct MyStruct
{ /*...*/ };
LLDB does not currently support these parameter packs;
it does not emit them into the template argument list
at all. This causes problems when you specialize, e.g.:
template <> struct MyStruct<int>
{ /*...*/ };
template <> struct MyStruct<int, int> : MyStruct<int>
{ /*...*/ };
LLDB generates two template specializations, each with
no template arguments, and then when they are imported
by the ASTImporter into a parser's AST context we get a
single specialization that inherits from itself,
causing Clang's record layout mechanism to smash its
stack.
This patch fixes the problem for classes and adds
tests. The tests for functions fail because Clang's
ASTImporter can't import them at the moment, so I've
xfailed that test.
Differential Revision: https://reviews.llvm.org/D33025
llvm-svn: 302833
Summary:
'arch' is a valid qHostInfo key, but the unit
test for qHostInfo did not include it in the set of possible keys.
Reviewers: tfiala, labath
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D32711
llvm-svn: 302260
Summary:
I have found a way to segfault lldb in 7 keystrokes! Steps to reproduce:
1) Launch lldb
2) Type `print` and hit enter. lldb will now prompt you to type a list of
expressions, followed by an empty line.
3) Hit enter, indicating the end of your input.
4) Segfault!
After some investigation, I've found the issue in Host/common/Editline.cpp.
Editline::MoveCursor() relies on m_input_lines not being empty when the `to`
argument is CursorPosition::BlockEnd. This scenario, as far as I can tell,
occurs in one specific instance: In Editline::EndOrAddLineCommand() when the
list of lines being processed contains exactly one string (""). Meeting this
condition is fairly simple, I have posted steps to reproduce above.
Reviewers: krytarowski, zturner, labath
Reviewed By: labath
Subscribers: scott.smith, lldb-commits
Differential Revision: https://reviews.llvm.org/D32421
Patch by Alex Langford.
llvm-svn: 302225
Summary:
Arm64 Procedure Call Standard specifies than only vectors up to 16 bytes
are stored in v0 (which makes sense, as that's the size of the
register). 32-byte vector types are passed as regular structs via x8
pointer. Treat them as such.
This fixes TestReturnValue for arm64-clang. I also split the test case
into two so I can avoid the if(gcc) line, and annotate each test
instead. (It seems the vector type tests fail with gcc only when
targetting x86 arches).
Reviewers: tberghammer, eugene
Subscribers: aemerson, omjavaid, rengolin, srhines, lldb-commits
Differential Revision: https://reviews.llvm.org/D32813
llvm-svn: 302220
Summary:
The existing cpp-level checks using PR_MPX_ENABLE_MANAGEMENT aren't sufficient,
as this isn't defined for linux kernel versions below 3.19.
Reviewers: valentinagiusti, zturner, labath
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D32719
llvm-svn: 302027
gnuwin32 rm does not like wildcards that match nothing even if we
specify -f (probably because the wildcard expansion happens in-process
there). We could use make $(wildcard) here, but it seems safer to
explicitly list the files here, just like the normal Makefile.rules
does.
llvm-svn: 302013
Loading a shared library can require a large amount of work; rather than do that serially for each library,
this patch will allow parallelization of the symbols and debug info name indexes.
From scott.smith@purestorage.comhttps://reviews.llvm.org/D32598
llvm-svn: 301609
Many times a user wants to access a type when there's a variable of
the same name, or a variable when there's a type of the same name.
Depending on the precise context, currently the expression parser
can fail to resolve one or the other.
This is because ClangExpressionDeclMap has logic to limit the
amount of information it searches, and that logic sometimes cuts
down the search prematurely. This patch removes some of those early
exits.
In that sense, this patch trades performance (early exit is faster)
for correctness.
I've also included two new test cases showing examples of this
behavior – as well as modifying an existing test case that gets it
wrong.
llvm-svn: 301273
LLDB uses clang::DeclContexts for lookups, and variables get put into
the DeclContext for their abstract origin. (The abstract origin is a
DWARF pointer that indicates the unique definition of inlined code.)
When the expression parser is looking for variables, it locates the
DeclContext for the current context. This needs to be done carefully,
though, e.g.:
__attribute__ ((always_inline)) void f(int a) {
{
int b = a * 2;
}
}
void g() {
f(3);
}
Here, if we're stopped in the inlined copy of f, we have to find the
DeclContext corresponding to the definition of f – its abstract
origin. Clang doesn't allow multiple functions with the same name and
arguments to exist. It also means that any variables we see must be
placed in the appropriate DeclContext.
[Bug 1]: When stopped in an inline block, the function
GetDeclContextDIEContainingDIE for that block doesn't properly
construct a DeclContext for the abstract origin for inlined
subroutines. That means we get duplicated function DeclContexts, but
function arguments only get put in the abstract origin's DeclContext,
and as a result when we try to look for them in nested contexts they
aren't found.
[Bug 2]: When stopped in an inline block, the DWARF (for space
reasons) doesn't explicitly point to the abstract origin for that
block. This means that the function GetClangDeclContextForDIE returns
a different DeclContext for each place the block is inlined. However,
any variables defined in the block have abstract origins, so they
will only get placed in the DeclContext for their abstract origin.
In this fix, I've introduced a test covering both of these issues,
and fixed them.
Bug 1 could be resolved simply by making sure we look up the abstract
origin for inlined functions when looking up their DeclContexts on
behalf of nested blocks.
For Bug 2, I've implemented an algorithm that makes the DeclContext
for a block be the containing DeclContext for the closest entity we
would find during lookup that has an abstract origin pointer. That
means that in the following situation:
{ // block 1
int a;
{ // block 2
int b;
}
}
if we looked up the DeclContext for block 2, we'd find the block
containing the abstract origin of b, and lookup would proceed
correctly because we'd see b and a. However, in the situation
{ // block 1
int a;
{ // block 2
}
}
since there isn't anything to look up in block 2, we can't determine
its abstract origin (and there is no such pointer in the DWARF for
blocks). However, we can walk up the parent chain and find a, and its
abstract origin lives in the abstract origin of block 1. So we simply
say that the DeclContext for block 2 is the same as the DeclContext
for block 1, which contains a. Lookups will return the same results.
Thanks to Jim Ingham for review and suggestions.
Differential revision: https://reviews.llvm.org/D32375
llvm-svn: 301263
Summary:
MergeFrom was updating the architecture if the target triple did not
have it set. However, it was leaving the core field as invalid. This
resulted in assertion failures in core file tests as a missing core
meant we were unable to compute the address byte size properly.
Add a unit test for the new behaviour.
Reviewers: jingham, clayborg
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D32221
llvm-svn: 300836
The test fails because an older clang did not emit the required debug
info (I am not sure when this got added, but clang-3.7 certainly did not
work yet). The actual platform has nothing to do with this.
llvm-svn: 300834
I thought my previous commit got the last ones but somehow I missed
these. This also resurrects TestDataFormatterLibcxxSet, which got
commented out in r263859 as a part of some seemingly unrelated change.
llvm-svn: 300833
Clang rejects __attribute__((regparm)) when targetting arm. The default
calling convention passes arguments in registers anyway, so we can just
remove them in this case.
llvm-svn: 300670
r285226 dropped the code that did these checks. I am pretty
sure that was inadvertent, so I added that back in and added
a test for it.
<rdar://problem/31661252>
llvm-svn: 300564
Summary:
The iteration list through the available data formatters was undefined,
which meant that the vector<bool> formatter kicked in only in cases
where it happened to be queried before the general vector formatter. To
fix this, I merge the two data formatter entries into one, and select
which implementation to use in the factory function.
Reviewers: jasonmolenda, tberghammer, EricWF
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D31880
llvm-svn: 300047
gcc emits DW_LANG_C89 even if we specify -std=c99 during compilation.
Since this isn't an lldb bug, but just the way the compiler happens to
be implemented, I teach the test to expect this situation correctly.
llvm-svn: 300046
I have put them all in their own category, and made that category disabled by default.
Differential revision: https://reviews.llvm.org/D31718
llvm-svn: 299587
look showed that the target's arch has no core / byte order and so when
AuxVector::AuxVector calls into a dataextractor and sets the byte size to 0,
it asserts. e.g.
m_arch = {
m_triple = (Data = "x86_64--linux", Arch = x86_64, SubArch = NoSubArch, Vendor = UnknownVendor, OS = Linux, Environment = UnknownEnvironment, ObjectFormat = ELF)
m_core = kCore_invalid
m_byte_order = eByteOrderInvalid
m_flags = 0x00000000
m_distribution_id = <no value available>
}
<rdar://problem/31380097>
llvm-svn: 299408
Summary:
After this change a sythetic child provider can generate a special child
named "$$dereference$$" what if present is used when "operator*" or
"operator->" used on a ValueObject. The goal of the change is to make
expressions like "up->foo" work inside the "frame variable" command.
Reviewers: labath, jingham
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D31368
llvm-svn: 299251
Summary:
Displaying the object pointed by the unique_ptr can cause an infinite
recursion when we have a pointer loop so this change stops that
behavior. Additionally it makes the unique_ptr act more like a class
containing a pointer (what is the underlying truth) instead of some
"magic" class.
Reviewers: labath, jingham
Differential Revision: https://reviews.llvm.org/D31366
llvm-svn: 299249
Summary:
This aims to replace the different decorators we've had on each libc++
test with a single solution. Each libc++ will be assigned to the
"libc++" category and a single central piece of code will decide whether
we are actually able to run libc++ test in the given configuration by
enabling or disabling the category (while giving the user the
opportunity to override this).
I started this effort because I wanted to get libc++ tests running on
android, and none of the existing decorators worked for this use case:
- skipIfGcc - incorrect, we can build libc++ executables on android
with gcc (in fact, after this, we can now do it on linux as well)
- lldbutil.skip_if_library_missing - this checks whether libc++.so is
loaded in the proces, which fails in case of a statically linked
libc++ (this makes copying executables to the remote target easier to
manage).
To make this work I needed to split out the pseudo_barrier code from the
force-included file, as libc++'s atomic does not play well with gcc on
linux, and this made every test fail, even though we need the code only
in the threading tests.
So far, I am only annotating one of the tests with this category. If
this does not break anything, I'll proceed to update the rest.
Reviewers: jingham, zturner, EricWF
Subscribers: srhines, lldb-commits
Differential Revision: https://reviews.llvm.org/D30984
llvm-svn: 299028
This was added to workaround a limitation in LLVM's implementation
of getting the current user's home directory, since it would
only look at the value of $HOME, but we did not want to rely
on that being set so we would also look in the password database.
Adding the ability to look in the password database to LLVM was
a straightforward patch that was submitted in r298513, so since
that is done this test is no longer needed.
llvm-svn: 298519
This fixes a bug introduced by r291559. The Module's FindType was
passing the original name not the basename in the case where it didn't
find any separators. I also added a testcase for this.
<rdar://problem/31159173>
llvm-svn: 298331
Only do this when we are debugging an executable, since we
don't have a good way to trace from an ObjectFile back to its
containing executable. Detecting pre-run libs before running
is "best effort" in lldb, but this one is pretty easy.
llvm-svn: 298290
r298203 make SBPlatform::MakeDirectory less recursive, which breaks the
test suite creation of test directory hierarchy creation on the remote
target. Since the function was never fully recursive, and the name does
not imply recursiveness, I fix the problem by modifying the test runner
to do the recursion manually.
I also make the runner complain more loudly when it fails to create the
directory -- previously it just printed the error to stdout and caused
most of the tests to hang, which is not very helpful in diagnosing the
problem.
llvm-svn: 298261
dotest.py script doesn't validate executables passed on the command line
before spawning dozens of subprocesses, all of which fail silently,
leaving an empty results file.
We should validate the lldb and compiler executables on
configuration, aborting when given invalid paths, to prevent numerous,
cryptic, and spurious failures.
<rdar://problem/31117272>
llvm-svn: 298111
Summary:
These classes existed only because of the GetName() static function,
which can be moved to a more natural place anyway. I move the linux
version to NativeProcessLinux (and get rid of ProcFileReader), the
freebsd version to ProcessFreeBSD (and fix a bug where it was using the
current process ID, instead of the inferior pid), and remove the NetBSD
version (which was probably incorrect anyway, as it assumes the current
process instead of the inferior.
I also add an llgs test to that verifies thread names are read
correctly.
Reviewers: zturner, krytarowski, emaste
Subscribers: lldb-commits, mgorny
Differential Revision: https://reviews.llvm.org/D30981
llvm-svn: 298058
It seems that on darwin we are not able to resolve breakpoints in the
test shared library until the process has started. That seems
unfortunate, but it is not the purpose of this test, so work around that
by starting the process before doing the rest of our checks.
llvm-svn: 297830
Summary:
This fixes the case where a user tries to set a breakpoint on a source
line outside of any function (e.g. because that code is #ifdefed out, or
the compiler did not emit code for the function, etc.) and we would
silently move the breakpoint to the next function.
Now we check whether the line range of the resolved symbol context
function matches the original line number. We reject any breakpoint
locations that appear to move the breakpoint into a new function. This
filtering only happens if we have full debug info available (e.g. in
case of -gline-tables-only compilation, we still set the breakpoint on
the nearest source line).
Reviewers: jingham
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D30817
llvm-svn: 297817
Summary:
This has been broken at least since the new test result framework was
added, which was over a year ago. It looks like nobody has missed it
since.
Removing this makes the gmodules handling code saner, as it already did
not know how to handle the multiple-compilers case.
My motivation for this is libc++ data formatters support on android -- I
am trying make a central way of determining whether libc++ tests can be
run, and without this, I would have to resort to similar hacks as the
gmodules code.
Reviewers: jingham, zturner
Subscribers: danalbert, tfiala, lldb-commits
Differential Revision: https://reviews.llvm.org/D30779
llvm-svn: 297811
This patch adds support to the test suite for overriding the path to debugserver, and uses the override to point to the build tree's debugserver on Darwin.
llvm-svn: 297776
Summary:
This adds support for building libc++ tests when targetting android. The
tests are still not passing due to several other problems, but this way
we can at least build them.
Reviewers: eugene, EricWF, danalbert
Subscribers: srhines, lldb-commits
Differential Revision: https://reviews.llvm.org/D30737
llvm-svn: 297616
SectionLoadList exposed by this test. Greg tried to chase it down
& got pretty far but the isn't correct so we'll disable this test
for now until I can figure that out.
<rdar://problem/30899227>
llvm-svn: 297440
The toolchain directory for arm android targets was computed
incorrectly. The architecture part should be arm, and the environment
part androideabi. This fixes that.
llvm-svn: 297279
it fails, but it works on the local workstations. I'll
need to figure out what the difference is between these.
<rdar://problem/30915340>
llvm-svn: 297259
Currently on remote platforms the lldb-mi tests fail, which means they time out.
Given how many of the lldb-mi tests there are, this means a long wait.
llvm-svn: 296951
Prior to MSVC 2015 we had to manually include this header any
time we were going to include <thread> or <future> due to a
bug in MSVC's STL implementation. This has been fixed in MSVC
for some time now, and we require VS 2015 minimum, so we can
remove this across all subprojects.
llvm-svn: 296906
Kuba Mracek