building method override tables for CXXMethodDecls in
DWARFASTParserClang::CompleteTypeFromDWARF.
C++ virtual method calls in LLDB expressions may fail if the override table for
the method being called is not correct as IRGen will produce references to the
wrong (or a missing) vtable entry.
This patch does not fix calls to virtual methods with covariant return types as
it mistakenly treats these as overloads, rather than overrides. This will be
addressed in a future patch.
Review: https://reviews.llvm.org/D41997
Partially fixes <rdar://problem/14205774>
llvm-svn: 323163
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
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
RemoveInvalidLocations was clearing out the m_locations in the
breakpoint by hand, and it wasn't also clearing the locations from
the address->location map, which confused us when we went to update
breakpoint locations.
I also made Breakpoint::ModulesChanged check the Location's Section
to make sure it hadn't been deleted. This shouldn't strictly be necessary,
but if the DynamicLoaderPlugin doesn't do it's job right (I'm looking at
you new Darwin DynamicLoader...) then it can end up leaving stale locations
on rerun. It doesn't hurt to clean them up here as a backstop.
<rdar://problem/36134350>
llvm-svn: 322348
This test stresses expression evaluation support for template functions.
Currently the support is rudimentary, and running this test causes assertion
failures in clang. This test cannot be XFAIL'ed because the test harness
treats assertion failures as unexpected events. For now, the test must be
skipped.
llvm-svn: 322340
When rendezvous structure is not initialized we need to set up
rendezvous breakpoint anyway. In this case the code will locate
dynamic loader (interpreter) and look for known function names.
This is r322209, but with fixed VDSO loading fixed.
Bug: https://bugs.llvm.org/show_bug.cgi?id=25806
Differential Revision: https://reviews.llvm.org/D41533
llvm-svn: 322251
When rendezvous structure is not initialized we need to set up
rendezvous breakpoint anyway. In this case the code will locate
dynamic loader (interpreter) and look for known function names.
Bug: https://bugs.llvm.org/show_bug.cgi?id=25806
Differential Revision: https://reviews.llvm.org/D41533
llvm-svn: 322209
Summary:
There was some confusion in the code about how to represent process
environment. Most of the code (ab)used the Args class for this purpose,
but some of it used a more basic StringList class instead. In either
case, the fact that the underlying abstraction did not provide primitive
operations for the typical environment operations meant that even a
simple operation like checking for an environment variable value was
several lines of code.
This patch adds a separate Environment class, which is essentialy a
llvm::StringMap<std::string> in disguise. To standard StringMap
functionality, it adds a couple of new functions, which are specific to
the environment use case:
- (most important) envp conversion for passing into execve() and likes.
Instead of trying to maintain a constantly up-to-date envp view, it
provides a function which creates a envp view on demand, with the
expectation that this will be called as the very last thing before
handing the value to the system function.
- insert(StringRef KeyEqValue) - splits KeyEqValue into (key, value)
pair and inserts it into the environment map.
- compose(value_type KeyValue) - takes a map entry and converts in back
into "KEY=VALUE" representation.
With this interface most of the environment-manipulating code becomes
one-liners. The only tricky part was maintaining compatibility in
SBLaunchInfo, which expects that the environment entries are accessible
by index and that the returned const char* is backed by the launch info
object (random access into maps is hard and the map stores the entry in
a deconstructed form, so we cannot just return a .c_str() value). To
solve this, I have the SBLaunchInfo convert the environment into the
"envp" form, and use it to answer the environment queries. Extra code is
added to make sure the envp version is always in sync.
(This also improves the layering situation as Args was in the Interpreter module
whereas Environment is in Utility.)
Reviewers: zturner, davide, jingham, clayborg
Subscribers: emaste, lldb-commits, mgorny
Differential Revision: https://reviews.llvm.org/D41359
llvm-svn: 322174
Summary:
This used to be important when all tests were run in a single process,
but that has no longer been the case for a while. Furthermore, this hook fails
to build on new mac versions for several people, and it's not clear
whether fixing it is worth the effort.
Reviewers: jingham, clayborg, davide
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D41871
llvm-svn: 322167
This fixes a bug in -gmodules DWARF handling when debugging without a .dSYM bundle
that was particularly noticable when debugging LLVM itself.
Debugging without clang modules and DWO handling should be unaffected by this patch.
<rdar://problem/32436209>
llvm-svn: 321802
The test works fine on linux, and I believe other targets should not
have an issue with as well. If they do, we can start blacklisting
instead of whitelisting.
The idea of using "-1" as the value of the pointer on non-apple targets
backfired, as it fails the "address != LLDB_INVALID_ADDRESS" test (-1 is
the value of LLDB_INVALID_ADDRESS). However, it should be safe to use
0x100 for other targets as well. The first page of memory is generally
kept unreadable to catch null pointer dereferences.
llvm-svn: 321353
an empty Python string object when it reads a 0-length
string out of memory (and a successful SBError object).
<rdar://problem/26186692>
llvm-svn: 321338
Two tests were failing because the debugger was picking up multiply
defined internal symbols from the system libraries. This is a bug, as
there should be no ambiguity because the tests are defining variables
with should shadow these symbols, but lldb is not smart enough to figure
that out.
I work around the issue by renaming the variables in these tests, and in
exchange I create a self-contained test which reproduces the issue
without depending on the system libraries.
This increases the predictability of our test suite.
llvm-svn: 321271
"Default" is a valid QoS for a thread on older versions of macOS,
like the one installed in the bot.
Thanks to Jason Molenda for helping me figuring out the problem.
<rdar://problem/28346273>
llvm-svn: 320883
I tested on x86-64 and Jason on embedded architectures.
This cleans up another couple of reported unexpected successes.
<rdar://problem/28623427>
llvm-svn: 320452
After discussing this with Jim and Jason, I think my commit was
actually sweeping the issue under the carpet rather than fixing it.
I'll take a closer look between tonight and tomorrow.
llvm-svn: 320447
Some tests are failing on macOS when building with the in-tree
clang, and this is because they're conditional on the version released.
Apple releases using a different versioning number, but as these are
conditional on clang < 7, they fail for clang ToT (which is 6.0).
As a general solution, we actually need either a mapping between
Apple internal release version and public ones.
That said, I discussed this with Fred , and Apple Clang 6.0 seems
to be old enough that we can remove this altogether (which means I
can delay implementing the general purpose solution for a bit).
Differential Revision: https://reviews.llvm.org/D41101
llvm-svn: 320444
This is the first of a series of commits aiming to improve
overall LLDB's hygiene. Feel free to shout at me in case
I break something.
<rdar://problem/30915340>
llvm-svn: 320425
Also add a test. There should also be control for this
in ProcessLaunchInfo and a "target launch" flag, but at least
this will allow you to control it somehow.
<rdar://problem/35842137>
llvm-svn: 319731
Summary:
This flag is on by default for darwin and freebsd, but off for linux.
Without it, clang will sometimes not emit debug info for types like
std::string. Whether it does this, and which tests will fail because of
that depends on the linux distro and c++ library version.
A bunch of tests were already setting these flags manually, but here
instead I take a whole sale approach and enable this flag for all tests.
Any test which does not want to have this flag (right now we have one
such test) can turn it off explicitly via
CFLAGS_EXTRAS+=$(LIMIT_DEBUG_INFO_FLAGS)
This fixes a bunch of data formatter tests on red-hat.
Reviewers: davide, jankratochvil
Subscribers: emaste, aprantl, krytarowski, JDevlieghere, lldb-commits
Differential Revision: https://reviews.llvm.org/D40717
llvm-svn: 319653
unambiguously on one bit of code. On macOS these
lines mapped to two distinct locations, and that
was artificially throwing off the test.
llvm-svn: 319472
Summary:
New linux kernels (on systems that support the XSAVES instruction) will
not update the inferior registers unless the corresponding flag in the
XSAVE header is set. Normally this flag will be set in our image of the
XSAVE area (since we obtained it from the kernel), but if the inferior
has never used the corresponding register set, the respective flag can
be clear.
This fixes the issue by making sure we explicitly set the flags
corresponding to the registers we modify. I don't try to precisely match
the flags to set on each write, as the rules could get quite complicated
-- I use a simpler over-approximation instead.
This was already caught by test_fp_register_write, but that was only
because the code that ran before main() did not use some of the register
sets. Since nothing in this test relies on being stopped in main(), I
modify the test to stop at the entry point instead, so we can be sure
the inferior did not have a chance to access these registers.
Reviewers: clayborg, valentinagiusti
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D40434
llvm-svn: 319161
New android ndk linker started adding more flags to the produced
binaries, which causes older dynamic linkers display warnings to stderr
about unsupported flags. This interferes with our stderr tests.
Extend the hasChattyStderr function to catch these targets as well.
llvm-svn: 319028
Adrian Prantl