| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
DynamicLoaderDarwinKernel::KextImageInfo::LoadImageUsingMemoryModule a
bit so that we only read the binaries out of memory once we've
determined that we can find a real binary on the local system.
Previously, lldb would read all of the kext binaries out of memory
and then determine if it had the local copy. The kext table gives
us most the information we need (address, name, uuid) so lldb only
needs the actual in-memory load commands when it comes time to set
the section load addresses. Delay reading until that point for all
the kexts.
NFC; doing the operations in a different order.
<rdar://problem/41181173>
llvm-svn: 356108
|
|
|
|
|
|
|
|
|
|
|
| |
Python 3 default encoding is utf-8, so taking random bytes and
interpreting them as a string might result in invalid unicode sequences.
As the only thing we care about here is that the formatter shows the
elements of the underyling array, relax the string matching (this is
good enough as all the elements are distinct so they resolve to different
strings).
llvm-svn: 356096
|
|
|
|
|
|
|
|
|
|
| |
This was found by the green dragon sanitizer bot.
rdar://problem/48536644
Differential Revision: https://reviews.llvm.org/D59314
llvm-svn: 356090
|
|
|
|
|
|
|
|
|
| |
resolving clang resource dir
I committed a change that removed this line, but I meant to restore it
befor committing.
llvm-svn: 356079
|
|
|
|
| |
llvm-svn: 356073
|
|
|
|
|
|
| |
One of Davide's changes yesterday fixed the behavior on Windows, so the test is now passing.
llvm-svn: 356065
|
|
|
|
|
|
| |
This should finally fix TestPaths.py.
llvm-svn: 356057
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
In my next step at cleaning up modify-python-lldb.py, I started focusing
on equality comparison. To my surprise, I found out that both python and
c++ versions of the SBType class implement equality comparison, but each
one does it differently. While the python version was implemented in
terms of type name equality, the C++ one used a deep comparison on the
underlying objects.
Removing the python version caused one test to fail (TestTypeList). This
happened because the c++ version of operator== boiled down to
TypePair::operator==, which contains two items: the compiler_type and
type_sp. In this case, the compiler_type was identical, but one of the
objects had the type_sp field unset.
I tried fixing the code so that both objects keep their type_sp member,
but it wasn't easy, because there are so many operations which just work
with the CompilerType types, and so any operation on the SBType (the
test in question was doing GetPointeeType on the type of one variable
and expecting it to match the type of another variable), cause that
second member to be lost.
So instead, here I relax the equality comparison on the TypePair
class. Now, this class ignores the type_sp for the purposes of
comparison, and uses the CompilerType only. This seems reasonable, as
each TypeSP is able to convert itself to a CompilerType.
Reviewers: clayborg, aprantl, serge-sans-paille
Subscribers: jdoerfert, lldb-commits
Differential Revision: https://reviews.llvm.org/D59217
llvm-svn: 356048
|
|
|
|
| |
llvm-svn: 356003
|
|
|
|
|
|
|
| |
They can be reinstated in case somebody needs to debug
this test in the future.
llvm-svn: 356002
|
|
|
|
| |
llvm-svn: 356000
|
|
|
|
|
|
|
|
| |
Given this was under trace, it can just be removed. If somebody
ever needs to debug this testcase again and print the data, they
can add a new statement.
llvm-svn: 355999
|
|
|
|
| |
llvm-svn: 355998
|
|
|
|
|
|
| |
comply with the more pedantic TestPaths.py
llvm-svn: 355994
|
|
|
|
|
|
| |
Disable it for now till I can figure out what's going wrong.
llvm-svn: 355992
|
|
|
|
| |
llvm-svn: 355991
|
|
|
|
| |
llvm-svn: 355990
|
|
|
|
|
|
|
|
|
| |
This patch adds an XCOFF triple object format type into LLVM.
This XCOFF triple object file type will be used later by object file and assembly generation for the AIX platform.
Differential Revision: https://reviews.llvm.org/D58930
llvm-svn: 355989
|
|
|
|
| |
llvm-svn: 355986
|
|
|
|
| |
llvm-svn: 355985
|
|
|
|
|
|
|
|
|
|
|
| |
LLVM doesn't produce DWARF64, and neither does GCC. LLDB's support
for DWARF64 is only partial, and if enabled appears to also not work.
Finally, it's untested. Removing this makes merging LLVM and
LLDB's DWARF parsing implementations simpler.
Differential Revision: https://reviews.llvm.org/D59235
llvm-svn: 355975
|
|
|
|
|
|
|
|
|
|
| |
This is a very thin wrapper over a std::vector<DWARFDIE> and does
not seem to provide any real value over just using a container
directly.
Differential Revision: https://reviews.llvm.org/D59165
llvm-svn: 355974
|
|
|
|
|
|
|
|
|
|
| |
This is not used outside of the private implementation of the class,
so hiding in the implementation file is a nice way of simplifying
the external interface.
Differential Revision: https://reviews.llvm.org/D59164
llvm-svn: 355973
|
|
|
|
| |
llvm-svn: 355969
|
|
|
|
|
|
| |
Except that it will probably stop failing on and off on my machine.
llvm-svn: 355968
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: labath, jdevlieghere
Subscribers: lldb-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D59159
llvm-svn: 355967
|
|
|
|
|
|
| |
Fixes warning: comparison of integers of different signs.
llvm-svn: 355963
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
darwin kernel debug session.
Originally, the kext name & uuid were emitted in the middle of the
kext-loading period's. Last week I decided to try not printing
any details about kexts that failed to load, only printing a summary
of how many failed to load.
This time I'm print different progress characters depending on whether
the kext loaded or not ("-" for not), then at the end I will print a
summary of how many kexts failed to load and a sorted list of the
kexts with the bundle ID and the uuid. It's a lot more readable.
<rdar://problem/48654569>
llvm-svn: 355958
|
|
|
|
|
|
|
|
|
|
|
| |
There's a single report of a crash coming from this current_sp being NULL. I don't
have a repro case, and I couldn't get it to happen by hand-corrupting a list. We
always get an error instead. So I don't have a test case. But checking for null
is clearly right here.
<rdar://problem/48503320>
llvm-svn: 355957
|
|
|
|
| |
llvm-svn: 355956
|
|
|
|
| |
llvm-svn: 355951
|
|
|
|
|
|
|
|
|
|
|
|
| |
ICF can cause multiple symbols to start at the same virtual address.
I plan to handle this shortly, but I wanted to correct the comment for
now.
Deleted an obsolete comment about adjusting the offset for the magic
number at the beginning of the debug info stream. This adjustment is
handled at a lower level now.
llvm-svn: 355943
|
|
|
|
|
|
|
|
| |
Yesterday I noticed a reproducer test failing after making a local
change. Removing the reproducer directory solved the issue. Add a test
case that detects this.
llvm-svn: 355941
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The command interpreter holds a pointer to a DataRecorder. After
generating the reproducer, we deallocated all the DataRecorders, causing
the command interpreter to hold a non-null reference to an invalid
object.
This patch changes the behavior of the command provider to stop the
DataRecorders when a reproducer is generated, rather than deallocating
them.
llvm-svn: 355940
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This patch is the MVP version of importing the std module into the expression parser to improve C++ debugging.
What happens in this patch is that we inject a `@import std` into our expression source code. We also
modify our internal Clang instance for parsing this expression to work with modules and debug info
at the same time (which is the main change in terms of LOC). We implicitly build the `std` module on the first use. The
C++ include paths for building are extracted from the debug info, which means that this currently only
works if the program is compiled with `-glldb -fmodules` and uses the std module. The C include paths
are currently specified by LLDB.
I enabled the tests currently only for libc++ and Linux because I could test this locally. I'll enable the tests
for other platforms once this has landed and doesn't break any bots (and I implemented the platform-specific
C include paths for them).
With this patch we can now:
* Build a libc++ as a module and import it into the expression parser.
* Read from the module while also referencing declarations from the debug info. E.g. `std::abs(local_variable)`.
What doesn't work (yet):
* Merging debug info and C++ module declarations. E.g. `std::vector<CustomClass>` doesn't work.
* Pretty much anything that involves the ASTImporter and templated code. As the ASTImporter is used for saving the result declaration, this means that we can't
call yet any function that returns a non-trivial type.
* Use libstdc++ for this, as it requires multiple include paths and Clang only emits one include path per module. Also libstdc++ doesn't support Clang modules without patches.
Reviewers: aprantl, jingham, shafik, friss, davide, serge-sans-paille
Reviewed By: aprantl
Subscribers: labath, mgorny, abidh, jdoerfert, lldb-commits
Tags: #c_modules_in_lldb, #lldb
Differential Revision: https://reviews.llvm.org/D58125
llvm-svn: 355939
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Tablegen doesn't support options that are both flags and take values as
an argument. I noticed this when doing the tablegen rewrite, but forgot
that that affected the reproducer --capture flag.
This patch makes --capture a flag and adds --capture-path to specify a
path for the reproducer. In reality I expect this to be mostly used for
testing, but it could be useful nonetheless.
Differential revision: https://reviews.llvm.org/D59238
llvm-svn: 355936
|
|
|
|
|
|
|
|
|
| |
docs (experimental)"
This reverts commit 511066858d44101703d61eded9abf8caff0f9fe0.
This turned out unnecessary to fix the bot.
llvm-svn: 355931
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This patch marks the inline namespaces from DWARF as inline and also ensures that looking
up declarations now follows the lookup rules for inline namespaces.
Reviewers: aprantl, shafik, serge-sans-paille
Reviewed By: aprantl
Subscribers: eraman, jdoerfert, lldb-commits
Tags: #c_modules_in_lldb, #lldb
Differential Revision: https://reviews.llvm.org/D59198
llvm-svn: 355897
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(experimental)
Proposal to fix bot
http://lab.llvm.org:8011/builders/lldb-sphinx-docs/builds/1564/steps/cmake-configure/logs/stdio
Patch by: Stefan Gränitz
Differential revision: https://reviews.llvm.org/D59232
llvm-svn: 355887
|
|
|
|
|
|
|
|
|
|
| |
Summary: see above
Reviewers: compnerd
Differential Revision: https://reviews.llvm.org/D59230
llvm-svn: 355883
|
|
|
|
|
|
|
|
| |
The RECORD macro is context sensitive because it depends on the
LLDB_GET_INSTRUMENTATION_DATA. This updates the modulemap to mark that
header as textual.
llvm-svn: 355879
|
|
|
|
| |
llvm-svn: 355875
|
|
|
|
|
|
|
|
| |
Apparently the log_append variant added in r355863 is considered
ambiguous. At this point I'm out of ideas so a good old reinterpret cast
will have to do. If anybody has a better idea I'd be happy to hear it.
llvm-svn: 355866
|
|
|
|
|
|
|
|
|
|
| |
Changing the type in the DUMMY macro to void* doesn't actually fix the
build error, because the argument type is deducted from the template (as
opposed to when serializing through the instrumentation framework, where
this would matter). Instead I've added a proper instance of log_append
that takes function pointers and logs their address.
llvm-svn: 355863
|
|
|
|
|
| |
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
llvm-svn: 355861
|
|
|
|
|
|
|
|
| |
There was a crash that would happen if an IDE would ask for a child of a shared pointer via any SB API call that ends up calling StackFrame::GetValueForVariableExpressionPath(). The previous code expects an error to be set describing why the synthetic child of a type was not able to be found, but we have some synthetic child providers that weren't setting the error and returning an empty value object shared pointer. This fixes that to ensure we don't lose our debug session by crashing, fully tests GetValueForVariableExpressionPath functionality, and ensures we don't crash on GetValueForVariableExpressionPath() in the future.
Differential Revision: https://reviews.llvm.org/D59200
llvm-svn: 355850
|
|
|
|
| |
llvm-svn: 355843
|
|
|
|
|
|
|
|
| |
Callbacks in the LLDB_RECORD_DUMMY macros were causing build failures
with the Xcode project. This patch replaces the function pointers with
void pointers so they can be logged.
llvm-svn: 355842
|
|
|
|
|
|
| |
This changes '@' prefix to '\'.
llvm-svn: 355841
|
|
|
|
| |
llvm-svn: 355838
|