| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Move scripts/Python/interface to scripts/interface so that we
can start making iterative improvements towards sharing the
interface files between multiple languages (each of which would
have their own directory as now).
Test Plan: Build and see.
Reviewers: zturner, emaste, clayborg
Reviewed By: clayborg
Subscribers: mjsabby, lldb-commits
Differential Revision: http://reviews.llvm.org/D9212
llvm-svn: 235676
|
|
|
|
|
|
| |
directly. http://reviews.llvm.org/D9033
llvm-svn: 235633
|
|
|
|
|
|
| |
stores in a more Pythonic fashion
llvm-svn: 235447
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
# Turn off interpreter.prompt-on-quit on startup (MI)
# Add CommandInterpreter::SetPromptOnQuit
# Add SBCommandInterpreter::GetPromptOnQuit/SetPromptOnQuit
All tests pass on OS X.
Test Plan:
```
-file-exec-and-symbols ~/p/hello
-break-insert -f main
-exec-run
-interpreter-exec console quit
```
Reviewers: abidh, clayborg
Reviewed By: abidh, clayborg
Subscribers: lldb-commits, clayborg, abidh
Differential Revision: http://reviews.llvm.org/D8444
llvm-svn: 233034
|
|
|
|
|
|
|
|
|
|
|
| |
and r232891
This includes:
# SBCommandInterpreter::EventIsCommandInterpreterEvent
# SBModule::GetSymbolFileSpec/GetObjectFileHeaderAddress
# SBTarget::EventIsTargetEvent/GetTargetFromEvent/GetNumModulesFromEvent/GetModuleAtIndexFromEvent/GetLaunchInfo/SetLaunchInfo
llvm-svn: 233029
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
These functions were added in 2013, but not added to the SWIG
bindings.
Reviewers: ki.stfu, clayborg
Reviewed By: ki.stfu, clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D7909
llvm-svn: 230646
|
|
|
|
|
|
| |
This should not bring any feature change, except changing names of things here and there
llvm-svn: 230077
|
|
|
|
|
|
|
|
|
|
|
| |
with yet another bool argument""
Reverting this commit led to other failures which I did not see at
first. This turned out to be an easy problem to fix, so I added
SBVariablesOptions.cpp to the CMakeLists.txt. In the future please
try to make sure new files are added to CMake.
llvm-svn: 229516
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
another bool argument"
This reverts commit r228975. It was causing link errors
on the Windows bots, since last Thursday.
http://lab.llvm.org:8011/builders/lldb-x86-win7-msvc/builds/725
Conflicts:
lldb.xcodeproj/project.pbxproj
llvm-svn: 229514
|
|
|
|
|
|
| |
SBAttachInfo.cpp and SBAttachInfo.i.
llvm-svn: 229346
|
|
|
|
|
|
|
|
|
|
| |
bool argument
We talked about it internally - and came to the conclusion that it's time to have an options class
This commit adds an SBVariablesOptions class and goes through all the required dance
llvm-svn: 228975
|
|
|
|
|
|
|
|
|
|
|
| |
add the version of
SBTarget::BreakpointCreateBySourceRegex that takes file spec lists to the Python interface,
and add a test for this.
<rdar://problem/19805037>
llvm-svn: 228938
|
|
|
|
|
|
|
|
|
|
|
|
| |
A runtime support value is a ValueObject whose only purpose is to support some language runtime's operation, but it does not directly provide any user-visible benefit
As such, unless the user is working on the runtime support, it is mostly safe for them not to see such a value when debugging
It is a language runtime's job to check whether a ValueObject is a support value, and that - in conjunction with a target setting - is used by frame variable and target variable
SBFrame::GetVariables gets a new overload with yet another flag to dictate whether to return those support values to the caller - that which defaults to the setting's value
rdar://problem/15539930
llvm-svn: 228791
|
|
|
|
| |
llvm-svn: 228660
|
|
|
|
|
|
|
|
| |
Integrate this change into test framework in order to spawn processes on a remote target.
http://reviews.llvm.org/D7263
llvm-svn: 228230
|
|
|
|
| |
llvm-svn: 227383
|
|
|
|
|
|
| |
SBValue level; and also make all the implenentations agree on using the matching ValueObject::Create instead of doing code copypastas
llvm-svn: 224460
|
|
|
|
|
|
|
|
|
| |
names can then be used in place of breakpoint id's or breakpoint id
ranges in all the commands that operate on breakpoints.
<rdar://problem/10103959>
llvm-svn: 224392
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
a flattened view of registers
Our actual view of registers is a set of register sets, each one of which contains a subset of the actual registers
This makes trivial scripting operations tedious ("I just want to read r7!")
This helper allows things like: print lldb.frame.reg["r7"]
Fixes rdar://19185662
llvm-svn: 224275
|
|
|
|
|
|
|
|
|
|
|
|
| |
Such a persisted version is equivalent to evaluating the value via the expression evaluator, and holding on to the $n result of the expression, except this API can be used on SBValues that do not obviously come from an expression (e.g. are the result of a memory lookup)
Expose this via SBValue::Persist() in our public API layer, and ValueObject::Persist() in the lldb_private layer
Includes testcase
Fixes rdar://19136664
llvm-svn: 223711
|
|
|
|
|
|
|
| |
SBLineEntry and SBDeclaration. Patch from Chris Willmore.
<rdar://problem/19054323>
llvm-svn: 222592
|
|
|
|
|
|
| |
not the *only* one. Rename it to reflect that
llvm-svn: 222582
|
|
|
|
|
|
| |
in the list
llvm-svn: 222576
|
|
|
|
|
|
| |
options, we don't end up caching the summary hence obtained. You may want to obtain an uncapped summary, but this should not be reflected in the summary we cache. The drawback is that we don't cache as aggressively as we could, but at least you get to have different summaries with different options without having to reset formatters or the SBValue at each step
llvm-svn: 222280
|
|
|
|
|
|
|
|
|
| |
SBTarget::GetInstructions APIs so it's a little clearer to
understand which should be used.
<rdar://problem/18787018>
llvm-svn: 222225
|
|
|
|
|
|
| |
that the function/compile unit is defined in
llvm-svn: 222189
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixed include:
- Change Platform::ResolveExecutable(...) to take a ModuleSpec instead of a FileSpec + ArchSpec to help resolve executables correctly when we have just a path + UUID (no arch).
- Add the ability to set the listener in SBLaunchInfo and SBAttachInfo in case you don't want to use the debugger as the default listener.
- Modified all places that use the SBLaunchInfo/SBAttachInfo and the internal ProcessLaunchInfo/ProcessAttachInfo to not take a listener as a parameter since it is in the launch/attach info now
- Load a module's sections by default when removing a module from a target. Since we create JIT modules for expressions and helper functions, we could end up with stale data in the section load list if a module was removed from the target as the section load list would still have entries for the unloaded module. Target now has the following functions to help unload all sections a single or multiple modules:
size_t
Target::UnloadModuleSections (const ModuleList &module_list);
size_t
Target::UnloadModuleSections (const lldb::ModuleSP &module_sp);
llvm-svn: 222167
|
|
|
|
|
|
| |
properties to SBTarget. Fixes rdar://18963842
llvm-svn: 221850
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
down to individual summary formatters to alter their behavior in a formatter-dependent way
Two flags are introduced:
- preferred display language (as in, ObjC vs. C++)
- summary capping (as in, should a limit be put to the amount of data retrieved)
The meaning - if any - of these options is for individual formatters to establish
The topic of a subsequent commit will be to actually wire these through to individual data formatters
llvm-svn: 221482
|
|
|
|
|
|
| |
rdar://12675166
llvm-svn: 220824
|
|
|
|
|
|
|
|
|
|
|
|
| |
New functions to give client applications to tools to discover target byte sizes
for addresses prior to ReadMemory. Also added GetPlatform and ReadMemory to the
SBTarget class, since they seemed to be useful utilities to have.
Each new API has had a test case added.
http://reviews.llvm.org/D5867
llvm-svn: 220372
|
|
|
|
|
|
| |
more informational content to consumers of the LLDB API than the existing TypeClass. Part of the fix for rdar://18517593
llvm-svn: 220322
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
quit the debugger
after all the commands have been executed except if one of the commands was an execution control
command that stopped because of a signal or exception.
Also adds a variant of SBCommandInterpreter::HandleCommand that takes an SBExecutionContext. That
way you can run an lldb command targeted at a particular target, thread or process w/o having to
select same before running the command.
Also exposes CommandInterpreter::HandleCommandsFromFile to the SBCommandInterpreter API, since that
seemed generally useful.
llvm-svn: 219654
|
|
|
|
|
|
|
|
|
|
| |
Reviewed at http://reviews.llvm.org/D5738
This adds an SB API into SBProcess:
bool SBProcess::IsInstrumentationRuntimePresent(InstrumentationRuntimeType type);
which simply tells whether a particular InstrumentationRuntime (read "ASan") plugin is present and active.
llvm-svn: 219560
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
do that (RunCommandInterpreter, HandleCommands, HandleCommandsFromFile) to gather
the options into an options class. Also expose that to the SB API's.
Change the way the "-o" options to the lldb driver are processed so:
1) They are run synchronously - didn't really make any sense to run the asynchronously.
2) The stop on error
3) "quit" in one of the -o commands will not quit lldb - not the command interpreter
that was running the -o commands.
I added an entry to the run options to stop-on-crash, but I haven't implemented that yet.
llvm-svn: 219553
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
report data extraction
Reviewed at http://reviews.llvm.org/D5592
This patch gives LLDB some ability to interact with AddressSanitizer runtime library, on top of what we already have (historical memory stack traces provided by ASan). Namely, that's the ability to stop on an error caught by ASan, and access the report information that are associated with it. The report information is also exposed into SB API.
More precisely this patch...
adds a new plugin type, InstrumentationRuntime, which should serve as a generic superclass for other instrumentation runtime libraries, these plugins get notified when modules are loaded, so they get a chance to "activate" when a specific dynamic library is loaded
an instance of this plugin type, AddressSanitizerRuntime, which activates itself when it sees the ASan dynamic library or founds ASan statically linked in the executable
adds a collection of these plugins into the Process class
AddressSanitizerRuntime sets an internal breakpoint on __asan::AsanDie(), and when this breakpoint gets hit, it retrieves the report information from ASan
this breakpoint is then exposed as a new StopReason, eStopReasonInstrumentation, with a new StopInfo subclass, InstrumentationRuntimeStopInfo
the StopInfo superclass is extended with a m_extended_info field (it's a StructuredData::ObjectSP), that can hold arbitrary JSON-like data, which is the way the new plugin provides the report data
the "thread info" command now accepts a "-s" flag that prints out the JSON data of a stop reason (same way the "-j" flag works now)
SBThread has a new API, GetStopReasonExtendedInfoAsJSON, which dumps the JSON string into a SBStream
adds a test case for all of this
I plan to also get rid of the original ASan plugin (memory history stack traces) and use an instance of AddressSanitizerRuntime for that purpose.
Kuba
llvm-svn: 219546
|
|
|
|
|
|
| |
class is a convenient way at the API level to package a target,process,thread and frame all together - or just a subset of those
llvm-svn: 218808
|
|
|
|
|
|
|
|
|
|
|
|
| |
more accessible from
the user level. It adds the ability to invent new stepping modes implemented by python classes,
and to view the current thread plan stack and to some extent alter it.
I haven't gotten to documentation or tests yet. But this should not cause any behavior changes
if you don't use it, so its safe to check it in now and work on it incrementally.
llvm-svn: 218642
|
|
|
|
|
|
| |
definition
llvm-svn: 218147
|
|
|
|
|
|
| |
FindGlobalFunctions that lets you search by name, by regular expression and by starts with.
llvm-svn: 218140
|
|
|
|
|
|
|
|
|
| |
well as C++
For the Objective-C case, we do not have a "function type" notion, so we actually end up wrapping the clang ObjCMethodDecl in the Impl object, and ask function-y questions of it
In general, you can always ask for return type, number of arguments, and type of each argument using the TypeMemberFunction layer - but in the C++ case, you can also acquire a Type object for the function itself, which instead you can't do in the Objective-C case
llvm-svn: 218132
|
|
|
|
|
|
| |
member function in more detail. A type was really quite vague. This now has function name, kind, as well as function type
llvm-svn: 217828
|
|
|
|
|
|
| |
classes. Add plumbing for that all the way up to the SB layer
llvm-svn: 217701
|
|
|
|
|
|
|
|
|
| |
Reviewed at
http://reviews.llvm.org/D5219
and
http://lists.cs.uiuc.edu/pipermail/lldb-commits/Week-of-Mon-20140901/012809.html
llvm-svn: 217300
|
|
|
|
|
|
| |
API. To keep it simple, do not expose the pair, but just return a NULL string for success, and a non-NULL string for error; If we were to decide to expose the pair, we would need an SBTypeValidatorResult, which is fine, but it should come as part of exposing type validators through the SB API rather than as a one-off thing. So, KISS for now
llvm-svn: 217299
|
|
|
|
|
|
|
|
|
| |
Reviewed at
http://reviews.llvm.org/D5218
and
http://lists.cs.uiuc.edu/pipermail/lldb-commits/Week-of-Mon-20140901/012828.html
llvm-svn: 217296
|
|
|
|
|
|
| |
and so can only be used in the script interpreter.
llvm-svn: 216625
|
|
|
|
|
|
|
|
| |
* transfered => transferred
* unkown => unknown
* sucessfully => successfully
llvm-svn: 215367
|
|
|
|
|
|
|
|
|
|
|
|
| |
EvaluateExpression
from Python. If you don't need to refer to the result in another expression, there's no
need to bloat the persistent variable table with them since you already have the result
SBValue to work with.
<rdar://problem/17963645>
llvm-svn: 215244
|
|
|
|
| |
llvm-svn: 214319
|