Summary:
This is the next step in avoiding funneling all SymbolFile calls through
the SymbolVendor. Right now, it is just a convenience function, but it
allows us to update all calls to SymbolVendor functions to access the
SymbolFile directly. Once all call sites have been updated, we can
remove the GetSymbolVendor member function.
This patch just updates the calls to GetSymbolVendor, which were calling
it just so they could fetch the underlying symbol file. Other calls will
be done in follow-ups.
Reviewers: JDevlieghere, clayborg, jingham
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D65435
llvm-svn: 367664
This patch replaces explicit calls to log::Printf with the new LLDB_LOGF
macro. The macro is similar to LLDB_LOG but supports printf-style format
strings, instead of formatv-style format strings.
So instead of writing:
if (log)
log->Printf("%s\n", str);
You'd write:
LLDB_LOG(log, "%s\n", str);
This change was done mechanically with the command below. I replaced the
spurious if-checks with vim, since I know how to do multi-line
replacements with it.
find . -type f -name '*.cpp' -exec \
sed -i '' -E 's/log->Printf\(/LLDB_LOGF\(log, /g' "{}" +
Differential revision: https://reviews.llvm.org/D65128
llvm-svn: 366936
Summary:
Move checking pointer code block before accessing the pointer
This caused lldb to crash when testing on Android
Patch by Wanyi Ye!
Differential Revision: https://reviews.llvm.org/D64434
llvm-svn: 365567
This was set in a std::function, but I was shadowing a
variable that I thought I was capturing. Even with this bug
we were correctly not raising an error and returning an address
of 0x0. We were not marking the symbol as weak, but apparently
the JIT didn't need that, so the test still passed.
llvm-svn: 364980
Summary:
LookupRuntimeSymbol seems like a general LanguageRuntime method.
Although no other language runtime currently implements this, there's no
reason another language runtime couldn't use this.
Additionally, this breaks IRExecutionUnit's dependency on
ObjCLanguageRuntime.
Reviewers: compnerd, labath, JDevlieghere, davide
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D62795
llvm-svn: 362458
Summary:
NFC = [[ https://llvm.org/docs/Lexicon.html#nfc | Non functional change ]]
This commit is the result of modernizing the LLDB codebase by using
`nullptr` instread of `0` or `NULL`. See
https://clang.llvm.org/extra/clang-tidy/checks/modernize-use-nullptr.html
for more information.
This is the command I ran and I to fix and format the code base:
```
run-clang-tidy.py \
-header-filter='.*' \
-checks='-*,modernize-use-nullptr' \
-fix ~/dev/llvm-project/lldb/.* \
-format \
-style LLVM \
-p ~/llvm-builds/debug-ninja-gcc
```
NOTE: There were also changes to `llvm/utils/unittest` but I did not
include them because I felt that maybe this library shall be updated in
isolation somehow.
NOTE: I know this is a rather large commit but it is a nobrainer in most
parts.
Reviewers: martong, espindola, shafik, #lldb, JDevlieghere
Reviewed By: JDevlieghere
Subscribers: arsenm, jvesely, nhaehnle, hiraditya, JDevlieghere, teemperor, rnkovacs, emaste, kubamracek, nemanjai, ki.stfu, javed.absar, arichardson, kbarton, jrtc27, MaskRay, atanasyan, dexonsmith, arphaman, jfb, jsji, jdoerfert, lldb-commits, llvm-commits
Tags: #lldb, #llvm
Differential Revision: https://reviews.llvm.org/D61847
llvm-svn: 361484
The Windows Code Generation model cannot generation code with the PIC relocation
model - all code is implicitly position independent due to the DLL load slide
that occurs if it is not loaded at the preferred base address. Invert the
condition and inline the single use of the variable. This should also aid the
WASM target. This significantly improves the state of the (swift) repl on
Windows (and should aid in expression evaluation on Windows).
llvm-svn: 361443
My apologies for the large patch. With the exception of ConstString.h
itself it was entirely produced by sed.
ConstString has exactly one const char * data member, so passing a
ConstString by reference is not any more efficient than copying it by
value. In both cases a single pointer is passed. But passing it by
value makes it harder to accidentally return the address of a local
object.
(This fixes rdar://problem/48640859 for the Apple folks)
Differential Revision: https://reviews.llvm.org/D59030
llvm-svn: 355553
The `ap` suffix is a remnant of lldb's former use of auto pointers,
before they got deprecated. Although all their uses were replaced by
unique pointers, some variables still carried the suffix.
In r353795 I removed another auto_ptr remnant, namely redundant calls to
::get for unique_pointers. Jim justly noted that this is a good
opportunity to clean up the variable names as well.
I went over all the changes to ensure my find-and-replace didn't have
any undesired side-effects. I hope I didn't miss any, but if you end up
at this commit doing a git blame on a weirdly named variable, please
know that the change was unintentional.
llvm-svn: 353912
to reflect the new license.
We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.
Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.
llvm-svn: 351636
Summary:
instead of returning the architecture through by-ref argument and a
boolean value indicating success, we can just return the ArchSpec
directly. Since the ArchSpec already has an invalid state, it can be
used to denote the failure without the additional bool.
Reviewers: clayborg, zturner, espindola
Subscribers: emaste, arichardson, JDevlieghere, lldb-commits
Differential Revision: https://reviews.llvm.org/D56129
llvm-svn: 350291
Summary:
This patch contains several small fixes, which makes it possible to evaluate
expressions on Windows using information from PDB. The changes are:
- several sanitize checks;
- make IRExecutionUnit::MemoryManager::getSymbolAddress to not return a magic
value on a failure, because callers wait 0 in this case;
- entry point required to be a file address, not RVA, in the ObjectFilePECOFF;
- do not crash on a debuggee second chance exception - it may be an expression
evaluation crash. Also fix detection of "crushed" threads in tests;
- create parameter declarations for functions in AST to make it possible to call
debugee functions from expressions;
- relax name searching rules for variables, functions, namespaces and types. Now
it works just like in the DWARF plugin;
- fix endless recursion in SymbolFilePDB::ParseCompileUnitFunctionForPDBFunc.
Reviewers: zturner, asmith, stella.stamenova
Reviewed By: stella.stamenova, asmith
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D53759
llvm-svn: 348136
This reverts commit dec87759523b2f22fcff3325bc2cd543e4cda0e7.
This commit caused the tests on Windows to run forever rather than complete.
Reverting until the commit can be fixed to not stall.
llvm-svn: 348009
Summary:
This patch contains several small fixes, which makes it possible to evaluate
expressions on Windows using information from PDB. The changes are:
- several sanitize checks;
- make IRExecutionUnit::MemoryManager::getSymbolAddress to not return a magic
value on a failure, because callers wait 0 in this case;
- entry point required to be a file address, not RVA, in the ObjectFilePECOFF;
- do not crash on a debuggee second chance exception - it may be an expression
evaluation crash;
- create parameter declarations for functions in AST to make it possible to call
debugee functions from expressions;
- relax name searching rules for variables, functions, namespaces and types. Now
it works just like in the DWARF plugin;
- fix endless recursion in SymbolFilePDB::ParseCompileUnitFunctionForPDBFunc.
Reviewers: zturner, asmith, stella.stamenova
Reviewed By: stella.stamenova, asmith
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D53759
llvm-svn: 347962
This is similar to D53597, but following up with 2 more enums.
After this, all flag enums should be strongly typed all the way
through to the symbol files plugins.
Differential Revision: https://reviews.llvm.org/D53616
llvm-svn: 345314
This implements the support for .debug_loclists section, which is
DWARF 5 version of .debug_loc.
Currently, clang is able to emit it with the use of D53365.
Differential revision: https://reviews.llvm.org/D53436
llvm-svn: 345016
The only reason this was here was so that Module could have a
function called CreateJITModule which created things in a special
order. Instead of making this specific to creating JIT modules,
I converted this into a template function that can create a module
for any type of object file plugin and just forwards arguments
through. Since the template is not instantiated in Core, the linker
(and header file) dependency moves to the point where it is
instantiated, which only happens in Expression. Conceptually, this
location also makes more sense for a dependency on ObjectFileJIT.
After all, we JIT expressions so it's no surprise that Expression
needs to make use of ObjectFileJIT.
Differential Revision: https://reviews.llvm.org/D47228
llvm-svn: 333143
This is intended as a clean up after the big clang-format commit
(r280751), which unfortunately resulted in many of the comment
paragraphs in LLDB being very hard to read.
FYI, the script I used was:
import textwrap
import commands
import os
import sys
import re
tmp = "%s.tmp"%sys.argv[1]
out = open(tmp, "w+")
with open(sys.argv[1], "r") as f:
header = ""
text = ""
comment = re.compile(r'^( *//) ([^ ].*)$')
special = re.compile(r'^((([A-Z]+[: ])|([0-9]+ )).*)|(.*;)$')
for line in f:
match = comment.match(line)
if match and not special.match(match.group(2)):
# skip intentionally short comments.
if not text and len(match.group(2)) < 40:
out.write(line)
continue
if text:
text += " " + match.group(2)
else:
header = match.group(1)
text = match.group(2)
continue
if text:
filled = textwrap.wrap(text, width=(78-len(header)),
break_long_words=False)
for l in filled:
out.write(header+" "+l+'\n')
text = ""
out.write(line)
os.rename(tmp, sys.argv[1])
Differential Revision: https://reviews.llvm.org/D46144
llvm-svn: 331197
This commit really did not introduce any functional changes (for most
people) but it turns out it's not for the reason we thought it was.
The reason wasn't that Orc is a perfect drop-in replacement for MCJIT,
but it was because we were never using Orc in the first place, as it was
not initialized.
Orc's initialization relies on a global constructor in the LLVMOrcJIT.a.
Since this archive does not expose any symbols referenced from other
object files, it does not get linked into liblldb when linking against
llvm components statically. However, in an LLVM_LINK_LLVM_DYLIB=On
build, LLVMOrcJit.a is linked into libLLVM.so using --whole-archive, so
the global constructor does end up firing.
The result of using Orc jit is pr34194, where lldb fails to evaluate
even very simple expressions. This bug can be reproduced in
non-LLVM_LINK_LLVM_DYLIB builds by making sure Orc jit is linked into
liblldb, for example by #including
llvm/ExecutionEngine/OrcMCJITReplacement.h in IRExecutionUnit.cpp (and
adding OrcJIT as a dependency to the relevant CMakeLists.txt file). The
bug reproduces (at least) on linux and osx.
The root cause of the bug seems to be related to relocation processing.
It seems Orc processes relocations earlier than the system it is
replacing. This means the relocation processing happens before we have
had a chance to remap section load addresses to reflect their address in
the target process memory, so they end up pointing to locations in the
lldb's address space instead.
I am not sure whether this is a bug in Orc jit, or in how we are using
it from lldb, but in any case it is preventing us from using Orc right
now. Reverting this fixes LLVM_LINK_LLVM_DYLIB build, and makes it clear
that we are in fact *not* using Orc, and we never really were.
This reverts commit r279327.
llvm-svn: 318039
Summary:
The DWP (DWARF package) format is used to pack multiple dwo files
generated by split-dwarf into a single ELF file to make distributing
them easier. It is part of the DWARFv5 spec and can be generated by
dwp or llvm-dwp from a set of dwo files.
Caviats:
* Only the new version of the dwp format is supported (v2 in GNU
numbering schema and v5 in the DWARF spec). The old version (v1) is
already deprecated but binutils 2.24 still generates that one.
* Combining DWP files with module debugging is not yet supported.
Subscribers: emaste, mgorny, aprantl
Differential Revision: https://reviews.llvm.org/D36062
llvm-svn: 311775
This renames the LLDB error class to Status, as discussed
on the lldb-dev mailing list.
A change of this magnitude cannot easily be done without
find and replace, but that has potential to catch unwanted
occurrences of common strings such as "Error". Every effort
was made to find all the obvious things such as the word "Error"
appearing in a string, etc, but it's possible there are still
some lingering occurences left around. Hopefully nothing too
serious.
llvm-svn: 302872
All references to Host and Core have been removed, so this
class can now safely be lowered into Utility.
Differential Revision: https://reviews.llvm.org/D30559
llvm-svn: 296909
This is a redux of [Ewan's patch](https://reviews.llvm.org/D17957) , refactored
to properly substitute primitive types using a hook in the itanium demangler,
and updated after the previous patch went stale
The new `SubsPrimitiveParmItanium` function takes a symbol name and replacement
primitive type parameter as before but parses it using the FastDemangler, which
has been modified to be able to notify clients of parse events (primitive types
at this point).
Additionally, we now use a `set` of `ConstStrings` instead of a `vector` so
that we don't try and resolve the same invalid candidate multiple times.
Differential Revision: https://reviews.llvm.org/D27223
Subscribers: lldb-commits
llvm-svn: 290117
This is a large API change that removes the two functions from
StreamString that return a std::string& and a const std::string&,
and instead provide one function which returns a StringRef.
Direct access to the underlying buffer violates the concept of
a "stream" which is intended to provide forward only access,
and makes porting to llvm::raw_ostream more difficult in the
future.
Differential Revision: https://reviews.llvm.org/D26698
llvm-svn: 287152
This allows debugging of the JIT and other analyses of the internals of the
expression parser. I've also added a testcase that verifies that the setting
works correctly when off and on.
llvm-svn: 282434
*** to conform to clang-format’s LLVM style. This kind of mass change has
*** two obvious implications:
Firstly, merging this particular commit into a downstream fork may be a huge
effort. Alternatively, it may be worth merging all changes up to this commit,
performing the same reformatting operation locally, and then discarding the
merge for this particular commit. The commands used to accomplish this
reformatting were as follows (with current working directory as the root of
the repository):
find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} +
find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ;
The version of clang-format used was 3.9.0, and autopep8 was 1.2.4.
Secondly, “blame” style tools will generally point to this commit instead of
a meaningful prior commit. There are alternatives available that will attempt
to look through this change and find the appropriate prior commit. YMMV.
llvm-svn: 280751
expression evaluation.
OrcMCJITReplacement is a reimplementation of MCJIT using ORC components, and
provides an easy upgrade path to ORC for existing MCJIT clients. There should be
no functional changes resulting from this switch.
llvm-svn: 279327
Summary:
Without this commit, when `log enable lldb expr` is enabled, the
disassembly of JIT'ed code is never displayed.
Reviewers: spyffe, clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D20312
llvm-svn: 271863
Some compilers do not mark up C++ functions as extern "C" in the DWARF, so LLDB
has to fall back (if it is about to give up finding a symbol) to using the base
name of the function.
This fix also ensures that we search by full name rather than "auto," which
could cause unrelated C++ names to be found. Finally, it adds a test case.
<rdar://problem/25094302>
llvm-svn: 271551
This is a pretty straightforward first pass over removing a number of uses of
Mutex in favor of std::mutex or std::recursive_mutex. The problem is that there
are interfaces which take Mutex::Locker & to lock internal locks. This patch
cleans up most of the easy cases. The only non-trivial change is in
CommandObjectTarget.cpp where a Mutex::Locker was split into two.
llvm-svn: 269877
They're not supposed to go in the symbol table, and in fact the way the JIT
is currently implemented it sometimes crashes when you try to get the
address of such a function. So we skip them.
llvm-svn: 264821
IRExecutionUnits contain code and data that persistent declarations can
depend on. In order to keep them alive and provide for lookup of these
symbols, we now allow any PersistentExpressionState to keep a list of
execution units. Then, when doing symbol lookup on behalf of an
expression, any IRExecutionUnit can consult the persistent expression
states on a particular Target to find the appropriate symbol.
<rdar://problem/22864976>
llvm-svn: 263995
Summary:
From Adrian McCarthy:
"Running ninja check-lldb now has one crash in a Python process, due to deferencing a null pointer in IRExecutionUnit.cpp: candidate_sc.symbol is null, which leads to a call with a null this pointer."
Reviewers: zturner, spyffe, amccarth
Subscribers: ted, jingham, lldb-commits
Differential Revision: http://reviews.llvm.org/D17860
llvm-svn: 263066
Summary: Recent changes to the expression parser broke function name resolution when using the IR interpreter instead of JIT. This patch changes the IRMemoryMap ivar in InterpreterStackFrame to an IRExecutionUnitSP (which is a subclass), allowing InterpreterStackFrame::ResolveConstantValue() to call FindSymbol() on the name of the Value when it's a FunctionVal. It also changes IRExecutionUnit::FindInSymbols() to call GetFileAddress() on the symball if ResolveCallableAddress() fails and there is no valid Process.
Reviewers: spyffe
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D17745
llvm-svn: 262407
IRExecutionUnit previously replicated a bunch of logic that already
existed elsewhere for the purpose of getting a load address for a
symbol. This approach failed to resolve certain types of symbols.
Instead, we now use functions on SymbolContext to do the address
resolution.
This is a cleanup of IRExecutionUnit::FindInSymbols, and also fixes a
latent bug where we looked at the wrong SymbolContext to determine
whether or not it is external.
<rdar://problem/24770829>
llvm-svn: 261704
Previously we would try both versions of a symbol -- the one with _ in it and
the one without -- in all cases, because we didn't know what the current
platform's policy was. However, stripping _ is only necessary on platforms
where _ is the prefix for global symbols.
There's an API that does this, though, on llvm::DataLayout, so this patch fixes
IRExecutionUnit to use that API to determine whether or not to strip _ from the
symbol or not.
llvm-svn: 260767
I'm preparing to remove symbol lookup from IRForTarget, where it constitutes a
dreadful hack working around no-longer-existing JIT bugs. Thanks to our
contributors, IRForTarget has a lot of smarts that IRExecutionUnit doesn't have,
so I've cleaned them up a bit and moved them over to IRExecutionUnit.
Also for historical reasons, IRExecutionUnit used the "Small" code model on non-
ELF platforms (namely, OS X). That's no longer necessary, and we can use the
same code model as everyone else on OS X. I've fixed that.
llvm-svn: 260734
Pavel Labath