LowerDbgDeclare inserts a dbg.value before each use of an address
described by a dbg.declare. When inserting a dbg.value before a CallInst
use, however, it fails to append DW_OP_deref to the DIExpression.
The DW_OP_deref is needed to reflect the fact that a dbg.value describes
a source variable directly (as opposed to a dbg.declare, which relies on
pointer indirection).
This patch adds in the DW_OP_deref where needed. This results in the
correct values being shown during a debug session for a program compiled
with ASan and optimizations (see https://reviews.llvm.org/D49520). Note
that ConvertDebugDeclareToDebugValue is already correct -- no changes
there were needed.
One complication is that SelectionDAG is unable to distinguish between
direct and indirect frame-index (FRAMEIX) SDDbgValues. This patch also
fixes this long-standing issue in order to not regress integration tests
relying on the incorrect assumption that all frame-index SDDbgValues are
indirect. This is a necessary fix: the newly-added DW_OP_derefs cannot
be lowered properly otherwise. Basically the fix prevents a direct
SDDbgValue with DIExpression(DW_OP_deref) from being dereferenced twice
by a debugger. There were a handful of tests relying on this incorrect
"FRAMEIX => indirect" assumption which actually had incorrect
DW_AT_locations: these are all fixed up in this patch.
Testing:
- check-llvm, and an end-to-end test using lldb to debug an optimized
program.
- Existing unit tests for DIExpression::appendToStack fully cover the
new DIExpression::append utility.
- check-debuginfo (the debug info integration tests)
Differential Revision: https://reviews.llvm.org/D49454
llvm-svn: 338069
/usr/bin/env is recommended as a cross-platform way to find python. But:
- we're only using lldb on darwin, where we know python (or at least,
the xcrun-style shortcut) is in /usr/bin/
- the python interpreter in LLDB comes from /S/L/F:
$ otool -L Contents/SharedFrameworks/LLDB.framework/LLDB | grep Python
/System/Library/Frameworks/Python.framework/Versions/2.7/Python
so when we use the lldb python module, it calls into the swig/python
support in the lldb framework, and if there's a mismatch between the
interpreter and the linked python, weird things occur.
In theory, I believe this should be done by:
- looking for the LLDB framework (llgdb.py does some of that)
- finding the binary inside the framework
- looking for the Python it was linked against (otool -L)
- finding the interpreter executable inside the Python.framework
But in practice, that's only different if we use a custom LLDB
framework/pythonpath when running these tests, and AFAIK nobody does
that right now, so the code would be dead anyway.
Don't pretend we can use any arbitrary python: just use the system one.
Differential Revision: https://reviews.llvm.org/D47967
llvm-svn: 334369
These sections will be retired. Also, explicitly list llvm-objdump
as a dependency. This should've been done in the previous commit,
but I failed to squash the two changes together.
Thanks to Adrian for pointing the first problem out in a comment.
llvm-svn: 326121
Summary:
Add cmake and lit files needed to run these tests as an
external project. Also, copy test_debuginfo.pl from llvm/utils since
it's only used here. The copy in llvm/utils must be maintained as
long as bots continue to include debuginfo-tests in clang/test.
This patch depends on clang patch https://reviews.llvm.org/D41055.
Reviewers: zturner, aprantl
Reviewed By: aprantl
Subscribers: mgorny, llvm-commits, JDevlieghere
Differential Revision: https://reviews.llvm.org/D40971
llvm-svn: 320495
This is still breaking greendragon.
At this point I give up until someone can fix the greendragon
bots, and I will probably abandon this effort in favor of using
a private github repository.
llvm-svn: 318722
This was reverted due to the tests being run twice on some
build bots. Each run had a slightly different configuration
due to the way in which it was being invoked. This fixes
the problem (albeit in a somewhat hacky way). Hopefully in
the future we can get rid of the workflow of running
debuginfo-tests as part of clang, and then this hack can
go away.
llvm-svn: 318697
This is still broken because it causes certain tests to be
run twice with slightly different configurations, which is
wrong in some cases.
You can observe this by running:
ninja -nv check-all | grep debuginfo-tests
And seeing that it passes clang/test and clang/test/debuginfo-tests
to lit, which causes it to run debuginfo-tests twice. The fix is
going to involve either:
a) figuring out that we're running in this "deprecated" configuration,
and then deleting the clang/test/debuginfo-tests path, which should
cause it to behave identically to before, or:
b) make lit smart enough that it doesn't descend into a sub-suite if
that sub-suite already has a lit.cfg file.
llvm-svn: 318486
This was reverted due to some failures on specific darwin buildbots,
the issue being that the new lit configuration was not setting the
SDKROOT environment variable. We've tested a fix locally and confirmed
that it works, so this patch resubmits everything with the fix
applied.
llvm-svn: 318435
This reverts the aforementioned patch and 2 subsequent follow-ups,
as some buildbots are still failing 2 tests because of it.
Investigation is ongoing into the cause of the failures.
llvm-svn: 318112
Previously, debuginfo-tests was expected to be checked out into
clang/test and then the tests would automatically run as part of
check-clang. This is not a standard workflow for handling
external projects, and it brings with it some serious drawbacks
such as the inability to depend on things other than clang, which
we will need going forward.
The goal of this patch is to migrate towards a more standard
workflow. To ease the transition for build bot maintainers,
this patch tries not to break the existing workflow, but instead
simply deprecate it to give maintainers a chance to update
the build infrastructure.
Differential Revision: https://reviews.llvm.org/D39605
llvm-svn: 317925
Summary:
Split asan.c into asan.c and asan-blocks.c, which will be
darwin-specific. I suspect we could make it pass on Linux by adding
cmake to build BlocksRuntime from compiler-rt, but I'm not shaving that
yak yet.
asan.c and safestack.c: GDB and LLDB appear to print aggregates
differently today. Print individual elements instead of the entire
aggregate.
dbg-arg.c: GDB doesn't appear to print leading zeros when printing
pointers.
stack-var.c: Add the optnone attribute so that LLVM won't optimize away
this no-op function call. This should be a cross-platform failure
observable on Mac, so this is surprising.
Reviewers: aprantl, dblaikie
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D37344
llvm-svn: 312265
When this testcase was migrated from IR to source the DEBUGGER
commands were not migrated together with the rest of the testcase. It
was also compiling without debug info.
Make the testcase slightly less useless by adding them back in :-)
llvm-svn: 299673
VLAs are special-cased in the frontend. This testcase ensures that the
contract between clang and llvm won't be accidentally broken by future
refactorings.
llvm-svn: 299668
clang tests were breaking, at least when compiling clang only, from an
installed llvm. Make the lit.cfg script deal with the case when we don't
have a host_triple available.
llvm-svn: 220152
Since these tests expect a working debugger, always compile them for the
host triple, assuming a working debugger is present.
This enables us to compile and run them, even when clang is, by default,
a cross-compiler (but can still target the host).
llvm-svn: 219992
This reverts commit 203504. We decided that it is better to disable this test on a per-buildbot basis in zorg rather than everywhere on Darwin.
llvm-svn: 203627
Vedant Kumar