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
Nitesh Jain