| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 355830
|
|
|
|
|
|
|
| |
Adding parens should be enough to fix the "'operator bool': is
ambiguous or is not a member of 'lldb::SBFoo'" errors.
llvm-svn: 355827
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Our python version of the SB API has (the python equivalent of)
operator bool, but the C++ version doesn't.
This is because our python operators are added by modify-python-lldb.py,
which performs postprocessing on the swig-generated interface files.
In this patch, I add the "operator bool" to all SB classes which have an
IsValid method (which is the same logic used by modify-python-lldb.py).
This way, we make the two interfaces more constent, and it allows us to
rely on swig's automatic syntesis of python __nonzero__ methods instead
of doing manual fixups.
Reviewers: zturner, jingham, clayborg, jfb, serge-sans-paille
Subscribers: jdoerfert, lldb-commits
Differential Revision: https://reviews.llvm.org/D58792
llvm-svn: 355824
|
|
|
|
|
|
|
|
|
|
|
|
| |
the input StringRef is not guaranteed to be null-terminated, so using
data to get the c string is wrong. Luckily, in two of the usages the
target function already accepts a StringRef so we can just drop the
data() call, and the third one is easily replaced by a stringref-aware
function.
Issue found by msan.
llvm-svn: 355817
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Within .lldbinit, regex commands can be structured as a list of substitutions over
multiple lines. It's possible that this is uninentional, but it works and has
benefits.
For example:
command regex <command-name>
s/pat1/repl1/
s/pat2/repl2/
...
I use this form of `command regex` in my `~/.lldbinit`, because it makes it
clearer to write and read compared to a single line definition, because
multiline substitutions don't need to be quoted, and are broken up one per line.
However, multiline definitions result in usage instructions being printed for
each use. The result is that every time I run `lldb`, I get a dozen or more
lines of noise. With this change, the instructions are only printed when
`command regex` is invoked interactively, or from a terminal, neither of which
are true when lldb is sourcing `~/.lldbinit`.
Reviewers: clayborg, jingham
Reviewed By: clayborg
Subscribers: jdoerfert, kastiglione, xiaobai, keith, lldb-commits
Differential Revision: https://reviews.llvm.org/D48752
llvm-svn: 355793
|
|
|
|
|
|
|
|
|
|
| |
Fix 2lwp_process_SIGSEGV NetBSD core test to terminate inside regular
function rather than libc call, in order to get reproducible backtrace
on different platforms.
Differential Revision: https://reviews.llvm.org/D59177
llvm-svn: 355786
|
|
|
|
|
|
|
|
| |
Adjust the XFAIL-ing tests to match consistent results from buildbot.
I'm going to work on differences between them and my local results
following this.
llvm-svn: 355774
|
|
|
|
|
|
|
|
| |
The code commited in r355764 didn't do what I want as I typed GetThreadID
instead of GetQueueID. This commit contains a (hopefully) better version
of the workaround.
llvm-svn: 355766
|
|
|
|
|
|
|
|
| |
This is not a fix, but if I understand enough of the issue, it should
bail out early of the test when in a situation that would result in
a failure down the road.
llvm-svn: 355764
|
|
|
|
|
|
|
|
|
|
| |
Inspired by Zachary's mail on lldb-dev, this seemed like low hanging
fruit. This patch breaks the circular dependency between commands and
expression.
Differential revision: https://reviews.llvm.org/D59158
llvm-svn: 355762
|
|
|
|
|
|
|
|
|
|
|
| |
to do "databuffer + offset" so that we don't overflow the uint64_t's
we're using for addresses when working with high addresses.
Found with clang's ubsan while doing darwin kernel debugging.
<rdar://problem/48728940>
llvm-svn: 355761
|
|
|
|
|
|
|
| |
Apparently the problem is harder than anticipated. Skip the test for
now to fix buildbots.
llvm-svn: 355750
|