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
only execute thumb instructions, force the arch triple string to
be "thumbv..." instead of "armv..." so we do the right thing by
default when disassembling arbitrary chunks of code.
<rdar://problem/15126397>
llvm-svn: 228486
Summary:
This commit adds a new open flag File::eOpenOptionCloseOnExec (i.e., O_CLOEXEC), and adds it to
the list of flags when opening log files (#ifndef windows). A regression test is included.
Reviewers: vharron, clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D7412
llvm-svn: 228310
Background: dyld binaries often have extra symbols in their symbol table like "malloc" and "free" for the early bringup of dyld and we often don't want to set breakpoints in dynamic linker binaries. We also don't want to call the "malloc" or "free" function in dyld when a user writes an expression like "(void *)malloc(123)" so we need to avoid doing name lookups in dyld. We mark Modules as being dynamic link editors and this helps do correct lookups for breakpoints by name and function lookups.
<rdar://problem/19716267>
llvm-svn: 228261
Why? Debugger::FormatPrompt() would run through the format prompt every time and parse it and emit it piece by piece. It also did formatting differently depending on which key/value pair it was parsing.
The new code improves on this with the following features:
1 - Allow format strings to be parsed into a FormatEntity::Entry which can contain multiple child FormatEntity::Entry objects. This FormatEntity::Entry is a parsed version of what was previously always done in Debugger::FormatPrompt() so it is more efficient to emit formatted strings using the new parsed FormatEntity::Entry.
2 - Allows errors in format strings to be shown immediately when setting the settings (frame-format, thread-format, disassembly-format
3 - Allows auto completion by implementing a new OptionValueFormatEntity and switching frame-format, thread-format, and disassembly-format settings over to using it.
4 - The FormatEntity::Entry for each of the frame-format, thread-format, disassembly-format settings only replaces the old one if the format parses correctly
5 - Combines all consecutive string values together for efficient output. This means all "${ansi.*}" keys and all desensitized characters like "\n" "\t" "\0721" "\x23" will get combined with their previous strings
6 - ${*.script:} (like "${var.script:mymodule.my_var_function}") have all been switched over to use ${script.*:} "${script.var:mymodule.my_var_function}") to make the format easier to parse as I don't believe anyone was using these format string power user features.
7 - All key values pairs are defined in simple C arrays of entries so it is much easier to add new entries.
These changes pave the way for subsequent modifications where we can modify formats to do more (like control the width of value strings can do more and add more functionality more easily like string formatting to control the width, printf formats and more).
llvm-svn: 228207
This was causing code that opened multiple targets to try and get a path to debugserver from the GDB remote communication class, and it would get the LLDB path and some instances would return empty strings and it would cause debugserver to not be found.
<rdar://problem/18756927>
llvm-svn: 227935
And since enough of these are doing the right thing, add a test case to verify we are doing the right thing with freeze drying ObjC object types
Fixes rdar://18092770
llvm-svn: 227282
This is necessary because the byte size of an ObjC class type is not reliably statically knowable (e.g. because superclasses sit deep in frameworks that we have no debug info for)
The lack of reliable size info is a problem when trying to freeze-dry an ObjC instance (not the pointer, the pointee)
This commit lays the foundation for having language runtimes help in figuring out byte sizes, and having ClangASTType ask for runtime help
No feature change as no runtime actually implements the logic, and nowhere is an ExecutionContext passed in yet
llvm-svn: 227274
Without this overload, attempts to edit the value of a variable with synthetic children enabled would change the value inside the synthetic ValueObject, but not propagate the changes to the underlying storage, hence resulting in no write for any meaningful purpose
Comes with a test case, and fixes rdar://19586311
llvm-svn: 227120
This matches the behavior of the default constructor, so is
technically more correct.
Patch by Chaoren Lin
Differential Revision: http://reviews.llvm.org/D7113
llvm-svn: 226851
When you create a target, it tries to look for the platform's list
of supported architectures for a match. The match it finds can
contain specific triples, like i386-pc-windows-msvc. Later, we
overwrite this value with the most generic triple that can apply
to any platform with COFF support, causing some of the fields of
the triple to get overwritten.
This patch changes the behavior to only merge in values from the COFF
triple if the fields of the matching triple were unknown/unspecified
to begin with.
This fixes load address resolution on Windows, since it enables the
DynamicLoaderWindows to be used instead of DynamicLoaderStatic.
Reviewed by: Greg Clayton
Differential Revision: http://reviews.llvm.org/D7120
llvm-svn: 226849
Since REG_ENHANCED is available on MacOSX, this allow the use of \d (digits) \b (word boundaries) and much more without affecting other systems.
<rdar://problem/12082562>
llvm-svn: 226704
Most of the time, we can use context information just fine to choose a language (i.e. the language of the frame that the root object was defined in, if any); but in some cases, synthetic children may be fabricated as root frame-less entities, and then we wouldn't know any better
This patch allows (internal) synthetic child providers to set a display language on the children they generate, should they so choose
llvm-svn: 226634
This function returns a URI of the resource that the connection is connected to. This is especially important for connections established by accepting a connection from a remote host.
Also added implementations for ConnectionMachPort, ConnectionSharedMemory,
Also fixed up some documentation in Connection::Write
Renamed ConnectionFileDescriptorPosix::SocketListen to ConnectionFileDescriptorPosix::SocketListenAndAccept
Fixed a log message in Socket.cpp
Differential Review: http://reviews.llvm.org/D7026
llvm-svn: 226362
The refactor was motivated by some comments that Greg made
http://reviews.llvm.org/D6918
and also to break a dependency cascade that caused functions linking
in string->int conversion functions to pull in most of lldb
llvm-svn: 226199
moved into the #else branch of the #if/#elif/#endif, so it wasn't getting done in the #if case anymore.
Keep the code to add the demangled name outside of the #if, and then just free the demangled_name
and set it back to NULL in the Windows case.
<rdar://problem/19479499>
llvm-svn: 226088
This is done by adding a "Variable *" to SymbolContext and allowing SymbolFile::ResolveSymbolContext() so if an address is resolved into a symbol context, we can include the global or static variable for that address.
This means you can now find global variables that are merged globals when doing a "image lookup --verbose --address 0x1230000". Previously we would resolve a symbol and show "_MergedGlobals123 + 1234". But now we can show the global variable name.
The eSymbolContextEverything purposely does not include the new eSymbolContextVariable in its lookup since stack frame code does many lookups and we don't want it triggering the global variable lookups.
<rdar://problem/18945678>
llvm-svn: 226084
The default help display now shows the alias collection by default, and hides commands whose named begin with an underscore. Help is primarily useful to those unfamiliar with LLDB and should aim to answer typical questions while still being able to provide more esoteric answers when required. To that latter end an argument to include the hidden commands in help has been added, and instead of having a help flag to show aliases there is now one to hide them. This final change might be controversial as it repurposes the -a shorthand as the opposite of its original meaning.
The previous implementation of OutputFormattedHelpText was easily confused by embedded newlines. The new algorithm correctly breaks on the FIRST newline or LAST space/tab before the target column count rather than treating all whitespace interchangeably.
Command interpreters now have the ability to specify help prologue text and a command prefix string. Neither are used in the current LLDB sources but are required to support REPL-like extensions where LLDB commands must be prefixed and additional help text is required to explain how to access traditional debugging commands.
<rdar://problem/17751929>
<rdar://problem/16953815>
<rdar://problem/16953841>
<rdar://problem/16930173>
<rdar://problem/16879028>
llvm-svn: 226068
I have been seeing a few crashes where LLDB tries to acquire a cached synthetic child by index, and crashes in the ClusterManager obtaining a shared_ptr for that ValueObject
That kind of crash most often means that I am holding on to a raw pointer to a ValueObject that was let go from the cluster
The main way that could happen is that the synthetic provider is being updated at the same time that some child is being accessed from the previous provider state
This fixes the problem by making the children be stored in a thread-safe map
Fixes rdar://18627964
llvm-svn: 225538
It also comes with a (rudimentary) test case that gets itself in a failed update scenario, and checks that we don't crash
This is the easiest case I could think of that forces the failed update case Zachary was seeing
llvm-svn: 225463
The issue was we had a global variable that was a pointer, and the address type of the children wasn't "load address" when it needed to be. Full details are in the comments of the changes.
<rdar://problem/15107937>
llvm-svn: 224559
Function pointers had a summary generated for them bypassing formatters, directly as part of the ValueObject subsystem
This patch transitions that code into a hardcoded summary
llvm-svn: 223906
The issue with Thumb IT (if/then) instructions is the IT instruction preceeds up to four instructions that are made conditional. If a breakpoint is placed on one of the conditional instructions, the instruction either needs to match the thumb opcode size (2 or 4 bytes) or a BKPT instruction needs to be used as these are always unconditional (even in a IT instruction). If BKPT instructions are used, then we might end up stopping on an instruction that won't get executed. So if we do stop at a BKPT instruction, we need to continue if the condition is not true.
When using the BKPT isntructions are easy in that you don't need to detect the size of the breakpoint that needs to be used when setting a breakpoint even in a thumb IT instruction. The bad part is you will now always stop at the opcode location and let LLDB determine if it should auto-continue. If the BKPT instruction is used, the BKPT that is used for ARM code should be something that also triggers the BKPT instruction in Thumb in case you set a breakpoint in the middle of code and the code is actually Thumb code. A value of 0xE120BE70 will work since the lower 16 bits being 0xBE70 happens to be a Thumb BKPT instruction.
The alternative is to use trap or illegal instructions that the kernel will translate into breakpoint hits. On Mac this was 0xE7FFDEFE for ARM and 0xDEFE for Thumb. The darwin kernel currently doesn't recognize any 32 bit Thumb instruction as a instruction that will get turned into a breakpoint exception (EXC_BREAKPOINT), so we had to use the BKPT instruction on Mac. The linux kernel recognizes a 16 and a 32 bit instruction as valid thumb breakpoint opcodes. The benefit of using 16 or 32 bit instructions is you don't stop on opcodes in a IT block when the condition doesn't match.
To further complicate things, single stepping on ARM is often implemented by modifying the BCR/BVR registers and setting the processor to stop when the PC is not equal to the current value. This means single stepping is another way the ARM target can stop on instructions that won't get executed.
This patch does the following:
1 - Fix the internal debugserver for Apple to use the BKPT instruction for ARM and Thumb
2 - Fix LLDB to catch when we stop in the middle of a Thumb IT instruction and continue if we stop at an instruction that won't execute
3 - Fixes this in a way that will work for any target on any platform as long as it is ARM/Thumb
4 - Adds a patch for ignoring conditions that don't match when in ARM mode (see below)
This patch also provides the code that implements the same thing for ARM instructions, though it is disabled for now. The ARM patch will check the condition of the instruction in ARM mode and continue if the condition isn't true (and therefore the instruction would not be executed). Again, this is not enable, but the code for it has been added.
<rdar://problem/19145455>
llvm-svn: 223851
Because of the way they are created, synthetic children cannot (in general) have a sane expression path
A solution to this would be letting the parent front-end generate expression paths for its children
Doing so requires a significant amount of refactoring, and might not always lead to better results (esp. w.r.t. C++ templates)
This commit takes a simpler approach:
- if a synthetic child is of pointer type and it's a target pointer, then emit *((T)value)
- if a synthetic child is a non-pointer, but its location is in the target, then emit *((T*)loadAddr)
- if a synthetic child has a value, emit ((T)value)
- else, don't emit anything
Fixes rdar://18442386
llvm-svn: 223836
track of the checksum of the object so we can
track if it is modified. This fixes a testcase
(test/expression_command/issue_11588) on OS X.
Patch by Enrico Granata.
llvm-svn: 223830
- adds a new flag to mark ValueObjects as "synthetic children generated"
- vends new Create functions as part of the SyntheticChildrenFrontEnd that set the flag automatically
- moves synthetic child providers over to using these new functions
No visible feature change, but preparatory work for feature change
llvm-svn: 223819
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
in the "dummy-target". The dummy target breakpoints prime all future
targets. Breakpoints set before any target is created (e.g. breakpoints
in ~/.lldbinit) automatically get set in the dummy target. You can also
list, add & delete breakpoints from the dummy target using the "-D" flag,
which is supported by most of the breakpoint commands.
This removes a long-standing wart in lldb...
<rdar://problem/10881487>
llvm-svn: 223565
format for the not-current-stack-frame. This was causing
test/functionalities/inferior-assert to fail.
Also document the new additions to the format specifications used
in the disassembly-format changes to formats.html.
<rdar://problem/19102757>
llvm-svn: 223096
% lldb /bin/nonono
(lldb) target create "/bin/nonono"
error: unable to find executable for '/usr/bin/nonono'
<deadlock>
The problem was the initial commands 'target create "/bin/nonono"' were put into a pipe and the command interpreter was being run with:
void
CommandInterpreter::RunCommandInterpreter(bool auto_handle_events,
bool spawn_thread,
CommandInterpreterRunOptions &options)
{
// Always re-create the command intepreter when we run it in case
// any file handles have changed.
bool force_create = true;
m_debugger.PushIOHandler(GetIOHandler(force_create, &options));
m_stopped_for_crash = false;
if (auto_handle_events)
m_debugger.StartEventHandlerThread();
if (spawn_thread)
{
m_debugger.StartIOHandlerThread();
}
else
{
m_debugger.ExecuteIOHanders();
if (auto_handle_events)
m_debugger.StopEventHandlerThread();
}
}
If "auto_handle_events" was set to true and "spawn_thread" was false, we would execute:
m_debugger.StartEventHandlerThread();
m_debugger.ExecuteIOHanders();
m_debugger.StopEventHandlerThread();
The problem was there was no synchonization in Debugger::StartEventHandlerThread() to ensure the event handler was listening to events and the the call to "m_debugger.StopEventHandlerThread()" would do:
void
Debugger::StopEventHandlerThread()
{
if (m_event_handler_thread.IsJoinable())
{
GetCommandInterpreter().BroadcastEvent(CommandInterpreter::eBroadcastBitQuitCommandReceived);
m_event_handler_thread.Join(nullptr);
}
}
The problem was that the event thread might not be listening for the CommandInterpreter::eBroadcastBitQuitCommandReceived event yet.
The solution is to make sure the Debugger::DefaultEventHandler() is listening to events before we return from Debugger::StartEventHandlerThread(). Once we have this synchonization we remove the race condition.
This fixes radar:
<rdar://problem/19041192>
llvm-svn: 223083
(e.g. breakpoints, stop-hooks) before we have any targets - for instance in
your ~/.lldbinit file. These will then get copied over to any new targets
that get created. So far, you can only make stop-hooks.
Breakpoints will have to learn to move themselves from target to target for
us to get them from no-target to new-target.
We should also make a command & SB API way to prime this ur-target.
llvm-svn: 222600
Editline does not work correctly on Windows. This goes back at
least to r208369, and as a result r210105 was submitted to disable
libedit at runtime on Windows.
More recently, r222163 was submitted which re-writes editline
entirely, but makes the situation even worse on Windows, to the
point that it doesn't even compile. While it would be easy to
fix the compilation failure, this patch simply stops compiling
Editline entirely on Windows, as the simple compilation fix would
still result in a broken use of select on Windows, and as such a
broken implementation of Editline.
Since Editline was already disabled to begin with on Windows, we
don't attempt to fix the compilation failure or the underlying
issues, and instead just disable it "even more".
llvm-svn: 222177
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
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
ObjectFileMachO. It's close but we seem to be missing some
of the memory region segments - not exactly sure how that's
happening. The register context writing into the LC_THREAD
load commands is working correctly though.
Slightly reordered the arm64 definitions in ArchSpec.cpp so
when we look for an arm64 core file definiton we're getting
a cpu subtype of CPU_ANY which we can't put in the mach
header of a core file. Make the first definition we find by
linear search have the currently correct '1' cpu subtype.
llvm-svn: 221743
I went back and forth on removing this - and tried dropping it for
a few weeks. But when you're working at an assembly language, it
really is helpful to have this displayed to show where the current
pc is.
llvm-svn: 221682
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
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
the runtime rather than trying to fix it up,
because now those types have ivars regardless of
whether they come from "frame variable" or from
expressions.
Patch by Enrico Granata.
llvm-svn: 220982
Summary:
Ed Maste found some problems with the commit in D5988. Address most of these.
While here, also add floating point return handling. This doesn't handle
128-bit long double yet. Since I don't have any system that uses it, I don't
currently have plans to implement it.
Reviewers: emaste
Reviewed By: emaste
Subscribers: emaste, lldb-commits
Differential Revision: http://reviews.llvm.org/D6049
llvm-svn: 220963
better output when we don't have any symbol name.
It looked like this:
0x1097fd029 <ud2
0x1097fd02b <addb %al, (%rax)
now, like this:
0x10cdd3064: ud2
0x10cdd3066: addb %al, (%rax)
<rdar://problem/18833391>
llvm-svn: 220948
Summary:
This adds preliminary support for PowerPC/PowerPC64, for FreeBSD. There are
some issues still:
* Breakpoints don't work well on powerpc64.
* Shared libraries don't yet get loaded for a 32-bit process on powerpc64 host.
* Backtraces don't work. This is due to PowerPC ABI using a backchain pointer
in memory, instead of a dedicated frame pointer register for the backchain.
* Breakpoints on functions without debug info may not work correctly for 32-bit
powerpc.
Reviewers: emaste, tfiala, jingham, clayborg
Reviewed By: clayborg
Subscribers: emaste, lldb-commits
Differential Revision: http://reviews.llvm.org/D5988
llvm-svn: 220944
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
To do this, I fixed the CPPLanguageRuntime::StripNamespacesFromVariableName() function to use a regular expression that correctly determines if the name passed to it is a qualfied C++ name like "a:🅱️:c" or "b::c". The old version of this function was treating '__54-[NSUserScriptTask executeWithInterpreter:arguments::]_block_invoke' as a match with a basename of ']_block_invoke'.
Also fixed a case in the by name lookup of functions where we wouldn't look for the full name if we actually tried to call CPPLanguageRuntime::StripNamespacesFromVariableName() and got an empty basename back.
<rdar://problem/18527866>
llvm-svn: 220432
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
unreachable so we don't get warnings about them.
Completely initialize a structure instead of leaving some of its fields
potentially indeterminate (although in reality they would all be set
before use -- but the compiler warning doesn't know that).
clang warning.
llvm-svn: 220017
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
output style can be customized. Change the built-in default to be
more similar to gdb's disassembly formatting.
The disassembly-format for a gdb-like output is
${addr-file-or-load} <${function.name-without-args}${function.concrete-only-addr-offset-no-padding}>:
The disassembly-format for the lldb style output is
{${function.initial-function}{${module.file.basename}`}{${function.name-without-args}}:\n}{${function.changed}\n{${module.file.basename}`}{${function.name-without-args}}:\n}{${current-pc-arrow} }{${addr-file-or-load}}:
The two backticks in the lldb style formatter triggers the sub-expression evaluation in
CommandInterpreter::PreprocessCommand() so you can't use that one as-is ... changing to
use ' characters instead of ` would work around that.
<rdar://problem/9885398>
llvm-svn: 219544
The way to do this is to write a synthetic child provider for your type, and have it vend the (optional) get_value function.
If get_value is defined, and it returns a valid SBValue, that SBValue's value (as in lldb_private::Value) will be used as the synthetic ValueObject's Value
The rationale for doing things this way is twofold:
- there are many possible ways to define a "value" (SBData, a Python number, ...) but SBValue seems general enough as a thing that stores a "value", so we just trade values that way and that keeps our currency trivial
- we could introduce a new level of layering (ValueObjectSyntheticValue), a new kind of formatter (synthetic value producer), but that would complicate the model (can I have a dynamic with no synthetic children but synthetic value? synthetic value with synthetic children but no dynamic?), and I really couldn't see much benefit to be reaped from this added complexity in the matrix
On the other hand, just defining a synthetic child provider with a get_value but returning no actual children is easy enough that it's not a significant road-block to adoption of this feature
Comes with a test case
llvm-svn: 219330
This is the first step in getting ConnectionFileDescriptor ported
to Windows. It implements a connection against a disk file for
windows. This supports connection strings of the form file://PATH
which are currently supported only on posix platforms in
ConnectionFileDescriptor.
Reviewed by: Greg Clayton
Differential Revision: http://reviews.llvm.org/D5608
llvm-svn: 219145
As part of getting ConnectionFileDescriptor working on Windows,
there is going to be alot of platform specific work to be done.
As a result, the implementation is moving into Host. This patch
performs the code move and fixes up call-sites appropriately.
Reviewed by: Greg Clayton
Differential Revision: http://reviews.llvm.org/D5548
llvm-svn: 219143
works, as do breakpoints, run and pause, display zeroth frame.
See
http://reviews.llvm.org/D5503
for a fuller description of the changes in this commit.
llvm-svn: 218596
See http://reviews.llvm.org/D5495 for more details.
These are changes that are part of an effort to support building llgs, within the AOSP source tree, using the Android.mk
build system, when using the llvm/clang/lldb git repos from AOSP replaced with the experimental ones currently in
github.com/tfiala/aosp-{llvm,clang,lldb,compiler-rt}.
llvm-svn: 218568
was broken in r214984 by the addition of an unconditional error
return at the start of the code block handling this method. Remove
the errant lines.
<rdar://problem/18416691>
llvm-svn: 218291
Changes include:
- fix it so you can select the "host" platform using "platform select host"
- change all callbacks that create platforms to returns shared pointers
- fix TestImageListMultiArchitecture.py to restore the "host" platform by running "platform select host"
- Add a new "PlatformSP Platform::Find(const ConstString &name)" method to get a cached platform
- cache platforms that are created and re-use them instead of always creating a new one
llvm-svn: 218145
This patch moves creates a thread abstraction that represents a
thread running inside the LLDB process. This is a replacement for
otherwise using lldb::thread_t, and provides a platform agnostic
interface to managing these threads.
Differential Revision: http://reviews.llvm.org/D5198
Reviewed by: Jim Ingham
llvm-svn: 217460
LLDB had implemented its own DynamicLibrary class for plugin
support. LLVM has an equivalent mechanism, so this patch deletes
the duplicated code in LLDB and updates LLDB to reference the
mechanism provided by LLVM.
llvm-svn: 216606
Add entries to core_definitions and elf_arch_entries for
those variants. Select the subtype for the variant by parsing
the e_flags field of the elf header.
llvm-svn: 216541
with binaries in the dyld shared cache (esp on iOS) where the file
address for the executable binary (maybe from memory, maybe from
an expanded copy of the dyld shared cache) is different from the
file address in the dSYM. In that case, ObjectFileMachO replaces
the file addresses from the original binary with the dSYM file
addresses (usually 0-based) -- lldb doesn't have a notion of two
file addresses for a given module so they need to agree.
There was a cache of file addresses over in the Symtab so I added
a method to the Module and the objects within to clear any file address
caches if they exist, and added an implementation in the Symtab
module to do that.
<rdar://problem/16929569>
llvm-svn: 216258
This continues the effort to get Host code moved over to HostInfo,
and removes many more instances of preprocessor defines along the
way.
llvm-svn: 216195
See this email thread:
http://lists.cs.uiuc.edu/pipermail/lldb-commits/Week-of-Mon-20140818/012487.html
This patch handles the case where the inferior process exits but leaves the ReadThread in a continuous loop reading from the communication pipe. On MacOSX, the ReadThread exits when it receives a 0 return value from the read due to EOF. On Linux the read returns -1 and sets errno to EIO error, this does not currently cause the thread to shutdown so it continues to read from the comm. In Communication::ReadThread I added a handler for eConnectionStatusError to disconnect and shutdown the thread.
Change by Alex Pepper.
llvm-svn: 216194
This patch creates a HostInfo class, a static class used to answer
basic queries about the host platform. As part of this change,
some functionality is moved from Host to HostInfo, and relevant
fixups are performed in the rest of the codebase.
This is part of a larger effort to isolate more code in the Host
layer into platform-specific groups, to make it easier to make
platform specific changes for a particular Host without breaking
other hosts.
Reviewed by: Greg Clayton
Differential Revision: http://reviews.llvm.org/D4963
llvm-svn: 215992
The select() API on Windows is not compatible with objects other
than sockets, so passing a descriptor for the command pipe to this
function is guaranteed to fail. ConnectionFileDescriptor is still
broken on Windows after this patch, but slightly less broken than
before.
llvm-svn: 215172
This patch moves the logic of many common socket operations into
its own class lldb_private::Socket. It then modifies the
ConnectionFileDescriptor class, and a few users of that class,
to use this new Socket class instead of hardcoding socket logic
directly.
Finally, this patch creates a common interface called IOObject for
any objects that support reading and writing, so that endpoints
such as sockets and files can be treated the same.
Differential Revision: http://reviews.llvm.org/D4641
Reviewed by: Todd Fiala, Greg Clayton
llvm-svn: 214984
DW_OP_fbreg(N) DW_OP_piece(4) DW_OP_fbreg(M) DW_OP_piece(8)
DW_OP_fbreg(N) DW_OP_piece(4) DW_OP_piece(8)
The first grabs 4 bytes from FP+N followed by 8 bytes from FP+M, the second grabs 4 bytes from FP+N followed by zero filling 8 bytes which are unavailable. Of course regiters are stuff supported:
DW_OP_reg3 DW_OP_piece(4) DW_OP_reg8 DW_OP_piece(8)
The fix does the following:
1 - don't push the full piece value onto the stack, keep it on the side
2 - fill zeros for DW_OP_piece(N) opcodes that have nothing on the stack (instead of previously consuming the full piece that was pushed onto the stack)
3 - simplify the logic
<rdar://problem/16930524>
llvm-svn: 214415
i386, i486, i486sx, and i686 are all indistinguishable as far as
PE/COFF files are concerned. This patch adds support for all of
these architectures to PlatformWindows.
Differential Revision: http://reviews.llvm.org/D4658
llvm-svn: 214092
We now catch the issue with a static_assert() at compile time and use llvm::array_lengthof(g_core_definitions) as well.
<rdar://problem/17767541>
llvm-svn: 213778
See the following llvm change for details:
r213743 | tnorthover | 2014-07-23 05:32:47 -0700 (Wed, 23 Jul 2014) | 9 lines
AArch64: remove arm64 triple enumerator.
This change fixes build breaks on Linux and MacOSX lldb.
llvm-svn: 213755
GCC warns on reinterpret_cast expressions involving a void-pointer
source and a pointer-to-function destination. Take a detour through
intptr_t to silence it.
Differential Revision: http://reviews.llvm.org/D4626
llvm-svn: 213691
Platforms which don't use LLDB's built-in demangler don't use the
'mangled_length' variable. Instead, replace it's only use by an
expression it is equivalent to.
Differential Revision: http://reviews.llvm.org/D4625
llvm-svn: 213681
The new implementation is located in source/Core/FastDemangle.cpp. It’s fairly straightforward C code with a few basic C++ extensions. It should compile with little or no change on a variety of platforms, but of course it is still only useful for symbols that comply with the Itanium ABI mangling spec (plus a few Clang extensions.)
<rdar://problem/15397553> <rdar://problem/15794867>
llvm-svn: 213671
1) Preserve ref qualification state in a local variable while parsing a nested name. Previously, the state was recorded in the shared db reference and could therefore be overwritten when parsing multiple levels of nested names (e.g.: when a qualified name has qualified template args.)
2) Address an off-by-one error when testing whether or not a thunk is non-virtual. This resulted in the demangled identifying all thunks as non-virtual.
llvm-svn: 213591
This change comprises of additions and some minor changes in order that
"kalimba" is listed as a supported platform and that debugging any
kalimbas results in PlatformKalimba being associated with the target.
The changes are as follows:
* The PlatformKalimba implementation itself
* A tweak to ArchSpec
* .note parsing for Kalimba in ObjectFileELF.cpp
* Plugin registration
* Makefile additions
Change by Matthew Gardiner
Minor tweak for cmake and Xcode by Todd Fiala
Tested:
Ubuntu 14.04 x86_64, clang 3.5-built lldb, all tests pass.
MacOSX 10.9.4, Xcode 6.0 Beta 1-built lldb, all tests pass.
llvm-svn: 213158
Fixes include:
- Don't say that "<arch>-apple-ios" is compatible with "<arch>-apple-macosx"
- Fixed DynamicLoaderMacOSXDYLD so specify an architecture that was converted solely from a cputype and subtype, just specify the file + UUID.
- Fixed PlatformiOSSimulator::GetSupportedArchitectureAtIndex() so it returns the correct archs
- Fixed SymbolFileDWARFDebugMap to load .o files correctly by just specifying the architecture without the vendor and OS now that "<arch>-apple-ios" is not compatible with "<arch>-apple-macosx" so we can load .o files correctly for DWARF with debug map
- Fixed the coded in TargetList::CreateTarget() so it does the right thing with an underspecified triple where just the arch is specified.
llvm-svn: 212783
Windows does support pipes, but they do so in a slightly different way. Added a Host layer which abstracts the use of pipes into a new Pipe class that everyone can use.
Windows benefits include:
- Being able to interrupt running processes when IO is directly hooked up
- being able to interrupt long running python scripts
- being able to interrupt anything based on ConnectionFileDescriptor
llvm-svn: 212220
off_t is a type which is used for file offsets. Even more
specifically, it is only used by a limited number of C APIs that
deal with files. Any usage of off_t where the variable is not
intended to be used with one of these APIs is a bug, by definition.
This patch corrects some easy mis-uses of off_t, generally by
converting them to lldb::offset_t, but sometimes by using other
types such as size_t, when appropriate.
The use of off_t to represent these offsets has worked fine in
practice on linux-y platforms, since we used _FILE_OFFSET_64 to
guarantee that off_t was a uint64. On Windows, however,
_FILE_OFFSET_64 is unrecognized, and off_t will always be 32-bit.
So the usage of off_t on Windows actually leads to legitimate bugs.
Reviewed by: Greg Clayton
Differential Revision: http://reviews.llvm.org/D4358
llvm-svn: 212192
This change brings in lldb-gdbserver (llgs) specifically for Linux x86_64.
(More architectures coming soon).
Not every debugserver option is covered yet. Currently
the lldb-gdbserver command line can start unattached,
start attached to a pid (process-name attach not supported yet),
or accept lldb attaching and launching a process or connecting
by process id.
The history of this large change can be found here:
https://github.com/tfiala/lldb/tree/dev-tfiala-native-protocol-linux-x86_64
Until mid/late April, I was not sharing the work and continued
to rebase it off of head (developed via id tfiala@google.com). I switched over to
user todd.fiala@gmail.com in the middle, and once I went to github, I did
merges rather than rebasing so I could share with others.
llvm-svn: 212069
Replace adhoc inline implementation of llvm::array_lengthof in favour of the
implementation in LLVM. This is simply a cleanup change, no functional change
intended.
llvm-svn: 211868
The patch is as is with the functionality left disabled for apple vendors because of performance regressions. If this is enabled it ends up searching for symbols in all shared libraries that are loadeded.
llvm-svn: 211638
The issue was when we called Debugger::RunIOHandler(), it would run the current IOHandler by activating it, and running it and then try to pop it and exit regardless of wether it was on top or not.
The new code will push the IOHandler that was passed in, and run the IOHandlers until the one passed in is successfully popped. This allows files for the "command source" to switch input handlers:
% cat /tmp/commands
br s -S alignLeftEdges:
br command add
bt
frame var
po self
DONE
b s -n main
br command add
bt
frame var
DONE
Note above we set a breakpoint, then add commands do it. The "br command add" will push the breakpoint comment gatherer until it sees "DONE" and then pop itself off the stack. The a new breakpoint will be set and it does the same thing again.
Now this file can be sourced from the command line:
% lldb -s /tmp/commands /path/to/a.out
And your breakpoints will be correctly setup!
<rdar://problem/17081650>
llvm-svn: 211329
lldb support. I'll be doing more testing & cleanup but I wanted to
get the initial checkin done.
This adds a new SBExpressionOptions::SetLanguage API for selecting a
language of an expression.
I added adds a new SBThread::GetInfoItemByPathString for retriving
information about a thread from that thread's StructuredData.
I added a new StructuredData class for representing
key-value/array/dictionary information (e.g. JSON formatted data).
Helper functions to read JSON and create a StructuredData object,
and to print a StructuredData object in JSON format are included.
A few Cocoa / Cocoa Touch data formatters were updated by Enrico
to track changes in iOS 8 / Yosemite.
Before we query a thread's extended information, the system runtime may
provide hints to the remote debug stub that it will use to retrieve values
out of runtime structures. I added a new SystemRuntime method
AddThreadExtendedInfoPacketHints which allows the SystemRuntime to add
key-value type data to the initial request that we send to the remote stub.
The thread-format formatter string can now retrieve values out of a thread's
extended info structured data. The default thread-format string picks up
two of these - thread.info.activity.name and thread.info.trace_messages.
I added a new "jThreadExtendedInfo" packet in debugserver; I will
add documentation to the lldb-gdb-remote.txt doc soon. It accepts
JSON formatted arguments (most importantly, "thread":threadnum) and
it returns a variety of information regarding the thread to lldb
in JSON format. This JSON return is scanned into a StructuredData
object that is associated with the thread; UI layers can query the
thread's StructuredData to see if key-values are present, and if
so, show them to the user. These key-values are likely to be
specific to different targets with some commonality among many
targets. For instance, many targets will be able to advertise the
pthread_t value for a thread.
I added an initial rough cut of "thread info" command which will print
the information about a thread from the jThreadExtendedInfo result.
I need to do more work to make this format reasonably.
Han Ming added calls into the pmenergy and pmsample libraries if
debugserver is run on Mac OS X Yosemite to get information about the
inferior's power use.
I added support to debugserver for gathering the Genealogy information
about threads, if it exists, and returning it in the jThreadExtendedInfo
JSON result.
llvm-svn: 210874
(lldb) file /bin/ls
(lldb) b malloc
(lldb) run
(lldb) process save-core /tmp/ls.core
Each ObjectFile plug-in now has the option to save core files by registering a new static callback.
llvm-svn: 210864
We preivously had two copies of ::BytesAvailable with only trivial
differences between them, and fixes have been applied to only one of
them.
Instead of duplicating the whole function, hide the FD_SET differences
behind a macro. This leaves only one small __APPLE__-specific #if
block, and fixes ^C on non-__APPLE__ platforms.
llvm-svn: 210592
Changes include:
- ObjectFileMachO can now determine if a binary is "*-apple-ios" or "*-apple-macosx" by checking the min OS and SDK load commands
- ArchSpec now says "<arch>-apple-macosx" is equivalent to "<arch>-apple-ios" since the simulator mixes and matches binaries (some from the system and most from the iOS SDK).
- Getting process inforamtion on MacOSX now correctly classifies iOS simulator processes so they have "*-apple-ios" architectures in the ProcessInstanceInfo
- PlatformiOSSimulator can now list iOS simulator processes correctly instead of showing nothing by using:
(lldb) platform select ios-simulator
(lldb) platform process list
- debugserver can now properly return "*-apple-ios" for the triple in the process info packets for iOS simulator executables
- GDBRemoteCommunicationClient now correctly passes along the triples it gets for process info by setting the OS in the llvm::Triple correctly
<rdar://problem/17060217>
llvm-svn: 209852
This fixes a number of trivial warnings in the Windows build. This is part of a larger effort to make the Windows build warning-free.
See http://reviews.llvm.org/D3914 for more details.
Change by Zachary Turner
llvm-svn: 209749
Rationale:
Pretty simply, the idea is that sometimes type names are way too long and contain way too many details for the average developer to care about. For instance, a plain ol' vector of int might be shown as
std::__1::vector<int, std::__1::allocator<....
rather than the much simpler std::vector<int> form, which is what most developers would actually type in their code
Proposed solution:
Introduce a notion of "display name" and a corresponding API GetDisplayTypeName() to return such a crafted for visual representation type name
Obviously, the display name and the fully qualified (or "true") name are not necessarily the same - that's the whole point
LLDB could choose to pick the "display name" as its one true notion of a type name, and if somebody really needs the fully qualified version of it, let them deal with the problem
Or, LLDB could rename what it currently calls the "type name" to be the "display name", and add new APIs for the fully qualified name, making the display name the default choice
The choice that I am making here is that the type name will keep meaning the same, and people who want a type name suited for display will explicitly ask for one
It is the less risky/disruptive choice - and it should eventually make it fairly obvious when someone is asking for the wrong type
Caveats:
- for now, GetDisplayTypeName() == GetTypeName(), there is no logic to produce customized display type names yet.
- while the fully-qualified type name is still the main key to the kingdom of data formatters, if we start showing custom names to people, those should match formatters
llvm-svn: 209072
Add a callback that will allow an expression to be cancelled between the
expression evaluation stages (for the ClangUserExpressions.)
<rdar://problem/16790467>, <rdar://problem/16573440>
llvm-svn: 207944
- CTRL+C wasn't clearing the command in lldb
- CTRL+C doesn't work in python macros in lldb
- Ctrl+C no longer interrupts the running process that you attach to
<rdar://problem/15949205>
<rdar://problem/16778652>
<rdar://problem/16774411>
llvm-svn: 207816
Currently if you run _any_ python, python has the "lldb.debugger" global variable and it has a strong reference to a lldb_private::Debugger since it is a lldb::SBDebugger object with a shared pointer.
This makes sure that your LLDB command interpreter history is saved each time you quit command line LLDB.
llvm-svn: 207164
Set the correct FormatManager revision before starting to figure out the new formatters
This can avoid entering some corner cases where as part of figuring out formatters we try to figure out dynamic types, and in turn that causes us to go back in trying to fetch new formatters - it is not only a futile exercise, it's also prone to endless recursion
This would only cause a behavior change if getting this chain started would eventually cause something to run and alter the formatters, a very unlikely if at all possible sequence of events
llvm-svn: 205928
TIDs are conventionally shown as decimal values on FreeBSD and Linux.
Thus, use the ${thread.id%tid} format string to display the thread ID,
instead of a fixed hex format.
llvm.org/pr19380
llvm-svn: 205912
This is a purely mechanical change explicitly casting any parameters for printf
style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux.
llvm-svn: 205607
This is a mechanical change addressing the various sign comparison warnings that
are identified by both clang and gcc. This helps cleanup some of the warning
spew that occurs during builds.
llvm-svn: 205390
For some reason, the libc++ vector<bool> data formatter was essentially a costly no-up, doing everything required of it, except actually generating the child values!
This restores its functionality
llvm-svn: 205259
These changes were written by Greg Clayton, Jim Ingham, Jason Molenda.
It builds cleanly against TOT llvm with xcodebuild. I updated the
cmake files by visual inspection but did not try a build. I haven't
built these sources on any non-Mac platforms - I don't think this
patch adds any code that requires darwin, but please let me know if
I missed something.
In debugserver, MachProcess.cpp and MachTask.cpp were renamed to
MachProcess.mm and MachTask.mm as they picked up some new Objective-C
code needed to launch processes when running on iOS.
llvm-svn: 205113
For small structs, the frame format now prints them as one-liners
This follows the same definition that frame variable does for deciding what a "small struct" is, and as such should be fairly consistent with the variable display in general
llvm-svn: 204762
Add a GetFoundationVersion() to AppleObjCRuntime
This API is used to return and cache the major version of Foundation.framework, which is potentially a useful piece of data to key off of to enable or disable certain ObjC related behaviors (especially in data formatters)
llvm-svn: 204756
(lldb) b puts
(lldb) expr -g -i0 -- (int)puts("hello")
First we will stop at the entry point of the expression before it runs, then we can step over a few times and hit the breakpoint in "puts", then we can continue and finishing stepping and fininsh the expression.
Main features:
- New ObjectFileJIT class that can be easily created for JIT functions
- debug info can now be enabled when parsing expressions
- source for any function that is run throught the JIT is now saved in LLDB process specific temp directory and cleaned up on exit
- "expr -g --" allows you to single step through your expression function with source code
<rdar://problem/16382881>
llvm-svn: 204682
This is a mechanical cleanup of unused functions. In the case where the
functions are referenced (in comment form), I've simply commented out the
functions. A second pass to clean that up is warranted.
The functions which are otherwise unused have been removed. Some of these were
introduced in the initial commit and not in use prior to that point!
NFC
llvm-svn: 204310
TestPromptFormats appears as though it may be a useful unit test.
Unfortunately, there is no invocation mechanism in place right now. It is
unclear how to add a unit test for this scenario to the existing tests. It
would be ideal to remove this entirely, but I am hopeful that this can/will be
pulled out into a test still since it uses a user accessible interface.
llvm-svn: 204309
for customizing "step-in" behavior (e.g. step-in doesn't step into code with no debug info), but also
the behavior of step-in/step-out and step-over when they step out of the frame they started in.
I also added as a proof of concept of this reworking a mode for stepping where stepping out of a frame
into a frame with no debug information will continue stepping out till it arrives at a frame that does
have debug information. This is useful when you are debugging callback based code where the callbacks
are separated from the code that initiated them by some library glue you don't care about, among other
things.
llvm-svn: 203747
read during materialization. First of all, report
if we can't read the data for some reason. Second,
consult the ValueObject's error and report that if
there's some problem.
<rdar://problem/16074201>
llvm-svn: 202552
I carefully reviewed exactly how the IOHandlers interact and found places where we weren't properly controlling things. There should be no overlapping prompts and all output should now come out in a controlled fashion.
<rdar://problem/16111293>
llvm-svn: 202525
Revert the spirit of r199857 - a convincing case can be made that overriding a summary's format markers behind its back is not the right thing to do
This commit reverts the behavior of the code to the previous model, and changes the test case to validate the opposite of what it was validating before
llvm-svn: 201455
ObjectFile::SetLoadAddress (Target &target,
lldb::addr_t value,
bool value_is_offset);
Now "value" is a slide if "value_is_offset" is true, and "value" is an image base address otherwise. All previous usage of this API was using slides.
Updated the ObjectFileELF and ObjectFileMachO SetLoadAddress methods to do the right thing.
Also updated the ObjectFileMachO::SetLoadAddress() function to not load __LINKEDIT when it isn't needed and to only load sections that belong to the executable object file.
llvm-svn: 201003
Move some code that was in DynamicLoaderPOSIXDLYD into the
base class DynamicLoader. In the case of UpdateLoadedSections(),
the test to see whether a file is loadable (its address is zero)
is not generally applicable so that test is changed to a more
universally applicable check for the SHF_ALLOC flag on the section.
Also make it explicit that the reading of the module_id in
DynamicLoaderPOSIXDYLD::GetThreadLocalData() is using a hardcoded
size (of module_id) of 4, which might not be appropriate on
big-endian 64-bit systems, leaving a FIXME comment in place.
llvm-svn: 200939
- empty lines in init files would repeat previous command and cause errors to be displayed
- all options to control showing the command, its output, if it should stop on error or continue, weren't being obeyed.
llvm-svn: 200860
The many many benefits include:
1 - Input/Output/Error streams are now handled as real streams not a push style input
2 - auto completion in python embedded interpreter
3 - multi-line input for "script" and "expression" commands now allow you to edit previous/next lines using up and down arrow keys and this makes multi-line input actually a viable thing to use
4 - it is now possible to use curses to drive LLDB (please try the "gui" command)
We will need to deal with and fix any buildbot failures and tests and arise now that input/output and error are correctly hooked up in all cases.
llvm-svn: 200263
GetU32 and GetU64, to use memcpy to copy bytes into a local buffer instead
of having a (uint64_t *) etc local variable, pointing to the address, and
dereferencing it. If compiled on a CPU where data alignment is required
(e.g. the LDM instruction on armv7) and we try to GetU64 out of a mmap'ed
DWARF file, that 8 byte quantity may not be world aligned and the program
can get an unaligned memory access fault.
<rdar://problem/15849231>
llvm-svn: 200069
ArchSpec now contains an optional distribution_id, with getters and
setters. Host::GetArchitecture () sets it on non-Apple platforms using
Host::GetDistributionId (). The distribution_id is ignored during
ArchSpec comparisons.
The gdb remote qHostInfo message transmits it, if set, via the
distribution_id={id-value} key/value pair. Updated gdb remote docs to
reflect this change.
As before, GetDistributionId () returns nothing on non-Linux platforms
at this time. On Linux, it is returned only if the lsb_platform
command is installed (in /bin or /usr/bin), and only if the
distributor id key is returned by 'lsb_platform -i'. This id is
lowercased, and whitespace is replaced with underscores.
llvm-svn: 199539
symbols correctly. There were a couple of pieces to this.
1) When a breakpoint location finds itself pointing to an Indirect symbol, when the site for it is created
it needs to resolve the symbol and actually set the site at its target.
2) Not all breakpoints want to do this (i.e. a straight address breakpoint should always set itself on the
specified address, so somem machinery was needed to specify that.
3) I added some info to the break list output for indirect symbols so you could see what was happening.
Also I made it clear when we re-route through re-exported symbols.
4) I moved ResolveIndirectFunction from ProcessPosix to Process since it works the exact same way on Mac OS X
and the other posix systems. If we find a platform that doesn't do it this way, they can override the
call in Process.
5) Fixed one bug in RunThreadPlan, if you were trying to run a thread plan after a "running" event had
been broadcast, the event coalescing would cause you to miss the ThreadPlan running event. So I added
a way to override the coalescing.
6) Made DynamicLoaderMacOSXDYLD::GetStepThroughTrampolinePlan handle Indirect & Re-exported symbols.
<rdar://problem/15280639>
llvm-svn: 198976
The "type format add" command gets a new flag --type (-t). If you pass -t <sometype>, upon fetching the value for an object of your type,
LLDB will display it as-if it was of enumeration type <sometype>
This is useful in cases of non-contiguous enums where there are empty gaps of unspecified values, and as such one cannot type their variables as the enum type,
but users would still like to see them as-if they were of the enum type (e.g. DWARF field types with their user-reserved ranges)
The SB API has also been improved to handle both types of formats, and a test case is added
llvm-svn: 198105
TypeFormatImpl used to just wrap a Format (and Flags for matching), and then ValueObject itself would do the printing deed
With this checkin, the responsibility of generating a value string is centralized in the data formatter (as it should, and already is for summaries)
This change is good practice per se, and should also enable us to extend the type format mechanism in a cleaner way
llvm-svn: 197874
Previously, an opcode set via SetOpcode32 (for example) was later
extracted via GetData() as a byte sequence in host order rather than
target order.
Review: http://llvm-reviews.chandlerc.com/D1838
llvm-svn: 196808
<rdar://problem/15314403>
This patch adds a new lldb_private::SectionLoadHistory class that tracks what shared libraries were loaded given a process stop ID. This allows us to keep a history of the sections that were loaded for a time T. Many items in history objects will rely upon the process stop ID in the future.
llvm-svn: 196557
This gets rid of our hacky "get_random_port()" which would grab a random port and tell debugserver to open that port. Now LLDB creates, binds, listens and accepts a connection by binding to port zero and sending the correctly bound port down as the host:port to connect back to.
Fixed the "ConnectionFileDescriptor" to be able to correctly listen for connections from a specified host, localhost, or any host. Prior to this fix "listen://" only accepted the following format:
listen://<port>
But now it can accept:
listen://<port> // Listen for connection from localhost on port <port>
listen://<host>:<port> // Listen for connection from <host> and <port>
listen://*:<port> // Listen for connection from any host on port <port>
llvm-svn: 196547
lldb_private::Debugger was #including some "lldb/API" header files which causes tools (lldb-platform and lldb-gdbserver) that link against the internals only (no API layer) to fail to link depending on which calls were being used.
Also fixed the current working directory so that it gets set correctly for remote test suite runs. Now the remote working directory is set to: "ARCH/TESTNUM/..." where ARCH is the current architecture name and "TESTNUM" is the current test number.
Fixed the "lldb-platform" and "lldb-gdbserver" to not warn about mismatched visibility settings by having each have their own exports file which contains nothing. This forces all symbols to not be exported, and also quiets the linker warnings.
llvm-svn: 196141
Rework data formatters matching algorithm
What happens now is that, for each category, the FormatNavigator generates all possible matches, and checks them one by one
Since the possible matches do not actually depend on the category (whether a match is accepted or not does, but that check can be shifted at a more convenient time),
it is actually feasible to generate every possible match upfront and then let individual categories just scan through those
This commit changes things by introducing a notion of formatters match candidate, and shifting responsibility for generating all of them given a (ValueObject,DynamicValueType) pair
from the FormatNavigator back to the FormatManager
A list of these candidates is then passed down to each category for matching
Candidates also need to remember whether they were generated by stripping pointers, references, typedefs, since this is something that individual formatters can choose to reject
This check, however, is conveniently only done once a "textual" match has been found, so that the list of candidates is truly category-independent
While the performance benefit is small (mostly, due to caching), this is much cleaner from a design perspective
llvm-svn: 195395
Example code:
remote_platform = lldb.SBPlatform("remote-macosx");
remote_platform.SetWorkingDirectory("/private/tmp")
debugger.SetSelectedPlatform(remote_platform)
connect_options = lldb.SBPlatformConnectOptions("connect://localhost:1111");
err = remote_platform.ConnectRemote(connect_options)
if err.Success():
print >> result, 'Connected to remote platform:'
print >> result, 'hostname: %s' % (remote_platform.GetHostname())
src = lldb.SBFileSpec("/Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework", False)
dst = lldb.SBFileSpec()
# copy src to platform working directory since "dst" is empty
err = remote_platform.Install(src, dst);
if err.Success():
print >> result, '%s installed successfully' % (src)
else:
print >> result, 'error: failed to install "%s": %s' % (src, err)
Implemented many calls needed in lldb-platform to be able to install a directory that contains symlinks, file and directories.
The remote lldb-platform can now launch GDB servers on the remote system so that remote debugging can be spawned through the remote platform when connected to a remote platform.
The API in SBPlatform is subject to change and will be getting many new functions.
llvm-svn: 195273
The demangler added in r193708 from cxa_demangle.cpp uses language features which are not supported by the latest visual studio. In order to preserve the msvc build, this patch restores the previous (non)functionality in windows under msvc by disabling the demangler.
llvm-svn: 195254
pure virtual base class and made StackFrame a subclass of that. As
I started to build on top of that arrangement today, I found that it
wasn't working out like I intended. Instead I'll try sticking with
the single StackFrame class -- there's too much code duplication to
make a more complicated class hierarchy sensible I think.
llvm-svn: 193983
defines a protocol that all subclasses will implement. StackFrame
is currently the only subclass and the methods that Frame vends are
nearly identical to StackFrame's old methods.
Update all callers to use Frame*/Frame& instead of pointers to
StackFrames.
This is almost entirely a mechanical change that touches a lot of
the code base so I'm committing it alone. No new functionality is
added with this patch, no new subclasses of Frame exist yet.
I'll probably need to tweak some of the separation, possibly moving
some of StackFrame's methods up in to Frame, but this is a good
starting point.
<rdar://problem/15314068>
llvm-svn: 193907
FreeBSD includes the elftoolchain project's demangler in the base system.
It does not handle some unusual mangled names, so use the inlined
libcxxabi one.
llvm-svn: 193776
Inlined a copy of cxa_demangle.cpp from:
http://llvm.org/svn/llvm-project/libcxxabi/trunk/src/cxa_demangle.cpp
For systems that don't have demangling built into the system, and for systems that don't want to use the version that is installed. Defining LLDB_USE_BUILTIN_DEMANGLER in your build system allows you to use the built in demangler. This setting is curently automatically enabled for Windows builds.
llvm-svn: 193708
Fixing a problem where ValueObject::GetPointeeData() would not accept "partial" valid reads (i.e. asking for 10 items and getting only 5 back)
While suboptimal, this situation is not a flat-out failure and could well be caused by legit scenarios, such as hitting a page boundary
Among others, this allows data formatters to print char* buffers allocated under libgmalloc
llvm-svn: 193704
One of the things that dynamic typing affects is the count of children a type has
Clear out the flag that makes us blindly believe the children count when a dynamic type change is detected
llvm-svn: 193663
This commit reimplements the TypeImpl class (the class that backs SBType) in terms of a static,dynamic type pair
This is useful for those cases when the dynamic type of an ObjC variable can only be obtained in terms of an "hollow" type with no ivars
In that case, we could either go with the static type (+iVar information) or with the dynamic type (+inheritance chain)
With the new TypeImpl implementation, we try to combine these two sources of information in order to extract as much information as possible
This should improve the functionality of tools that are using the SBType API to do extensive dynamic type inspection
llvm-svn: 193564
Introduce a new boolean setting enable-auto-oneliner
This setting if set to false will force LLDB to not use the new compact one-line display
By default, one-line mode stays on, at least until we can be confident it works.
But now if it seriously impedes your workflow while it evolves/it works wonders but you still hate it, there's a way to turn it off
llvm-svn: 193450
Extend DummySyntheticProvider to actually use debug-info vended children as the source of information
Make Python synthetic children either be valid, or fallback to the dummy, like their C++ counterparts
This allows LLDB to actually stop bailing out upon encountering an invalid synthetic children provider front-end, and still displaying the non synthetized ivar info
llvm-svn: 192741
Fixed Module::ResolveSymbolContextForAddress() to be able to also look in the SymbolVendor's SymbolFile's ObjectFile for a more meaningful symbol when a symbol lookup finds a synthetic symbol from the main object file. This will help lookups on MacOSX as the main executable might be stripped, but the dSYM file always has a full symbol table.
llvm-svn: 192510
Based on the POSIX x86_64 register context. This is sufficient for opening
a mips64 (big endian) core file. Subsequent changes will connect the
disassembler, dynamic loader support, ABI, etc.
Review: http://llvm-reviews.chandlerc.com/D1873
llvm-svn: 192335
ObjectFile::CopyData is used to copy a block of target memory to the
caller's buffer (e.g. for "memory read"). This should be a straight
memcpy, and not byte-swapped if the target and host have different
endianness.
Add a new DataExtractor::CopyData() method that performs this straight
copy and use it in ObjectFile::CopyData().
llvm-svn: 192323
Constant ValueObjects should clear their description as well as their summary. Rationale being that both can depend on deeper-than-constified data
so both are subject to changes in "unpredictable" ways
To see this consider repeatedly po'ing a persistent variable of a type whose -description result changes at each invocation
llvm-svn: 192259
Formats (as in "type format") are now included in categories
The only bit missing is caching formats along with synthetic children and summaries, which might be now desirable
llvm-svn: 192217
that all clients use them explicitly. This will hopefully
prevent any future confusion where things get cast to types
we don't expect.
<rdar://problem/15146458>
llvm-svn: 191984
to be explicit, to prevent horrid things like
std::string a = ConstString("foo")
from taking the path ConstString -> bool -> char
-> std::string.
This fixes, among other things, ClangFunction.
<rdar://problem/15137989>
llvm-svn: 191934
DumpValueObject() 2.0
This checkin restores pre-Xcode5 functionality to the "po" (expr -O) command:
- expr now has a new --description-verbosity (-v) argument, which takes either compact or full as a value (-v is the same as -vfull)
When the full mode is on, "po" will show the extended output with type name, persistent variable name and value, as in
(lldb) expr -O -v -- foo
(id) $0 = 0x000000010010baf0 {
1 = 2;
2 = 3;
}
When -v is omitted, or -vcompact is passed, the Xcode5-style output will be shown, as in
(lldb) expr -O -- foo
{
1 = 2;
2 = 3;
}
- for a non-ObjectiveC object, LLDB will still try to retrieve a summary and/or value to display
(lldb) po 5
5
-v also works in this mode
(lldb) expr -O -vfull -- 5
(int) $4 = 5
On top of that, this is a major refactoring of the ValueObject printing code. The functionality is now factored into a ValueObjectPrinter class for easier maintenance in the future
DumpValueObject() was turned into an instance method ValueObject::Dump() which simply calls through to the printer code, Dump_Impl has been removed
Test case to follow
llvm-svn: 191694
Now that SBValues can be setup to ignore synthetic values, this is no longer necessary, and so m_suppress_synthetic_value can go away
Another Hack Bites the Dust
llvm-svn: 191338
to build out the symbol table as addresses are used, and implements
the mechanism for ELF to add stripped symbols from eh_frame.
Uses this mechanism to allow disassembly for addresses corresponding
to stripped symbols for ELF, and provide hooks to implement this for
PE COFF.
Also removes eSymbolContextTailCall in favor of an option for
ResolveSymbolContextForAddress for consistency with the documentation
for eSymbolContextEverything. Essentially, this is just an option for
interpreting the so_addr.
llvm-svn: 191307
Specifically, allows the unwinder to handle the case where sc.function
gets resolved with a pc that is one past the address range of the function
(consistent with a tail call). However, there is no matching symbol.
Adds eSymbolContextTailCall to provide callers with control over the scope
of symbol resolution and to allow ResolveSymbolContextForAddress to handle
tail calls since this routine is common to unwind and disassembly.
llvm-svn: 191102
Targets and hosts today are little-endian (arm, x86), so this change
should be a no-op as they will not encounter the byte swapping cases.
Byte swapping will happen when cross debugging of big endian-targets
(e.g. MIPS, PPC) on a little-endian host (x86). Register- or word-
sized data copies need to be swapped, but calls to ExtractBytes or
CopyByteOrderedData that would invoke the swapping case are presumably
in error.
llvm-svn: 191005
We cannot use "GetMaxU64Bitfield" for non-power-of-two sizes, so just use
the same code that handles N > 8 for these.
Review: http://llvm-reviews.chandlerc.com/D1699
llvm-svn: 190873
for the frame is one past the address range of the calling function.
- Lowers the fix from RegisterContextLLDB for use with disassembly
- Fixes one of three issues in the disassembly test in TestInferiorAssert.py
Also adds documentation that explains the resolution depths and interface.
Note: This change affects the resolution scope for eSymbolContextFunction
without impacting the performance of eSymbolContextSymbol.
Thanks to Matt Kopec for his review.
llvm-svn: 190812
with prefer_file_cache == false. This is what we want to do when
the user is doing a disassemble command -- show the actual memory
contents in case the memory has been corrupted or something -- but
when we're profiling functions for stepping or unwinding
(ThreadPlanStepRange::GetInstructionsForAddress,
UnwindAssemblyInstEmulation::GetNonCallSiteUnwindP) we can read
__TEXT instructions directly out of the file, if it exists.
<rdar://problem/14397491>
llvm-svn: 190638
This allows the PC to be directly changed to a different line.
It's similar to the example python script in examples/python/jump.py, except implemented as a builtin.
Also this version will track the current function correctly even if the target line resolves to multiple addresses. (e.g. debugging a templated function)
llvm-svn: 190572
SVN r189964 provided a sample Python script to inspect unordered(multi){set|map} with synthetic children, contribued by Jared Grubb
This checkin converts that sample script to a C++ provider built into LLDB
A test case is also provided
llvm-svn: 190564
Since I renamed most of the LLVM Mach-O enums in r189314, I had to go fix
LLDB to use the new names. While I was here, I decided that a COFF
plugin really shouldn't be using Mach-O enums.
llvm-svn: 189316
Summary:
This merge brings in the improved 'platform' command that knows how to
interface with remote machines; that is, query OS/kernel information, push
and pull files, run shell commands, etc... and implementation for the new
communication packets that back that interface, at least on Darwin based
operating systems via the POSIXPlatform class. Linux support is coming soon.
Verified the test suite runs cleanly on Linux (x86_64), build OK on Mac OS
X Mountain Lion.
Additional improvements (not in the source SVN branch 'lldb-platform-work'):
- cmake build scripts for lldb-platform
- cleanup test suite
- documentation stub for qPlatform_RunCommand
- use log class instead of printf() directly
- reverted work-in-progress-looking changes from test/types/TestAbstract.py that work towards running the test suite remotely.
- add new logging category 'platform'
Reviewers: Matt Kopec, Greg Clayton
Review: http://llvm-reviews.chandlerc.com/D1493
llvm-svn: 189295
This means that "register read stmm0 --format f" actually works now.
This is a little messy but LLDB assumes 'long double' is portable, when it is not.
llvm-svn: 188698
address.
When loading a dSYM, and the file addresses of the dSYM Sections are
different than the executable binary Sections' file addresses, the
debug info won't be remapped to the actual load addresses correctly.
This only happens with binaries on the in-memory shared cache binaries
where their File addresses have been set to their actual load address
(outside an offset value) whereas the original executable and dSYM
have 0-based File addresses.
I think this patch will not be activated for other cases -- this is
the only case we know of where the dSYM and the executable's File
addresses differ -- but if this causes other problems we can restrict
it more carefully.
<rdar://problem/12335086>
llvm-svn: 188532
LLDB needs in memory module load level settings to control how much information is read from memory when loading in memory modules. This change adds a new setting:
(lldb) settings set target.memory-module-load-level [minimal|partial|complete]
minimal will load only sections (no symbols, or function bounds via function starts or EH frame)
partial will load sections + bounds
complete will load sections + bounds + symbols
llvm-svn: 188246
list have a shared pointer back to their DisassemblerLLVMC. This checkin force clears the InstructionList
in all the places we use the DisassemblerSP to stop the leaking for now. I'll go back and fix this
for real when I have time to do so.
<rdar://problem/14581918>
llvm-svn: 187473
ELF notes contain a 'name' field, which specifies a vendor who defines
the format of the note. Examples are 'FreeBSD' or 'GNU', or it may be
empty for generic notes.
Add a case for FreeBSD-specific notes, leaving Linux and GNU notes,
other vendor-specific notes, and generic notes to be handled by the
existing code for now.
Thanks to Samuel Jacob for reviewing and suggesting improvements.
llvm-svn: 186973
Added a setting to control timeout for kdp response packets. While I was at it, I also added a way to control the response timeout for gdb-remote packets.
KDP defaults to 5 seconds, and GDB defaults to 1 second. These were the default values that were in the code prior to adding these settings.
(lldb) settings set plugin.process.gdb-remote.packet-timeout 10
(lldb) settings set plugin.process.kdp-remote.packet-timeout 10
llvm-svn: 186360
- MachO files now correctly extract the UUID all the time
- More file size and offset verification done for universal mach-o files to watch for truncated files
- ObjectContainerBSDArchive now supports enumerating all objects in BSD archives (.a files)
- lldb_private::Module() can not be properly constructed using a ModuleSpec for a .o file in a .a file
- The BSD archive plug-in shares its cache for GetModuleSpecifications() and the create callback
- Improved printing for ModuleSpec objects
llvm-svn: 186211
A long time ago we start with clang types that were created by the symbol files and there were many functions in lldb_private::ClangASTContext that helped. Later we create ClangASTType which contains a clang::ASTContext and an opauque QualType, but we didn't switch over to fully using it. There were a lot of places where we would pass around a raw clang_type_t and also pass along a clang::ASTContext separately. This left room for error.
This checkin change all type code over to use ClangASTType everywhere and I cleaned up the interfaces quite a bit. Any code that was in ClangASTContext that was type related, was moved over into ClangASTType. All code that used these types was switched over to use all of the new goodness.
llvm-svn: 186130
- ObjectFile::GetSymtab() and ObjectFile::ClearSymtab() no longer takes any flags
- Module coordinates with the object files and contain a unified section list so that object file and symbol file can share sections when they need to, yet contain their own sections.
Other cleanups:
- Fixed Symbol::GetByteSize() to not have the symbol table compute the byte sizes on the fly
- Modified the ObjectFileMachO class to compute symbol sizes all at once efficiently
- Modified the Symtab class to store a file address lookup table for more efficient lookups
- Removed Section::Finalize() and SectionList::Finalize() as they did nothing
- Improved performance of the detection of symbol files that have debug maps by excluding stripped files and core files, debug files, object files and stubs
- Added the ability to tell if an ObjectFile has been stripped with ObjectFile::IsStripped() (used this for the above performance improvement)
llvm-svn: 185990
There are two new classes:
lldb::SBModuleSpec
lldb::SBModuleSpecList
The SBModuleSpec wraps up a lldb_private::ModuleSpec, and SBModuleSpecList wraps up a lldb_private::ModuleSpecList.
llvm-svn: 185877
Both StopReadThread and the thread being stopped set the thread id to
0 after m_read_thread_enabled was set to false. If the thread being
stopped got there first then StopReadThread called pthread_join on an
invalid thread number. This is not a Good Thing,
Should fix a fairly regular segfault when quitting on Linux.
llvm-svn: 185107
Specifically, the ${target ${process ${thread and ${frame specifiers have been extended to allow a subkeyword .script:<fctName> (e.g. ${frame.script:FooFunction})
The functions are prototyped as
def FooFunction(Object,unused)
where object is of the respective SB-type (SBTarget for target.script, ... and so on)
This has not been implemented for ${var because it would be akin to a Python summary which is already well-defined in LLDB
llvm-svn: 184500
The script was able to point out and save 40 bytes in each lldb_private::Section by being very careful where we need to have virtual destructors and also by re-ordering members.
llvm-svn: 184364
Modifying our data formatters matching algorithm to ensure that "const X*" is treated as equivalent to "X*"
Also, a couple improvements to the "lldb types" logging
llvm-svn: 184215
325,000 breakpoints for running "breakpoint set --func-regex ." on lldb itself (after hitting a breakpoint at main so that LLDB.framework is loaded) used to take up to an hour to set, now we are down under a minute. With warm file caches, we are at 40 seconds, and that is with setting 325,000 breakpoint through the GDB remote API. Linux and the native debuggers might be faster. I haven't timed what how much is debug info parsing and how much is the protocol traffic to/from GDB remote.
That there were many performance issues. Most of them were due to storing breakpoints in the wrong data structures, or using the wrong iterators to traverse the lists, traversing the lists in inefficient ways, and not optimizing certain function name lookups/symbol merges correctly.
Debugging after that is also now very efficient. There were issues with replacing the breakpoint opcodes in memory that was read, and those routines were also fixed.
llvm-svn: 183820
Modified the test programs to use floating point constants that always will display correctly. We had some numbers that were being rounded, and now that we are using clang, we no longer round them and we get more correct results.
llvm-svn: 183792
Add support for half-floats, as specified by IEEE-754-2008
With this checkin, you can now say:
(lldb) x/7hf foo
to read 7 half-floats at address foo
llvm-svn: 183716
level. Fixes a bug in "break set --source-pattern-regexp" when a shared library is
specified.
Also cleaned up the help text for --source-pattern-regexp so it is a little clearer.
<rdar://problem/14084261>
llvm-svn: 183476
Fixing an issue where formats would not propagate from parents to children in all cases
Details follow:
an SBValue has children and those are fetched along with their values
Now, one calls SBValue::SetFormat() on the parent
Technically, the format choices should propagate onto the children (see ValueObject::GetFormat())
But if the children values are already fetched, they won't notice the format change and won't update themselves
This commit fixes that by making ValueObject::GetValueAsCString() check if any format change intervened from the previous call to the current one
A test case is also added
llvm-svn: 183030
command script import now does reloads - for real
If you invoke command script import foo and it detects that foo has already been imported, it will
- invoke reload(foo) to reload the module in Python
- re-invoke foo.__lldb_init_module
This second step is necessary to ensure that LLDB does not keep cached copies of any formatter, command, ... that the module is providing
Usual caveats with Python imports persist. Among these:
- if you have objects lurking around, reloading the module won't magically update them to reflect changes
- if module A imports module B, reloading A won't reload B
These are Python-specific issues independent of LLDB that would require more extensive design work
The --allow-reload (-r) option is maintained for compatibility with existing scripts, but is clearly documented as redundant - reloading is always enabled whether you use it or not
llvm-svn: 182977
Which means "platform process list" should work and list the architecture.
We are now parsing the elf build-id if it exists, which should allow us to load stripped symbols (looking at that next).
llvm-svn: 182610
settings set use-color [false|true]
settings set prompt "${ansi.bold}${ansi.fg.green}(lldb)${ansi.normal} "
also "--no-use-colors" on the command prompt
llvm-svn: 182609
Lock the lldb_private::Module mutex while tearing down the module to make sure we don't get clients accessing the contents on a module as it is going away.
llvm-svn: 182511
Yet another implementation of the python in dSYM autoload :)
This time we are going with a ternary setting:
true - load, do not warn
false - do not load, do not warn
warn - do not load, warn (default)
llvm-svn: 182414
There are two settings:
target.load-script-from-symbol-file is a boolean that says load or no load (default: false)
target.warn-on-script-from-symbol-file is also a boolean, it says whether you want to be warned when a script file is not loaded due to security (default: true)
the auto loading on change for target.load-script-from-symbol-file is preserved
llvm-svn: 182336
This changes the setting target.load-script-from-symbol-file to be a ternary enum value:
default (the default value) will NOT load the script files but will issue a warning suggesting workarounds
yes will load the script files
no will not load the script files AND will NOT issue any warning
if you change the setting value from default to yes, that will then cause the script files to be loaded
(the assumption is you didn't know about the setting, got a warning, and quickly want to remedy it)
if you have a settings set command for this in your lldbinit file, be sure to change "true" or "false" into an appropriate "yes" or "no" value
llvm-svn: 182323
Name matching was working inconsistently across many places in LLDB. Anyone doing name lookups where you want to look for all types of names should used "eFunctionNameTypeAuto" as the sole name type mask. This will ensure that we get consistent "lookup function by name" results. We had many function calls using as mask like "eFunctionNameTypeBase | eFunctionNameTypeFull | eFunctionNameTypeMethod | eFunctionNameTypeSelector". This was due to the function lookup by name evolving over time, but as it stands today, use eFunctionNameTypeAuto when you want general name lookups. Either ModuleList::FindFunctions() or Module::FindFunctions() will figure out the right kinds of names to lookup and remove the "eFunctionNameTypeAuto" and replace it with the exact subset of what the name can be.
This checkin also changes eFunctionNameTypeAny over to use eFunctionNameTypeAuto to reflect this.
llvm-svn: 182179
Provide a mechanism through which users can disable loading the Python scripts from dSYM files
This relies on a target setting: target.load-script-from-symbol-file which defaults to false ("do NOT load the script")
You need to set it to true before creating your target (or in your lldbinit file if you constantly rely on this feature) to allow the scripts to load
llvm-svn: 181709
<rdar://problem/13594769>
Main changes in this patch include:
- cleanup plug-in interface and use ConstStrings for plug-in names
- Modfiied the BSD Archive plug-in to be able to pick out the correct .o file when .a files contain multiple .o files with the same name by using the timestamp
- Modified SymbolFileDWARFDebugMap to properly verify the timestamp on .o files it loads to ensure we don't load updated .o files and cause problems when debugging
The plug-in interface changes:
Modified the lldb_private::PluginInterface class that all plug-ins inherit from:
Changed:
virtual const char * GetPluginName() = 0;
To:
virtual ConstString GetPluginName() = 0;
Removed:
virtual const char * GetShortPluginName() = 0;
- Fixed up all plug-in to adhere to the new interface and to return lldb_private::ConstString values for the plug-in names.
- Fixed all plug-ins to return simple names with no prefixes. Some plug-ins had prefixes and most ones didn't, so now they all don't have prefixed names, just simple names like "linux", "gdb-remote", etc.
llvm-svn: 181631
This commit changes the ${function.name-with-args} prompt keyword to also tackle structs
Previously, since aggregates have no values, this would show up as foo=(null)
This checkin changes that to instead print foo=(Foo at 0x123) (i.e. typename at address)
There are other potential choices here (summary, one-liner printout of all members, ...) and I would love to hear feedback about better options, if any
llvm-svn: 181462
Most important was a new[] + delete mismatch in ScanFormatDescriptor()
and a couple of possible memory leaks in FileSpec::EnumerateDirectory().
llvm-svn: 181080
<rdar://problem/13723772>
Modified the lldb_private::Thread to work much better with the OperatingSystem plug-ins. Operating system plug-ins can now return have a "core" key/value pair in each thread dictionary for the OperatingSystemPython plug-ins which allows the core threads to be contained with memory threads. It also allows these memory threads to be stepped, resumed, and controlled just as if they were the actual backing threads themselves.
A few things are introduced:
- lldb_private::Thread now has a GetProtocolID() method which returns the thread protocol ID for a given thread. The protocol ID (Thread::GetProtocolID()) is usually the same as the thread id (Thread::GetID()), but it can differ when a memory thread has its own id, but is backed by an actual API thread.
- Cleaned up the Thread::WillResume() code to do the mandatory parts in Thread::ShouldResume(), and let the thread subclasses override the Thread::WillResume() which is now just a notification.
- Cleaned up ClearStackFrames() implementations so that fewer thread subclasses needed to override them
- Changed the POSIXThread class a bit since it overrode Thread::WillResume(). It is doing the wrong thing by calling "Thread::SetResumeState()" on its own, this shouldn't be done by thread subclasses, but the current code might rely on it so I left it in with a TODO comment with an explanation.
llvm-svn: 180886
UInts even if their contents were set as bytes.
This makes expressions using registers work
better, especially with core files.
<rdar://problem/13743427>
llvm-svn: 180810
Enabling LLDB to write to variables that are stored in registers
Previously, this would not work since the Value's Context loses the notion of the data being in a register
We now store an "original" context that comes out of DWARF parsing, and use that context's data when attempting a write
llvm-svn: 180803
std::string
Module::GetSpecificationDescription () const;
This returns the module as "/usr/lib/libfoo.dylib" for normal files (calls "std::string FileSpec::GetPath()" on m_file) but it also might include the object name in case the module is for a .o file in a BSD archive ("/usr/lib/libfoo.a(bar.o)"). Cleaned up necessary logging code to use it.
llvm-svn: 180717
There is a new static ObjectFile function you can call:
size_t
ObjectFile::GetModuleSpecifications (const FileSpec &file,
lldb::offset_t file_offset,
ModuleSpecList &specs)
This will fill in "specs" which the details of all the module specs (file + arch + UUID (if there is one) + object name (for BSD archive objects eventually) + file offset to the object in question).
This helps us when a user specifies a file that contains a single architecture, and also helps us when we are given a debug symbol file (like a dSYM file on MacOSX) that contains one or more architectures and we need to be able to match it up to an existing Module that has no debug info.
llvm-svn: 180224
variables in the ValueObject code:
- Report an error if the variable does not have
a valid address.
- Return the contents of the data to GetData(),
even if the value is constant.
<rdar://problem/13690855>
llvm-svn: 179876
lets a ValueObject's contents be set from raw
data. This has certain limitations (notably,
registers can only be set to data that is as
large as the register) but will be useful for
the new Materializer.
I also exposed this interface through SBValue.
I have added a testcase that exercises various
special cases of SBValue::SetData().
llvm-svn: 179437
Enrico Granata