| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: These are not needed by lldb-server. Removing them shrinks the server by about 0.5%.
Reviewers: zturner
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D18206
llvm-svn: 264735
|
|
|
|
|
|
|
|
| |
this was needed because lldb-mi temporarily contained references to private lldb symbols
(lldb_private namespace), which it shouldn't have. The situation has since been rectified and
this wasn't the right fix anyway, since it can lead to funny ODR violations.
llvm-svn: 264733
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Since r264316, clang started adding DW_AT_GNU_dwo_name attribute to dwo files (previously, this
attribute was only present in main object files), breaking pretty much every dwo test. The
problem was that we were treating the presence of said attribute as a signal that we should look
for information in an external object file, and caused us to enter an infinite loop. I fix this
by making sure we do not go looking for an external dwo file if we already *are* parsing a dwo
file.
Reviewers: tberghammer, clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D18547
llvm-svn: 264729
|
|
|
|
| |
llvm-svn: 264721
|
|
|
|
| |
llvm-svn: 264713
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This allows these functions to be re-used by a forthcoming
PDBASTParser. The functions in question are CanCompleteType,
CompleteType, and CanImport. Conceptually, these functions belong
on ClangASTImporter anyway, and previously they were just ping
ponging around through a few levels of indirection to end up there
as well, so this patch actually makes the code somewhat simpler.
A few methods were moved to a new file called ClangUtil, so that
they can be shared between ClangASTImporter and ClangASTContext
without creating a circular dependency between those two cpp
files.
Differential Revision: http://reviews.llvm.org/D18381
llvm-svn: 264685
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Top-level Clang expressions are expressions that act as new translation units,
and define their own symbols. They do not have function wrappers like regular
expressions do, and declarations are persistent regardless of use of the dollar
sign in identifiers. Names defined by these are given priority over all other
symbol lookups.
This patch adds a new expression option, '-p' or '--top-level,' which controls
whether the expression is treated this way. It also adds a flag controlling
this to SBExpressionOptions so that this API is usable externally. It also adds
a test that validates that this works. (The test requires a fix to the Clang
AST importer which I will be committing shortly.)
<rdar://problem/22864976>
llvm-svn: 264662
|
|
|
|
| |
llvm-svn: 264660
|
|
|
|
| |
llvm-svn: 264659
|
|
|
|
|
|
|
|
|
|
|
| |
The ASTImporter completes the full definiton for a TagDecl in several places,
including the type-deport logic. When this happens, we should also propagate
the bit that says that this is a complete definition. This makes (for example)
lambdas callable.
<rdar://problem/22864976>
llvm-svn: 264485
|
|
|
|
|
|
|
|
|
|
|
| |
Blocks and lambdas have their implementation functions stored in the IR for an
expression. If we put the block/lambda into a result variable it needs to stay
around. As a heuristic, remember any execution unit that has more than one
function in it.
<rdar://problem/22864976>
llvm-svn: 264483
|
|
|
|
| |
llvm-svn: 264478
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This fixes a leak introduced by some of these changes:
r257644
r250530
r250525
The changes made in these patches result in leaking the FILE* passed
to SetImmediateOutputFile. GetStream() will dup() the fd held by the
python caller and create a new FILE*. It will then pass this FILE*
to SetImmediateOutputFile, which always uses the flag
transfer_ownership=false when it creates a File from the FILE*.
Since transfer_ownership is false, the lldb File destructor will not
close the underlying FILE*. Because this FILE* came from a dup-ed fd,
it will also not be closed when the python caller closes its file.
Leaking the FILE* causes issues if the same file is used multiple times
by different python callers during the same lldb run, even if these
callers open and close the python file properly, as you can end up
with issues due to multiple buffered writes to the same file.
Reviewers: granata.enrico, zturner, clayborg
Subscribers: zturner, lldb-commits, sas
Differential Revision: http://reviews.llvm.org/D18459
Change by Francis Ricci <fjricci@fb.com>
llvm-svn: 264476
|
|
|
|
|
|
| |
low-friction reproduction for issues with the LLDB demangling of C++ symbols
llvm-svn: 264474
|
|
|
|
|
|
|
|
| |
track the fact that an alias is an alias to a dash-dash alias
(and I hope I typed the word 'alias' enough times in this commit message :-)
llvm-svn: 264468
|
|
|
|
| |
llvm-svn: 264449
|
|
|
|
|
|
|
|
| |
months back to PlatformRemoteAppleTV and PlatformRemoteAppleWatch
to help understand what's happening when lldb can't find binaries
that it should be finding.
llvm-svn: 264380
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
"." for "->".)
This feature is controlled by an expression command option, a target property and the
SBExpressionOptions setting. FixIt's are only applied to UserExpressions, not UtilityFunctions,
those you have to get right when you make them.
This is just a first stage. At present the fixits are applied silently. The next step
is to tell the user about the applied fixit.
<rdar://problem/25351938>
llvm-svn: 264379
|
|
|
|
| |
llvm-svn: 264361
|
|
|
|
|
|
| |
'type lookup'
llvm-svn: 264356
|
|
|
|
|
|
|
|
| |
so that the lldb command line binary's version #'s are updated
correctly.
<rdar://problem/25346711>
llvm-svn: 264353
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Fixes SBCommandReturnObject::SetImmediateOutputFile() and
SBCommandReturnObject::SetImmediateOutputFile() for files opened
with "a" or "a+" by resolving inconsistencies between File and
our Python parsing of file objects.
Reviewers: granata.enrico, Eugene.Zelenko, jingham, clayborg
Subscribers: lldb-commits, sas
Differential Revision: http://reviews.llvm.org/D18228
Change by Francis Ricci <fjricci@fb.com>
llvm-svn: 264351
|
|
|
|
|
|
| |
the global destructor chain has been run on the main thread.
llvm-svn: 264348
|
|
|
|
|
|
| |
only function that uses these variables.
llvm-svn: 264347
|
|
|
|
|
|
| |
make the Timer safe to use after the main threads global destructor chain is called.
llvm-svn: 264346
|
|
|
|
|
|
|
|
| |
when it can't find a type matching user input
It would be fun to make it provide suggestions (e.g. 'can't find NString, did you mean NSString instead?'), but this worries me a little bit on the account of just how thorough of a type system scan it would have to do
llvm-svn: 264343
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: On Windows (and possibly other hosts with LLDB_DISABLE_LIBEDIT defined), the (lldb) prompt won't print after async output, like from a breakpoint hit or a step. This patch forces the prompt to be printed out after async output.
Reviewers: zturner, clayborg
Subscribers: amccarth, lldb-commits
Differential Revision: http://reviews.llvm.org/D18335
llvm-svn: 264332
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Though r264012 was fancy enough to make reading the jit entry struct
work with templates, the packing and alignment attributes do not work on
Windows. So, this change makes it plain and simple with manual reading
of the jit entry struct.
Reviewers: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D18379
llvm-svn: 264217
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: zturner, clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D17970
llvm-svn: 264173
|
|
|
|
| |
llvm-svn: 264168
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch adds ThreadSanitizer support into LLDB:
- Adding a new InstrumentationRuntime plugin, ThreadSanitizerRuntime, in the same way ASan is implemented.
- A breakpoint stops in `__tsan_on_report`, then we extract all sorts of information by evaluating an expression. We then populate this into StopReasonExtendedInfo.
- SBThread gets a new API, SBThread::GetStopReasonExtendedBacktraces(), which returns TSan’s backtraces in the form of regular SBThreads. Non-TSan stop reasons return an empty collection.
- Added some test cases.
Reviewed by Greg Clayton.
llvm-svn: 264162
|
|
|
|
|
|
|
|
|
|
| |
strings for commands
This solves issues such as 'apropos foo' returning valid matches just because syntax examples happen to use 'foo' as a placeholder token
Fixes rdar://9043025
llvm-svn: 264123
|
|
|
|
|
|
|
|
| |
FileSystem::Fopen is a lldb_private API, but lldb-mi uses only the
public API. Depending on lldb_private APIs makes Xcode builds fail.
I reverted the portion of r264074 that added such a dependency.
llvm-svn: 264113
|
|
|
|
|
|
| |
its parent command by setting itself to an empty help string
llvm-svn: 264108
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: zturner
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D18377
llvm-svn: 264104
|
|
|
|
|
|
| |
terms of another alias, trying to run the nested command would actually cause a crash in the command interpreter
llvm-svn: 264096
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch adds a new ExecutionPolicy, eExecutionPolicyTopLevel, which
tells the expression parser that the expression should be JITted as top
level code but nothing (except static initializers) should be run. I
have modified the Clang expression parser to recognize this execution
policy. On top of the existing patches that support storing IR and
maintaining a map of arbitrary Decls, this is mainly just patching up a
few places in the expression parser.
I intend to submit a patch for review that exposes this functionality
through the "expression" command and through the SB API. That patch
also includes a testcase for all of this.
<rdar://problem/22864976>
llvm-svn: 264095
|
|
|
|
|
|
| |
llvm/Support/ConvertUTF.h was brought into the driver
llvm-svn: 264087
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Win32 API calls that are Unicode aware require wide character
strings, but LLDB uses UTF8 everywhere. This patch does conversions
wherever necessary when passing strings into and out of Win32 API
calls.
Patch by Cameron
Differential Revision: http://reviews.llvm.org/D17107
Reviewed By: zturner, amccarth
llvm-svn: 264074
|
|
|
|
|
|
|
|
|
|
| |
Patch by Nitesh Jain
Reviewers: clayborg, labath.
Subscribers: jaydeep, bhushan, mohit.bhakkad, sagar, lldb-commits.
Differential Revision: http://reviews.llvm.org/D18082
llvm-svn: 264030
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: clayborg
Subscribers: tberghammer, dsrbecky, lldb-commits
Differential Revision: http://reviews.llvm.org/D18334
llvm-svn: 264012
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
| |
functions) so I added
a way for compilation to take a "thread to use for compilation". If it isn't set then the
compilation will use the currently selected thread. This should help keep function execution
to the one thread intended.
llvm-svn: 263972
|
|
|
|
| |
llvm-svn: 263899
|
|
|
|
| |
llvm-svn: 263865
|
|
|
|
|
|
|
|
|
|
| |
Persistent decls have traditionally only been types. However, we want to
be able to persist more things, like functions and global variables. This
changes some of the nomenclature and the lookup rules to make this possible.
<rdar://problem/22864976>
llvm-svn: 263864
|
|
|
|
| |
llvm-svn: 263861
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We want to do a better job presenting errors that occur when evaluating
expressions. Key to this effort is getting away from a model where all
errors are spat out onto a stream where the client has to take or leave
all of them.
To this end, this patch adds a new class, DiagnosticManager, which
contains errors produced by the compiler or by LLDB as an expression
is created. The DiagnosticManager can dump itself to a log as well as
to a string. Clients will (in the future) be able to filter out the
errors they're interested in by ID or present subsets of these errors
to the user.
This patch is not intended to change the *users* of errors - only to
thread DiagnosticManagers to all the places where streams are used. I
also attempt to standardize our use of errors a bit, removing trailing
newlines and making clients omit 'error:', 'warning:' etc. and instead
pass the Severity flag.
The patch is testsuite-neutral, with modifications to one part of the
MI tests because it relied on "error: error:" being erroneously
printed. This patch fixes the MI variable handling and the testcase.
<rdar://problem/22864976>
llvm-svn: 263859
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The Windows SDK provides a version of signal() that is much more
limited compared to other platforms. It only supports about 5-6
signal values. LLDB uses signals for a number of things, most
notably to handle Ctrl+C so we can gracefully shut down. The
portability solution to this on Windows has been to provide a
hand-rolled implementation of `signal` using the name `signal`
so that you could write code that simply calls signal directly
and it would work.
But this introduces a multiply defined symbol with the builtin
version and depending on how you included header files, you could
get yourself into a situation where you had linker errors. To
make matters worse, it led to a ton of compiler warnings. Worst
of all though is that this custom implementation of signal was,
in fact, identical for the purposes of handling Ctrl+C as the
builtin implementation of signal. So it seems to have literally
not been serving any useful purpose.
This patch deletes all the custom signal() functions for Windows,
and includes the signal.h system header, so that any calls to
signal now go to the actual version provided by the Windows SDK.
Differential Revision: http://reviews.llvm.org/D18287
llvm-svn: 263858
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We are using hardlinks instead of symlinks, and we attempted to
have some logic where we don't re-create the link if the target
file already exists. This logic is faulty, however, when you
manually delete the source file (e.g. liblldb.dll) and then rebuild
lldb so that a brand new liblldb.dll gets written. Now the two files
have different inodes, but the target exists, so we would not remake
the link and the target would become stale.
We fix this by only doing the optimization if they are really the
exact same file (by comparing inode numbers), and if they are not
the same file but the target exists, we delete it and re-create
the link.
llvm-svn: 263844
|