Summary:
The ValueObject code checks for a special `$$dereference$$` synthetic
child to allow formatter providers to implement a natural
dereferencing behavior in `frame variable` for objects like smart
pointers.
This support was broken when used directly throught the Python API and
not trhough `frame variable`. The reason is that
SBFrame.FindVariable() will return by default the synthetic variable
if it exists, while `frame variable` will not do this eagerly. The
code in `ValueObject::Dereference()` accounted for the latter but not
for the former. The fix is trivial. The test change includes
additional covergage for the already-working bahevior as it wasn't
covered by the testsuite before.
This commit also adds a short piece of documentatione explaining that
it is possible (even advisable) to provide this synthetic child
outstide of the range of the normal children.
Reviewers: jingham
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D73053
The Xcode generator does not provide the auto-generated targets where
you can append a folder name to check-lldb. Instead add two custom lit
targets to run just the shell and api tests.
I moved the code from the system initializer to PlatformMacOSX. The
defines are still necessary because MacOSX is initialized on other
platforms where the other platforms are not available.
Summary:
Add setting target.auto-install-main-executable that controls whether
the main executable should be automatically installed when connected to
a remote platform even if it does not have an explicit install path
specified. The default is true as the current behaviour.
Reviewers: omjavaid, JDevlieghere, srhines, labath, clayborg
Reviewed By: clayborg
Subscribers: kevin.brodsky, lldb-commits, llvm-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D71761
Summary:
Add setting target.auto-install-main-executable that controls whether
the main executable should be automatically installed when connected to
a remote platform even if it does not have an explicit install path
specified. The default is true as the current behaviour.
Reviewers: omjavaid, JDevlieghere, srhines, labath, clayborg
Reviewed By: clayborg
Subscribers: kevin.brodsky, lldb-commits, llvm-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D71761
PlatformMacOSX is the main entry point to the plugin with the same name.
This is part of a greater refactoring to auto generate the initializers.
Differential revision: https://reviews.llvm.org/D73116
We were creating a bunch of LineSequence objects but never deleting
them.
This fixes the leak and changes the code to use std::unique_ptr, to make
it harder to make the same mistake again.
The way the IO handlers are currently managed by the debugger is wrong. The
implementation lacks proper synchronization between RunIOHandlerSync and
RunIOHandlers. The latter is meant to be run by the "main thread", while the
former is meant to be run synchronously, potentially from a different thread.
Imagine a scenario where RunIOHandlerSync is called from a different thread
than RunIOHandlers. Both functions manipulate the debugger's IOHandlerStack.
Although the push and pop operations are synchronized, the logic to activate,
deactivate and run IO handlers is not.
While investigating PR44352, I noticed some weird behavior in the Editline
implementation. One of its members (m_editor_status) was modified from another
thread. This happened because the main thread, while running RunIOHandlers
ended up execution the IOHandlerEditline created by the breakpoint callback
thread. Even worse, due to the lack of synchronization within the IO handler
implementation, both threads ended up executing the same IO handler.
Most of the time, the IO handlers don't need to run synchronously. The
exception is sourcing commands from external files, like the .lldbinit file.
I've added a (recursive) mutex to prevent another thread from messing with the
IO handlers wile another thread is running one synchronously. It has to be
recursive, because we might have to source another file when encountering a
command source in the original file.
Differential revision: https://reviews.llvm.org/D72748
This patch introduces a small new utility (lldb-repro) to transparently
capture and replay debugger sessions through the command line driver.
Its used to test the reproducers by running the test suite twice.
During the first run, it captures a reproducer for every lldb invocation
and saves it to a well-know location derived from the arguments and
current working directory. During the second run, the test suite is run
again but this time every invocation of lldb replays the previously
recorded session.
Differential revision: https://reviews.llvm.org/D72823
Summary:
CXXRecordDecls that have a move constructor but no copy constructor need to
have their implicit copy constructor marked as deleted (see C++11 [class.copy]p7, p18)
Currently we don't do that when building an AST with ClangASTContext which causes
Sema to realise that the AST is malformed and asserting when trying to create an implicit
copy constructor for us in the expression:
```
Assertion failed: ((data().DefaultedCopyConstructorIsDeleted || needsOverloadResolutionForCopyConstructor())
&& "Copy constructor should not be deleted"), function setImplicitCopyConstructorIsDeleted, file include/clang/AST/DeclCXX.h, line 828.
```
In the test case there is a class `NoCopyCstr` that should have its copy constructor marked as
deleted (as it has a move constructor). When we end up trying to tab complete in the
`IndirectlyDeletedCopyCstr` constructor, Sema realises that the `IndirectlyDeletedCopyCstr`
has no implicit copy constructor and tries to create one for us. It then realises that
`NoCopyCstr` also has no copy constructor it could find via lookup. However because we
haven't marked the FieldDecl as having a deleted copy constructor the
`needsOverloadResolutionForCopyConstructor()` returns false and the assert fails.
`needsOverloadResolutionForCopyConstructor()` would return true if during the time we
added the `NoCopyCstr` FieldDecl to `IndirectlyDeletedCopyCstr` we would have actually marked
it as having a deleted copy constructor (which would then mark the copy constructor of
`IndirectlyDeletedCopyCstr ` as needing overload resolution and Sema is happy).
This patch sets the correct mark when we complete our CXXRecordDecls (which is the time when
we know whether a copy constructor has been declared). In theory we don't have to do this if
we had a Sema around when building our debug info AST but at the moment we don't have this
so this has to do the job for now.
Reviewers: shafik
Reviewed By: shafik
Subscribers: aprantl, JDevlieghere, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D72694
Summary:
Normally, on linux we retrieve the process ID from the LinuxProcStatus
stream (which is just the contents of /proc/%d/status pseudo-file).
However, this stream is not strictly required (it's a breakpad
extension), and we are encountering a fair amount of minidumps which do
not have it present. It's not clear whether this is the case with all
these minidumps, but the two known situations where this stream can be
missing are:
- /proc filesystem not mounted (or something to that effect)
- process crashing after exhausting (almost) all file descriptors (so
the minidump writer may not be able to open the /proc file)
Since this is a corner case which will become less and less relevant
(crashpad-generated minidumps should not suffer from this problem), I
work around this problem by hardcoding the PID to 1 in these cases.
The same thing is done by the gdb plugin when talking to a stub which
does not report a process id (e.g. a hardware probe).
Reviewers: jingham, clayborg
Subscribers: markmentovai, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D70238
Summary:
This code is handling debug info paths starting with /proc/self/cwd,
which is one of the mechanisms people use to obtain "relocatable" debug
info (the idea being that one starts the debugger with an appropriate
cwd and things "just work").
Instead of resolving the symlinks inside DWARFUnit, we can do the same
thing more elegantly by hooking into the existing Module path remapping
code. Since llvm::DWARFUnit does not support any similar functionality,
doing things this way is also a step towards unifying llvm and lldb
dwarf parsers.
Reviewers: JDevlieghere, aprantl, clayborg, jdoerfert
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D71770
Summary:
Motivation: When setting breakpoints in certain projects line sequences are frequently being inserted out of order.
Rather than inserting sequences one at a time into a sorted line table, store all the line sequences as we're building them up and sort and flatten afterwards.
Reviewers: jdoerfert, labath
Reviewed By: labath
Subscribers: teemperor, labath, mgrang, JDevlieghere, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D72909
Summary:
This method was doing a lot more than it's only caller needed
(DWARFDIE::LookupDeepestBlock) needed, so I inline it into the caller,
and remove any code which is not actually used. This includes code for
searching for the deepest function, and the code for working around
incomplete DW_AT_low_pc/high_pc attributes on a compile unit DIE (modern
compiler get this right, and this method is called on function DIEs
anyway).
This also improves our llvm consistency, as llvm::DWARFDebugInfoEntry is
just a very simple struct with no nontrivial logic.
Reviewers: JDevlieghere, aprantl
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D72920
Summary:
The goal of this patch is two-fold. First, it fixes a use-after-free in
the construction of the llvm DWARFContext. This happened because the
construction code was throwing away the lldb DataExtractors it got while
reading the sections (unlike their llvm counterparts, these are also
responsible for memory ownership). In most cases this did not matter,
because the sections are just slices of the mmapped file data. But this
isn't the case for compressed elf sections, in which case the section is
decompressed into a heap buffer. A similar thing also happen with object
files which are loaded from process memory.
The second goal is to make it explicit which sections go into the llvm
DWARFContext -- any access to the sections through both DWARF parsers
carries a risk of parsing things twice, so it's better if this is a
conscious decision. Also, this avoids loading completely irrelevant
sections (e.g. .text). At present, the only section that needs to be
present in the llvm DWARFContext is the debug_line_str. Using it through
both APIs is not a problem, as there is no parsing involved.
The first goal is achieved by loading the sections through the existing
lldb DWARFContext APIs, which already do the caching. The second by
explicitly enumerating the sections we wish to load.
Reviewers: JDevlieghere, aprantl
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D72917
This extract the common functionality of enabling and disabling hardware
watchpoints into a single function.
Differential revision: https://reviews.llvm.org/D72971
Those old Makefiles used completely ad-hoc rules for building files,
which means they didn't obey the test harness' variants.
They were somewhat tricky to update as they use very peculiar build
flags for some files. For this reason I was careful to compare the
build commands before and after the change, which is how I found the
discrepancy fixed by the previous commit.
While some of the make syntax used here might not be easy to grasp for
newcomers (per-target variable overrides), it seems better than to
have to repliacte the Makefile.rules logic for the test variants and
platform support.
The test harness invokes the test Makefiles with an explicit 'all'
target, but it's handy to be able to recursively call Makefile.rules
without speficying a goal.
Some time ago, we rewrote some tests in terms of recursive invocations
of Makefile.rules. It turns out this had an unintended side
effect. While using $(MAKE) for a recursive invocation passes all the
variables set on the command line down, it doesn't pass the make
goals. This means that those recursive invocations would invoke the
default rule. It turns out the default rule of Makefile.rules is not
'all', but $(EXE). This means that ti would work becuase the
executable is always needed, but it also means that the created
binaries would not follow some of the other top-level build
directives, like MAKE_DSYM.
Forcing 'all' to be the default target seems easier than making sure
all the invocations are correct going forward. This patch does this
using the .DEFAULT_GOAL directive rather than hoisting the 'all' rule
to be the first one of the file. It seems like this explicit approach
will be less prone to be broken in the future. Hopefully all the make
implementations we use support it.
[this re-applies c0176916a4
with the correct commit message and phabricator link]
This addresses point 1 of PR44213.
https://bugs.llvm.org/show_bug.cgi?id=44213
The DW_AT_LLVM_sysroot attribute is used for Clang module debug info,
to allow LLDB to import a Clang module from source. Currently it is
part of each DW_TAG_module, however, it is the same for all modules in
a compile unit. It is more efficient and less ambiguous to store it
once in the DW_TAG_compile_unit.
This should have no effect on DWARF consumers other than LLDB.
Differential Revision: https://reviews.llvm.org/D71732
This is a purely cosmetic change that is NFC in terms of the binary
output. I bugs me that I called the attribute DW_AT_LLVM_isysroot
since the "i" is an artifact of GCC command line option syntax
(-isysroot is in the category of -i options) and doesn't carry any
useful information otherwise.
This attribute only appears in Clang module debug info.
Differential Revision: https://reviews.llvm.org/D71722
These files should do the more or less the same initialize/terminate calls in the
same order. This just reverts all the differences that have piled up over time
in the SystemInitializerTest that people keep forgetting about.
... and include it from the main CMakeLists.txt instead of including the
utility subdirectories directly. This is consistent with the other
subdirectories and limits the scope of future changes.
The build configuration wasn't properly substituted for the
config.lldb_executable variable. This broke when the variable was
extracted from config.dotest_args_str which was properly substituted.
LLVMConfig doesn't export LLVM_HOST_TRIPLE, but it sets the
TARGET_TRIPLE based on this variable. So use that again for the compiler
invocations in the shell tests.
and document the shortcomings of LLDB's partially defined DW_OP_piece
handling.
This would manifest as "DW_OP_piece for offset foo but top of stack is
of size bar".
rdar://problem/46262998
Differential Revision: https://reviews.llvm.org/D72880
By switching to Scalars that are backed by explicitly-sized APInts we
can avoid a bug that increases the buffer reserved for a small piece
to the next-largest host integer type.
This manifests as "DW_OP_piece for offset foo but top of stack is of size bar".
Differential Revision: https://reviews.llvm.org/D72879
When LLVM_APPEND_VC_REV=OFF is set, the current git hash is no
longer embedded into binaries (mostly for --version output).
Without it, most binaries need to relink after every single
commit, even if they didn't change otherwise (due to, say,
a documentation-only commit).
LLVM_APPEND_VC_REV is ON by default, so this doesn't change the
default behavior of anything.
With this, all clients of GenerateVersionFromVCS.cmake honor
LLVM_APPEND_VC_REV.
Differential Revision: https://reviews.llvm.org/D72855
This test is just TestDataFormatterObjCNSData.py copied but without any changes
(and it therefore doesn't even test NSDate).
It's also failing as NSData has been changed by me in
4f244bba4f.
These tests used "clang -mllvm -accel-tables=Dwarf" as a way to
guarantee that clang will emit the debug_names table. Unfortunately,
a change it clang made that insufficient (-gpubnames is required now
too), which rendered these tests ineffective. Since lldb automatically
falls back to the manual index, the tests didn't fail and this change
went largely unnoticed.
This patch updates the tests to really use debug_names (-gdwarf-5
-gpubnames) is the combination that works now, and it adds additional
checks to ensure the section is actually emitted.
Fortunately, no regressions crept in while these tests were disabled.
The test is currently failing on some systems with ASAN enabled due to:
```
==22898==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x603000003da4 at pc 0x00010951c33d bp 0x7ffee6709e00 sp 0x7ffee67095c0
READ of size 5 at 0x603000003da4 thread T0
#0 0x10951c33c in wrap_memmove+0x16c (libclang_rt.asan_osx_dynamic.dylib:x86_64+0x1833c)
#1 0x7fff4a327f57 in CFDataReplaceBytes+0x1ba (CoreFoundation:x86_64+0x13f57)
#2 0x7fff4a415a44 in __CFDataInit+0x2db (CoreFoundation:x86_64+0x101a44)
#3 0x1094f8490 in main main.m:424
#4 0x7fff77482084 in start+0x0 (libdyld.dylib:x86_64+0x17084)
0x603000003da4 is located 0 bytes to the right of 20-byte region [0x603000003d90,0x603000003da4)
allocated by thread T0 here:
#0 0x109547c02 in wrap_calloc+0xa2 (libclang_rt.asan_osx_dynamic.dylib:x86_64+0x43c02)
#1 0x7fff763ad3ef in class_createInstance+0x52 (libobjc.A.dylib:x86_64+0x73ef)
#2 0x7fff4c6b2d73 in NSAllocateObject+0x12 (Foundation:x86_64+0x1d73)
#3 0x7fff4c6b5e5f in -[_NSPlaceholderData initWithBytes:length:copy:deallocator:]+0x40 (Foundation:x86_64+0x4e5f)
#4 0x7fff4c6d4cf1 in -[NSData(NSData) initWithBytes:length:]+0x24 (Foundation:x86_64+0x23cf1)
#5 0x1094f8245 in main main.m:404
#6 0x7fff77482084 in start+0x0 (libdyld.dylib:x86_64+0x17084)
```
The reason is that we create a string "HELLO" but get the size wrong (it's 5 bytes instead
of 4). Later on we read the buffer and pretend it is 5 bytes long, causing an OOB read
which ASAN detects.
In general this test probably needs some cleanup as it produces on macOS 10.15 around
100 compiler warnings which isn't great, but let's first get the bot green.
Add a flag which always generates a reproducer when normally it would be
discarded. This is meant for testing purposes to capture a debugger
session without modification the session itself.
size_t and uint64_t are spelled slightly differently on macOS, which was
causing the compiler to error out calling std::min - since the two types have
to be the same.
I fixed this by casting the uint64_t computation to a size_t. That's probably
not the cleanest solution, but it gets us back to building.
Summary:
This is the first in a series of patches to enable LLDB debugging of
WebAssembly targets.
Current versions of Clang emit (partial) DWARF debug information in WebAssembly
modules and we can leverage this debug information to give LLDB the ability to
do source-level debugging of Wasm code that runs in a WebAssembly engine.
A way to do this could be to use the remote debugging functionalities provided
by LLDB via the GDB-remote protocol. Remote debugging can indeed be useful not
only to connect a debugger to a process running on a remote machine, but also to
connect the debugger to a managed VM or script engine that runs locally,
provided that the engine implements a GDB-remote stub that offers the ability to
access the engine runtime internal state.
To make this work, the GDB-remote protocol would need to be extended with a few
Wasm-specific custom query commands, used to access aspects of the Wasm engine
state (like the Wasm memory, Wasm local and global variables, and so on).
Furthermore, the DWARF format would need to be enriched with a few Wasm-specific
extensions, here detailed: https://yurydelendik.github.io/webassembly-dwarf.
This CL introduce classes **ObjectFileWasm**, a file plugin to represent a Wasm
module loaded in a debuggee process. It knows how to parse Wasm modules and
store the Code section and the DWARF-specific sections.
Reviewers: jasonmolenda, clayborg, labath
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D71575
Instead of passing all the arguments for dotest.py as a single CMake
variable, lit now uses separate variables for the different test
binaries. Before this change they'd all get patched as part of the
LLDB_DOTEST_ARGS. We need to patch the new variables as well.
Instead of passing all the arguments for dotest.py as a single CMake
variable, lldb-dotest now uses separate variables for the different test
binaries. Before this change they'd all get patched as part of the
LLDB_DOTEST_ARGS. We need to patch the new variables as well.
Instead of passing all the arguments for dotest.py as a single CMake
variable, lldb-dotest now uses separate variables for the different test
binaries. Before this change they'd all get patched as part of the
LLDB_DOTEST_ARGS. We need to patch the new variables as well.
This reverts D53469, which changed llvm's DWARF emission to emit
DW_AT_call_return_pc as a function-local offset. Such an encoding is not
compatible with post-link block re-ordering tools and isn't standards-
compliant.
In addition to reverting back to the original DW_AT_call_return_pc
encoding, teach lldb how to fix up DW_AT_call_return_pc when the address
comes from an object file pointed-to by a debug map. While doing this I
noticed that lldb's support for tail calls that cross a DSO/object file
boundary wasn't covered, so I added tests for that. This latter case
exercises the newly added return PC fixup.
The dsymutil changes in this patch were originally included in D49887:
the associated test should be sufficient to test DW_AT_call_return_pc
encoding purely on the llvm side.
Differential Revision: https://reviews.llvm.org/D72489
Summary:
This patch adds a new function to lldbtest: `expect_expr`. This function is supposed to replace the current approach
of calling `expect`/`runCmd` with `expr`, `p` etc.
`expect_expr` allows evaluating expressions and matching their value/summary/type/error message without
having to do any string matching that might allow unintended passes (e.g., `self.expect("expr 3+4", substrs=["7"])`
can unexpectedly pass for results like `(Class7) $0 = 7`, `(int) $7 = 22`, `(int) $0 = 77` and so on).
This only uses the function in a few places to test and demonstrate it. I'll migrate the tests in follow up commits.
Reviewers: JDevlieghere, shafik, labath
Reviewed By: labath
Subscribers: christof, abidh, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D70314
The 'asynchronously' argument to both GetLLDBCommandsFromIOHandler and
GetPythonCommandsFromIOHandler is true for all call sites. This commit
simplifies the API by dropping it and giving the baton a default
argument.
The primary motivation for this is to add another dimension to the
Swift LLDB test matrix, but this seems generally useful.
Differential Revision: https://reviews.llvm.org/D72662
llvm_unreachable is marked noreturn so the compiler can assume the code
for printing the error message in release builds isn't hit which defeats
the purpose.
These are the last sections not managed by the DWARFContext object. I
also introduce separate SectionType enums for dwo section variants, as
this is necessary for proper handling of single-file split dwarf.
Summary:
This change is connected with
https://reviews.llvm.org/D69843
In large codebases, we sometimes see Module::FindFunctions (when called from
ClangExpressionDeclMap::FindExternalVisibleDecls) returning huge amounts of
functions.
In current fix I trying to return only function_fullnames from ManualDWARFIndex::GetFunctions when eFunctionNameTypeFull is passed as argument.
Reviewers: labath, jarin, aprantl
Reviewed By: labath
Subscribers: shafik, clayborg, teemperor, arphaman, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D70846
When trying to interpret an expression with a function call, if the
process hasn't been launched, the expression fails to be interpreted
and the user gets the following error message:
```error: Can't run the expression locally```
This message doesn't explain why the expression failed to be
interpreted, that's why this patch improves the error message that is
displayed when trying to run an expression while no process is running.
rdar://11991708
Differential Revision: https://reviews.llvm.org/D72510
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
Makes this function exit early instead of nesting if statements.
Also removed all the if (tag_type->getDecl()) checks. If we created
a TagType with a nullptr as a Decl then Clang would have already
deferenced that nullptr during TagType creation so there is no point
in gracefully handling a nullptr here.
Summary:
This renames the test `rdar-12481949` to `get-value-32bit-int` as it just tests that we return the
correct result get calling GetValueAsSigned/GetValueAsUnsigned on 32-bit integers.
It also deletes all the strange things going on in this test including resetting the data formatters (which are to my
knowledge not used to calculate scalar values) and testing Python's long integers (let's just assume that our Python
distribution works correctly). Also modernises the setup code.
Reviewers: labath, aprantl
Reviewed By: aprantl
Subscribers: JDevlieghere, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D72593
Summary:
Whenever we cast an LLVM instruction to one of its subclasses, we do a double check if the RTTI
enum value actually allows us to cast the class. I don't see a way this can ever happen as even when
LLVM's RTTI system has some corrupt internal state (which we probably should not test in the first
place) we just reuse LLVM RTTI to do the second check.
This also means that if we ever make an actual programming error in this function (e.g., have a enum
value and then cast it to a different subclass), we just silently fall back to the JIT in our tests.
We also can't test this code in any reasonable way.
This removes the checks and uses `llvm::cast` instead which will raise a fatal error when casting fails.
Reviewers: labath, mib
Reviewed By: labath
Subscribers: abidh, JDevlieghere, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D72596
Summary:
`SBThread.GetStopDescription` is a curious API as it takes a buffer length as a parameter that specifies
how many bytes the buffer we pass has. Then we fill the buffer until the specified length (or the length
of the stop description string) and return the string length. If the buffer is a nullptr however, we instead
return how many bytes we would have written to the buffer so that the user can allocate a buffer with
the right size and pass that size to a subsequent `SBThread.GetStopDescription` call.
Funnily enough, it is not possible to pass a nullptr via the Python SWIG bindings, so that might be the
first API in LLDB that is not only hard to use correctly but impossible to use correctly. The only way to
call this function via Python is to throw in a large size limit that is hopefully large enough to contain the
stop description (otherwise we only get the truncated stop description).
Currently passing a size limit that is smaller than the returned stop description doesn't cause the
Python bindings to return the stop description but instead the truncated stop description + uninitialized characters
at the end of the string. The reason for this is that we return the result of `snprintf` from the method
which returns the amount of bytes that *would* have been written (which is larger than the buffer).
This causes our Python bindings to return a string that is as large as full stop description but the
buffer that has been filled is only as large as the passed in buffer size.
This patch fixes this issue by just recalculating the string length in our buffer instead of relying on the wrong
return value. We also have to do this in a new type map as the old type map is also used for all methods
with the given argument pair `char *dst, size_t dst_len` (e.g. SBProcess.GetSTDOUT`). These methods have
different semantics for these arguments and don't null-terminate the returned buffer (they instead return the
size in bytes) so we can't change the existing typemap without breaking them.
Reviewers: labath, jingham
Reviewed By: labath
Subscribers: clayborg, shafik, abidh, JDevlieghere, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D72086
In the documentation of `include_directories`, it notes that
`target_include_directories` is preferred because it affects
specific targets intead of propagating include search paths
to the entire project.
No files in lldb-server are including a header from a plugin without the
whole path to the header relative to the lldb source directory. There is
no need to include the specific directories as a result.
This fixes a failing testcase on Fedora 30 x86_64 (regression Fedora 29->30):
PASS:
./bin/lldb ./lldb-test-build.noindex/functionalities/unwind/noreturn/TestNoreturnUnwind.test_dwarf/a.out -o 'settings set symbols.enable-external-lookup false' -o r -o bt -o quit
* frame #0: 0x00007ffff7aa6e75 libc.so.6`__GI_raise + 325
frame #1: 0x00007ffff7a91895 libc.so.6`__GI_abort + 295
frame #2: 0x0000000000401140 a.out`func_c at main.c:12:2
frame #3: 0x000000000040113a a.out`func_b at main.c:18:2
frame #4: 0x0000000000401134 a.out`func_a at main.c:26:2
frame #5: 0x000000000040112e a.out`main(argc=<unavailable>, argv=<unavailable>) at main.c:32:2
frame #6: 0x00007ffff7a92f33 libc.so.6`__libc_start_main + 243
frame #7: 0x000000000040106e a.out`_start + 46
vs.
FAIL - unrecognized abort() function:
./bin/lldb ./lldb-test-build.noindex/functionalities/unwind/noreturn/TestNoreturnUnwind.test_dwarf/a.out -o 'settings set symbols.enable-external-lookup false' -o r -o bt -o quit
* frame #0: 0x00007ffff7aa6e75 libc.so.6`.annobin_raise.c + 325
frame #1: 0x00007ffff7a91895 libc.so.6`.annobin_loadmsgcat.c_end.unlikely + 295
frame #2: 0x0000000000401140 a.out`func_c at main.c:12:2
frame #3: 0x000000000040113a a.out`func_b at main.c:18:2
frame #4: 0x0000000000401134 a.out`func_a at main.c:26:2
frame #5: 0x000000000040112e a.out`main(argc=<unavailable>, argv=<unavailable>) at main.c:32:2
frame #6: 0x00007ffff7a92f33 libc.so.6`.annobin_libc_start.c + 243
frame #7: 0x000000000040106e a.out`.annobin_init.c.hot + 46
The extra ELF symbols are there due to Annobin (I did not investigate why this
problem happened specifically since F-30 and not since F-28).
It is due to:
Symbol table '.dynsym' contains 2361 entries:
Valu e Size Type Bind Vis Name
0000000000022769 5 FUNC LOCAL DEFAULT _nl_load_domain.cold
000000000002276e 0 NOTYPE LOCAL HIDDEN .annobin_abort.c.unlikely
...
000000000002276e 0 NOTYPE LOCAL HIDDEN .annobin_loadmsgcat.c_end.unlikely
...
000000000002276e 0 NOTYPE LOCAL HIDDEN .annobin_textdomain.c_end.unlikely
000000000002276e 548 FUNC GLOBAL DEFAULT abort
000000000002276e 548 FUNC GLOBAL DEFAULT abort@@GLIBC_2.2.5
000000000002276e 548 FUNC LOCAL DEFAULT __GI_abort
0000000000022992 0 NOTYPE LOCAL HIDDEN .annobin_abort.c_end.unlikely
GDB has some more complicated preferences between overlapping and/or sharing
address symbols, I have made here so far the most simple fix for this case.
Differential revision: https://reviews.llvm.org/D63540
lld in 2bfee35 started emitting relocations for some intra-section jumps
between global symbols. This shifted the code around a bit, invalidating
text expectations.
Change the symbols to local to keep the previous behavior.
Summary:
This just adds `NO_DEBUG_INFO_TESTCASE` to tests that don't really exercise anything debug information specific
and therefore don't need to be rerun for all debug information variants.
Reviewers: labath, jingham, aprantl, mib, jfb
Reviewed By: aprantl
Subscribers: dexonsmith, JDevlieghere, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D72447
The argument is llvm::null() everywhere except llvm::errs() in
llvm-objdump in -DLLVM_ENABLE_ASSERTIONS=On builds. It is used by no
target but X86 in -DLLVM_ENABLE_ASSERTIONS=On builds.
If we ever have the needs to add verbose log to disassemblers, we can
record log with a member function, instead of passing it around as an
argument.
I modified the SBAPI under the assumption that nobody was using the old
API yet. However, that turns out to be false. So instead of adding the
deafault argument I've reintroduced the old API and made the new one an
overload.
This allows an unsanitized test process which loads a sanitized DSO (the
motivating example is a Swift runtime dylib) to launch on Darwin.
rdar://57290132
Differential Revision: https://reviews.llvm.org/D71379
The vim-lldb plugin is unmaintained and doesn't work with a recent vim
installation that uses Python 3. This removes it from the LLDB
repository. The code is still available under lldb-tools on GitHub like
we did with for lldb-mi. (https://github.com/lldb-tools/vim-lldb)
Differential revision: https://reviews.llvm.org/D72541
Rather than serializing every argument through LLDB_TEST_COMMON_ARGS, we
can pass some of them directly using their CMake variable. Although this
does introduce some code duplication between lit's site config and the
lldb-dotest utility, it also means that it becomes easier to override
these values (WIP).
Summary:
In Debug builds we call VerifyDecl in ClangASTContext::CreateFunctionDeclaration which in turn
calls `getAccess` on the created FunctionDecl. As we passed in a RecordDecl as the DeclContext
for the FunctionDecl, we end up hitting the assert in `getAccess` that checks that we never have
a Decl inside a Record without a valid AccessSpecifier. FunctionDecls are never in RecordDecls
(that would be a CXXMethodDecl) so setting a access specifier would not be the correct way to
fix this.
Instead this patch does the same thing that DWARFASTParserClang::ParseSubroutine is doing:
We pass in the FunctionDecl with the TranslationUnit as the DeclContext. That's not ideal but
it is how we currently do it when creating our debug info AST, so the unit test should do
the same.
Reviewers: shafik
Reviewed By: shafik
Subscribers: aprantl, JDevlieghere, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D72359
Summary:
We iterate over `m_decls_to_complete` to complete declarations. As
`m_decls_to_complete` is a set the iteration order can be non-deterministic.
The order is currently only non-deterministic when we have
a large set of decls that need to be completed (i.e. more than 32 decls,
as otherwise the SmallPtrSet is just a linear-searched list).
This doesn't really fix any specific bug or has any really observable
change in behavior as the order in which we import should not influence
any semantics. However the order we create decls/types is now always
deterministic which should make debugging easier.
Reviewers: labath, mib, shafik, davide
Reviewed By: shafik, davide
Subscribers: davide, abidh, JDevlieghere, lldb-commits, mgrang
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D72495
Summary:
This is a port of D67803 that was about preventing indirect importing to our scratch context when evaluating expressions.
D67803 already has a pretty long explanation of how this works, but the idea is that instead
of importing declarations indirectly over the expression AST (i.e., Debug info AST -> Expression AST -> scratch AST)
we instead directly import the declaration from the debug info AST to the scratch AST.
The difference from D67803 is that here we have to do this in the ASTImporterDelegate (which is our ASTImporter
subclass we use in LLDB). It has the same information as the ExternalASTMerger in D67803 as it can access the
ClangASTImporter (which also keeps track of where Decls originally came from).
With this patch we can also delete the FieldDecl stealing hack in the ClangASTSource (this was only necessary as the
indirect imports caused the creation of duplicate Record declarations but we needed the fields in the Record decl
we originally found in the scratch ASTContext).
This also fixes the current gmodules failures where we fail to find std::vector fields after an indirect import
over the expression AST (where it seems even our FieldDecl stealing hack can't save us from).
Reviewers: shafik, aprantl
Reviewed By: shafik
Subscribers: JDevlieghere, lldb-commits, mib, labath, friss
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D72507
GetPersistentExpressionStateForLanguage() can return a nullptr if it
cannot construct a typesystem. This patch adds missing nullptr checks
at all uses.
Inspired by rdar://problem/58317195
Differential Revision: https://reviews.llvm.org/D72413
There already are decorators and "--excluded" option to mark test-cases/files
as expected to fail. However, when a new test file is added and it which relates
to a feature that a target doesn't support, this requires either adding decorators
to that file or modifying the file provided as "--excluded" option value.
The purpose of this patch is to avoid any modifications in such cases.
E.g. if a target doesn't support "watchpoints" and passes "--xfail-category watchpoint"
to dotest, a testing job will not fail after a new watchpoint-related test file is added.
Differential Revision: https://reviews.llvm.org/D71906
As suggested by @labath extended RangeDataVector so that user can provide
custom sorting of the Entry's `data' field for D63540.
https://reviews.llvm.org/D63540
RangeData functions were used just by RangeDataVector (=after I removed them
LLDB still builds fine) which no longer uses them so I removed them.
Differential revision: https://reviews.llvm.org/D72460
This is needed to not re-write parent's categories by categories of a nested folder,
e.g. commands/expression/completion specify "cmdline" category, however it still belongs
to parent's "expression" category.
The sentinel ".categories" in the test-suite root directory is no longer needed.
Differential Revision: https://reviews.llvm.org/D71905
Gcc produces this (technically correct) warning when storing an
explicitly-sized enum in a bitfield. Surpress that by changing the type
of the bitfield to an integer. The same approach is used elsewhere in
llvm (e.g. 56b5eab12).
This patch removes the code (deep inside DWARFDebugInfoEntry) which
automagically returned the attributes of the dwo unit DIE when asking
for the attributes of the skeleton unit. This is fairly hacky, and not
consistent with how llvm DWARF parser operates.
Instead, I change the code the explicitly request (via
GetNonSkeletonUnit) the right unit to search (there were just two places
that needed this). If it turns out we need this more often, we can
create a utility function (external to DWARFUnit) for doing this.
Summary:
Motivation: When formatting an array of typedefed chars, we would like to display the array as a string.
The string formatter currently does not trigger because the formatter lookup does not resolve typedefs for array elements (this behavior is inconsistent with pointers, for those we do look through pointee typedefs). This patch tries to make the array formatter lookup somewhat consistent with the pointer formatter lookup.
Reviewers: teemperor, clayborg
Reviewed By: teemperor, clayborg
Subscribers: clayborg, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D72133
qemu has a very small maximum packet size (4096) and it actually
only uses half of that buffer for some implementation reason,
so when lldb asks for the register target definitions, the x86_64
definition is larger than 4096/2 and we need to fetch it in two parts.
This patch and test is fixing a bug in
GDBRemoteCommunicationClient::ReadExtFeature when reading a target
file in multiple parts. lldb was assuming that it would always
get back the maximum packet size response (4096) instead of
using the actual size received and asking for the next group of
bytes.
We now have two tests in gdb_remote_client for unique features
of qemu - TestNestedRegDefinitions.py would test the ability
of lldb to follow multiple levels of xml includes; I opted to
create a separate TestRegDefinitionInParts.py test to test this
wrinkle in qemu's gdb remote serial protocol stub implementation.
Instead of combining both tests into a single test file.
<rdar://problem/49537922>
All the code required to generate the language bindings for Python and
Lua lives under scripts, even though the majority of this code aren't
scripts at all, and surrounded by scripts that are totally unrelated.
I've reorganized these files and moved everything related to the
language bindings into a new top-level directory named bindings. This
makes the corresponding files self contained and much more discoverable.
Differential revision: https://reviews.llvm.org/D72437
The Python script interpreter makes the current debugger, target,
process, thread and frame available to interactive scripting sessions
through convenience variables. This patch does the same for Lua.
Differential revision: https://reviews.llvm.org/D71801
Making the string conversion operator a macro unintentionally dropped
the backslash before '\n' and '\r' and was therefore incorrectly
stripping 'n' and 'r' from the object description.
Summary:
Our code was expecting that a single (symbol) file contains only one
kind of location lists. This is not correct (on non-apple platforms, at
least) as a file can compile units with different dwarf versions.
This patch moves the deteremination of location list flavour down to the
compile unit level, fixing this problem. I have also tried to rougly
align the code with the llvm DWARFUnit. Fully matching the API is not
possible because of how lldb's DWARFExpression lives separately from the
rest of the DWARF code, but this is at least a step in the right
direction.
Reviewers: JDevlieghere, aprantl, clayborg
Subscribers: dblaikie, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D71751
Summary:
A skeleton unit can easily be detected by checking the m_dwo_symbol_file
member, but we cannot tell a split unit from a normal unit from the
"inside", which is sometimes useful.
This patch adds a m_is_dwo member to enable this, and align the code
with llvm::DWARFUnit. Right now it's only used to avoid creating a split
unit inside another split unit (which removes one override from
SymbolFileDWARFDwo and brings us a step closer to deleting it), but my
main motivation is fixing the handling of location lists in mixed v4&v5
files. This comes in a separate patch.
Reviewers: JDevlieghere, aprantl, clayborg
Subscribers: dblaikie, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D71750
The command here failed due to the type in 'create' but the expect
did not actually check for the error message. This fixes the typo
and adds a check for the actuall error message we should see.
The current SWIG extensions for the string conversion operator is Python
specific because it uses the PythonObjects. This means that the code
cannot be reused for other SWIG supported languages such as Lua.
This reimplements the extensions in a more generic way that can be
reused. It uses a SWIG macro to reduce code duplication.
Differential revision: https://reviews.llvm.org/D72377
When lldb requests an app launch through FrontBoard/BackBoard,
we get back an NSError object if there was a problem with an
integer error code and a descriptive text string. debugserver
would log the descriptive text string to the console, but it
would only save the error code value, ask for the
much-less-specific name of that error code, and send that very
generic error word back to lldb.
This patch saves the longer description of the failure when
available, and sends that to lldb. If unavailable, it falls
back to sending up the generic description of the error code
as it was doing before.
This only impacts the iOS on-device debugserver.
<rdar://problem/49953304>
The current SWIG extensions for the string conversion operator is Python
specific because it uses the PythonObjects. This means that the code
cannot be reused for other SWIG supported languages such as Lua.
This reimplements the extensions in a more generic way that can be
reused. It uses a SWIG macro to reduce code duplication.
Differential revision: https://reviews.llvm.org/D72377
Just like Python, Lua should only be auto-enabled if SWIG is found as
well. This moves the logic of finding SWIG and Lua as a whole into a new
CMake package.
The current SWIG extensions for the string conversion operator is Python
specific because it uses the PythonObjects. This means that the code
cannot be reused for other SWIG supported languages such as Lua.
This reimplements the extensions in a more generic way that can be
reused.
Differential revision: https://reviews.llvm.org/D72377
Libxml2 is already an optional dependency. It should use the same
infrastructure as the other dependencies.
Differential revision: https://reviews.llvm.org/D72290
Creating an ASTContext with an unknown triple is rarely a good idea (as usually
all our ASTs have a valid triple that is either from the host or the target) and the
default argument makes it far to easy to implicitly create such an AST. Let's
remove it and force people to pass a triple.
The only place where we don't pass a triple is a DWARFASTParserClangTests
where we now just pass the host triple instead (the test doesn't depend on any
triple so this shouldn't change anything).
ArchSpec has a superset of the information of llvm::Triple but the ClangASTContext
just uses the Triple part of it. This deletes the ArchSpec constructor and all
the code creating ArchSpecs and instead just uses the llvm::Triple constructor
for ClangASTContext.
As correctly pointed out by Martin on the mailing list, Python should
only be auto-enabled if SWIG is found as well. This moves the logic of
finding SWIG into FindPythonInterpAndLibs to make that possible.
To make diagnosing easier I've included a status message to convey why
Python support is disabled.
In TestConvenienceVariables I changed %t from a file to a directory.
This tripped up mkdir which can't deal with an existing file at the
given location. In order to solve this issue on the bots I added an
`rm -rf %t` statement, but now the Windows bot complains that "This
function is not supported on this system".
If you never ran the test suite wit this temporary workaround, the test
might fail. If this happens please remove what %t expands to in the lit
output and rerun the test.
This was returning a pointer to a stack-allocated memory location. This
works for Python where we return a PythonString which must own the
underlying string.
Extend the SBTarget class with a string conversion operator and reuse
the same code between Python and Lua. This should happen for all the SB
classes, but I'm doing just this one as an example and for use in a test
case.
This test was passing even when the output of lldb.target was empty.
I've made the test more strict by checking explicitly for the target
name and by using CHECK-NEXT lines.
Extend the SBTarget class with a string conversion operator and reuse
the same code between Python and Lua. This should happen for all the SB
classes, but I'm doing just this one as an example and for use in a test
case.
Summary: There are a few places in LLDB where we do a `reinterpret_cast` for conversions that we could also do with `static_cast`. This patch moves all this code to `static_cast`.
Reviewers: shafik, JDevlieghere, labath
Reviewed By: labath
Subscribers: arphaman, usaxena95, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D72161
This constructor is supposed to take a string representing an llvm::Triple.
We might as well take a llvm::Triple here which saves us all the string
conversions in the call sites and we make this more type safe.
Looking at a sometimes-passing test case on a platform
where random values were being returned - sometimes
the expected digit ('1' or '2') would be included in the
random returned value. Add a prefix to reduce the likelihood of
this a bit.
My earlier change for Python auto-detection caused PYTHON_HOME to be set
unconditionally, while before the change this only happened for Windows.
This caused the PythonDataObjectsTest to fail with an import error.
Summary:
lib/python2.7/dist-packages/lldb/_lldb.so is a symlink to lib/liblldb.so,
which depends on lib/libLLVM*.so (-DBUILD_SHARED_LIBS=ON) or lib/libLLVM-10git.so
(-DLLVM_LINK_LLVM_DYLIB=ON). Add an additional rpath `$ORIGIN/../../../../lib` so
that _lldb.so can be loaded from Python.
This fixes an import error from lib/python2.7/dist-packages/lldb/__init__.py
from . import _lldb
ImportError: libLLVMAArch64CodeGen.so.10git: cannot open shared object file: No such file or directory
The following configurations will work:
* -DBUILD_SHARED_LIBS=ON
* -DBUILD_SHARED_LIBS=OFF -DLLVM_LINK_LLVM_DYLIB=ON
* -DBUILD_SHARED_LIBS=OFF -DLLVM_LINK_LLVM_DYLIB=ON -DCLANG_LINK_CLANG_DYLIB=ON
(-DCLANG_LINK_CLANG_DYLIB=ON depends on -DLLVM_LINK_LLVM_DYLIB=ON)
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D71800
Python was the last remaining "optional" dependency for LLDB. This moves
the code to find Python into FindPythonInterpAndLibs using the same
principles as FindCursesAndPanel.
Differential revision: https://reviews.llvm.org/D72107
orig_*ax logic is Linux-specific, and was never used on NetBSD.
In fact, its support seems to be a dead code entirely.
Differential Revision: https://reviews.llvm.org/D72195
Currently, there is no option to delete all the watchpoint without LLDB
asking for a confirmation. Besides making the watchpoint delete command
homogeneous with the breakpoint delete command, this option could also
become handy to trigger automated watchpoint deletion i.e. using
breakpoint actions.
rdar://42560586
Differential Revision: https://reviews.llvm.org/D72096
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
It's not up to YAML to validate the semantics of the GDB remote packet
struct. This is especially wrong here as there's nothing that says that
the amount of bytes transmitted matches the packet payload size.
There is no clang::Action anymore so our forward decl for it and the obsolete pointer in the
ASTStructExtractor can both go (that code anyway didn't do anything).
Currently, there is no option to delete all the watchpoint without LLDB
asking for a confirmation. Besides making the watchpoint delete command
homogeneous with the breakpoint delete command, this option could also
become handy to trigger automated watchpoint deletion i.e. using
breakpoint actions.
rdar://42560586
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
Use a status message to convey whether an optional dependency was found
or not. With the auto-detection code it's not longer as simple as
checking the CMake cache.
The current FOUND_VAR for FindLibEdit is libedit_FOUND but wasn't set by
find_package_handle_standard_args. However this isn't valid for the
package name.
The argument for FOUND_VAR is "libedit_FOUND", but only "LibEdit_FOUND" and
"LIBEDIT_FOUND" are valid names.
This fixes all the variables set by FindLibEdit to match the desired
naming scheme.
PYTHON_LIBRARIES is the canonical variable set by FindPythonLibs while
PYTHON_LIBRARY is an implementation detail. This replaces the uses of
the latter with the former.
Rather than handling zlib handling manually, use `find_package` from CMake
to find zlib properly. Use this to normalize the `LLVM_ENABLE_ZLIB`,
`HAVE_ZLIB`, `HAVE_ZLIB_H`. Furthermore, require zlib if `LLVM_ENABLE_ZLIB` is
set to `YES`, which requires the distributor to explicitly select whether
zlib is enabled or not. This simplifies the CMake handling and usage in
the rest of the tooling.
This restores 68a235d07f,
e6c7ed6d21. The problem with the windows
bot is a need for clearing the cache.
This reverts commit 68a235d07f.
This commit broke the clang-x64-windows-msvc build bot and a follow-up
commit did not fix it. Reverting to fix the bot.
Summary:
We currently don't set access specifiers for function template declarations. This seems to be fine
as long as the function template is not declared inside any record in which case Clang asserts
with the following once we try to query it's access:
```
Assertion failed: (Access != AS_none && "Access specifier is AS_none inside a record decl"), function AccessDeclContextSanity,
```
This patch just marks these function template declarations as public to make Clang happy.
Reviewers: shafik, teemperor
Reviewed By: teemperor
Subscribers: JDevlieghere, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D71909
LLDB frequently converts QualType to CompilerType. This is currently done like this:
result = CompilerType(this, qual_type_var.getAsOpaquePtr())
There are a few shortcomings in this current approach:
1. CompilerType's constructor takes a void* pointer so it isn't type safe.
2. We can't add any sanity checks to the CompilerType constructor (e.g. that the type
actually belongs to the passed ClangASTContext) without expanding the TypeSystem API.
3. The logic for converting QualType->CompilerType is spread out over all of LLDB so
changing it is difficult (e.g., what if we want to just pass the type ptr and not the
1type_ptr | qual_flags1 to CompilerType).
This patch adds a `ClangASTContext::GetType` function similar to the other GetTypeForDecl
functions that does this conversion in a type safe way.
It also adds a sanity check for Tag-based types that the type actually belongs to the
current ClangASTContext (Types don't seem to know their ASTContext, so we have to
workaround by looking at the decl for the underlying TagDecl. This doesn't cover all types
we construct but it's better than no sanity check).
Rather than handling zlib handling manually, use `find_package` from CMake
to find zlib properly. Use this to normalize the `LLVM_ENABLE_ZLIB`,
`HAVE_ZLIB`, `HAVE_ZLIB_H`. Furthermore, require zlib if `LLVM_ENABLE_ZLIB` is
set to `YES`, which requires the distributor to explicitly select whether
zlib is enabled or not. This simplifies the CMake handling and usage in
the rest of the tooling.
Now that we are building the python bindings on Windows once more, the
extended testsuite is running. Mark a few failing tests and skip a few
tests which hang. This should at least bring the bot back to green
without reverting the Python changes which are an improvement for the
build system and enable another ~35% of the test suite which was
previously disabled.
CompilerType has no virtual functions and no statements in its constructors,
so we can simplify this code. This also allows Clang to emit unused variable warnings
for CompilerType, so I also removed one unused variable that otherwise causes -Werror
builds to fail.
These functions need a ClangASTContext instance that we would otherwise
recalculate by calling GetASTContext (which is no longer necessary with
this patch).
We try to build a CompilerType from the persistent decls so we need
a ClangASTContext. With this patch the ClangPersistentVariables store
the associated ClangASTContext of the persistent decls (which is
always the scratch ClangASTContext) and no longer call GetASTContext
to map back from clang::ASTContext to ClangASTContext.
Fred Riss