Previously using HostThread::GetNativeThread() required an ugly
cast to most-derived type. This solves the issue by simply returning
the derived type directly.
llvm-svn: 222185
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
Improvements include:
* Use of libedit's wide character support, which is imperfect but a distinct improvement over ASCII-only
* Fallback for ASCII editing path
* Support for a "faint" prompt clearly distinguished from input
* Breaking lines and insert new lines in the middle of a batch by simply pressing return
* Joining lines with forward and backward character deletion
* Detection of paste to suppress automatic formatting and statement completion tests
* Correctly reformatting when lines grow or shrink to occupy different numbers of rows
* Saving multi-line history, and correctly preserving the "tip" of history during editing
* Displaying visible ^C and ^D indications when interrupting input or sending EOF
* Fledgling VI support for multi-line editing
* General correctness and reliability improvements
llvm-svn: 222163
This creates a TargetThreadWindows class and updates the thread
list of the Process with the main thread. Additionally, we
fill out a few more overrides of Process base class methods. We
do not yet update the thread list as threads are created and/or
destroyed, and we do not yet propagate stop reasons to threads as
their states change.
llvm-svn: 222148
relative paths, like:
/whatever/llvm/lib/Sema/../../include/llvm/Sema/
That causes problems with our type uniquing, since we use the declaration file
and line as one component of the uniquing, and different ways of getting to the
same file will have different directory spellings, though they are functionally
equivalent. We end up with two copies of the exact same type because of this,
and that makes the expression parser give "duplicate type" errors.
I added a method to resolve paths with ../ in them and used that in the FileSpec::Equals,
for comparing Declarations and for doing Breakpoint compares as well, since they also
suffer from this if you specify breakpoints by full path (since nobody knows what
../'s to insert...)
<rdar://problem/18765814>
llvm-svn: 222075
RegisterContextLLDB. I have core files of half a dozen tricky
unwind situations on x86/arm and they're all working pretty much
correctly at this point, but we'll need to keep an eye out for
unwinder regressions for a little while; it's tricky to get these
heuristics completely correct in all unwind situations.
<rdar://problem/18937193>
llvm-svn: 221866
Summary:
PowerPC handles the stack chain with the current stack pointer being a pointer
to the backchain (CFA). LLDB currently has no way of handling this, so this
adds a "CFA is dereferenced from a register" type.
Discussed with Jason Molenda, who also provided the initial patch for this.
Reviewers: jasonmolenda
Reviewed By: jasonmolenda
Subscribers: emaste, lldb-commits
Differential Revision: http://reviews.llvm.org/D6182
llvm-svn: 221788
out we only want to roll back text that was in the
buffer to begin with, so it's not necessary to
provide a pushback stack.
I'm going to use this slightly cleaner API to perform
lookahead for the Objective-C runtime type parser.
llvm-svn: 221640
MSVC warns that not all control paths return a value when a switch
doesn't have a default case handler. Changed explicit value checks
to a default check.
Also, it caught a case where bitwise AND was being used instead of
logical AND. I'm not sure what this fixes, but presumably it is
not covered by any kind of test case.
llvm-svn: 221636
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
This was done by using regular expressions on any basename we find to ensure it is valid.
This fixed setting breakpoints by name with values like '[J]com.robovm.debug.server.apps.SleepLoop.startingUp()V'. This was previously triggering the C++ method name class to identify the string as C++ with a basename of '[J]com.robovm.debug.server.apps.SleepLoop.startingUp' which was obviously incorrect.
The changes also fixed errors in templated function names like "void foo<int>(...)" where "void foo<int>" was being identified incorrectly as the basename. We also handle more C++ operators correctly now.
llvm-svn: 221416
In the llgs world, ProcessWindows will eventually go away and
we'll implement a different protocol. This patch decouples
ProcessWindows from the core debug loop so that this transition
will not be more difficult than it needs to be.
llvm-svn: 221405
The recent StringPrinter changes made this behavior the default, and the setting defaults to yes
If you want to change this behavior and see non-printables unescaped (e.g. "a\tb" as "a b"), set it to false
Fixes rdar://12969594
llvm-svn: 221399
let's let lldb try the arch default unwind every time but not destructively --
it doesn't permanently replace the main unwind method for that function from
now on.
This fix is for <rdar://problem/18683658>.
I tested it against Ryan Brown's go program test case and also a
collection of core files of tricky unwind scenarios
<rdar://problem/15664282> <rdar://problem/15835846>
<rdar://problem/15982682> <rdar://problem/16099440>
<rdar://problem/17364005> <rdar://problem/18556719>
that I've fixed over the last 6-9 months.
llvm-svn: 221238
When processes are launched for debugging on Windows now, LLDB
will detect changes such as DLL loads and unloads, breakpoints,
thread creation and deletion, etc.
These notifications are not yet propagated to LLDB in a way that
LLDB understands what is happening with the process. This only
picks up the notifications from the OS in a way that they can be
sent to LLDB with subsequent patches.
Reviewed by: Scott Graham
Differential Revision: http://reviews.llvm.org/D6037
llvm-svn: 221207
to indicate that we're doing stuff for the expression
parser.
- When for_expression is true, look through @s and find
the actual class rather than just returning id.
- Rename BuildObjCObjectType to BuildObjCObjectPointerType
since it's actually returning an object *pointer* type.
llvm-svn: 220979
This works similarly to the {thread/frame/process/target.script:...} feature - you write a summary string, part of which is
${var.script:someFuncName}
someFuncName is expected to be declared as
def someFuncName(SBValue,otherArgument) - essentially the same as a summary function
Since . -> [] are the only allowed separators, and % is used for custom formatting, .script: would not be a legitimate symbol anyway, which makes this non-ambiguous
llvm-svn: 220821
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
BreakpointLocation::ShouldStop. That worked but wasn't really right,
since there's nothing to guarantee that won't get called more than
once. So this change moves that responsibility to the StopInfoBreakpoint
directly, and then it uses the BreakpointSite to actually do the bumping.
Also fix a test case that was assuming if you had many threads running some
code with a breakpoint in it, the hit count when you stopped would always be
1. Many of the threads could have hit it at the same time...
<rdar://problem/18577603>
llvm-svn: 220358
There were many issues with synchronous mode that we discovered when started to try and add a "batch" mode. There was a race condition where the event handling thread might consume events when in sync mode and other times the Process::WaitForProcessToStop() would consume them. This also led to places where the Process IO handler might or might not get popped when it needed to be.
llvm-svn: 220254
This implements Host::LaunchProcess for windows, and in doing so
does some minor refactor to move towards a more modular process
launching design.
The original motivation for this is that launching processes on
windows needs some very windows specific code, which would live
most appropriately in source/Host/windows somewhere. However,
there is already some common code that all platforms use when
launching a process before delegating to the platform specific
stuff, which lives in source/Host/common/Host.cpp which would
be nice to reuse without duplicating.
This commonality has been abstracted into MonitoringProcessLauncher,
a class which abstracts out the notion of launching a process using
an arbitrary algorithm, and then monitoring it for state changes.
The windows specific launching code lives in ProcessLauncherWindows,
and the posix specific launching code lives in ProcessLauncherPosix.
When launching a process MonitoringProcessLauncher is created, and
then an appropriate delegate launcher is created and given to the
MonitoringProcessLauncher.
Reviewed by: Greg Clayton
Differential Revision: http://reviews.llvm.org/D5781
llvm-svn: 219731
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
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
Enrico Granata