CommandInterpreter's execution context AFTER the process had started running
and before it initially stopped. Also fixed one test case that was implicitly
using this (and an abuse of the async mode) to accidentally succeed.
<rdar://problem/16814726>
llvm-svn: 226528
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
This hooks up the changes necessary to set the trap flag on the
CPU and properly manage the process and thread's resume state
and private state so that the ThreadPlan does its thing.
Stepping still doesn't work as of this change, because there are
some issues with stack frames where it doesn't update the thread's
frame list correctly when it breaks inside of a function, but
I will try to fix that separately.
llvm-svn: 226221
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 hit count is not updated.
Also, keep the hit count for the breakpoint in the breakpoint. We were
using just the sum of the location's hit counts, but that was wrong since if a shared library is
unloaded, and the location goes away, the breakpoint hit count should not suddenly drop
by the number of hits there were on that location.
llvm-svn: 226074
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
While there is quite a bit of potential for mishaps due to tagged pointers, and after quite some internal discussion, this seems a saner behavior given how "po" stands for "print OBJECT". The argument being that we should make at least some sensible attempt to print the thing the user passed as-if it was an object
Fixes rdar://19423124
llvm-svn: 226062
These fix various issues with path handling and disable a few tests
which use features of LLVM which are not yet supported on Windows.
llvm-svn: 226042
BUILD_SHARED_LIBS=TRUE currently isn't working for Linux x86_64
This patch fixes the link errors and also some runtime errors
Test Plan:
CC=clang CXX=clang++ cmake -GNinja -DBUILD_SHARED_LIBS=TRUE -DCMAKE_LINKER=ld.gold -DCMAKE_BUILD_TYPE=Debug ../../llvm
ninja
ninja check-lldb
llvm-svn: 226039
We now verify that the debugger's input file is a valid terminal file descriptor before allowing the "gui" command to try to run.
Xcode would crash if you typed "gui" at the command line prior to this fix.
<rdar://problem/18775851>
llvm-svn: 226027
saved/restored across a mid-function epilogue. We ignore
repeated push/pops of a register so once we saw one 'pop %rbp',
we'd ignore it the second time we saw it.
<rdar://problem/19417410>
llvm-svn: 225853
This is currently controlled by a setting:
(lldb) settings set target.process.python-os-plugin-path <path>
Or clearing it with:
(lldb) settings clear target.process.python-os-plugin-path
The process will now reload the OperatingSystem plug-in.
This was implemented by:
- adding the ability to set a notify callback for when an option value is changed
- added the ability for the process plug-in to load the operating system plug-in on the fly
- fixed bugs in the Process::GetStatus() so all threads are displayed if their thread IDs are larger than 32 bits
- adding a callback in ProcessProperties to tell when the "python-os-plugin-path" is changed by the user
- fixing a crasher in ProcessMachCore that happens when updating the thread list when the OS plugin is reloaded
llvm-svn: 225831
it will do the right thing on x86 routines with a mid-function
epilogue sequence (where the unwind rules need to be reinstalled
after the epilogue has completed).
<rdar://problem/19417410>
llvm-svn: 225773
which will verify if the eh_frame instructions include details about
the prologue or not. Both clang and gcc include prologue instructions
but there's no requirement for them to do so -- and I'm sure we'll
have to interoperate with a compiler that doesn't generate prologue
info at some point.
I don't have any compilers that omit the prologue instructions so the
testing was of the "makre sure augmented unwind info is still created".
With an eh_frame without prologue, this code should reject the
augmentation scheme altogether and we should fall back to using assembly
instruction profiling.
llvm-svn: 225771
step through the complete function looking for any epilogue
instructions. If we find an epilogue sequence, re-instate
the correct unwind instructions if there is more code past
that epilogue -- this will correctly handle an x86 function
with multiple epilogues in it.
NB there is still a bug with the "eh_frame augmented"
UnwindPlans and mid-function epilogues. Looking at that next.
<rdar://problem/18863406>
llvm-svn: 225770
This will allow, in a subsequent patch, the addition of a global
setting that allows the user to specify a single character that
LLDB will recognize as an escape character when processing arg
strings to accomodate differences in Windows/non-Windows path
handling.
Differential Revision: http://reviews.llvm.org/D6887
Reviewed by: Jim Ingham
llvm-svn: 225694
it more generally available.
Add checks to UnwindAssembly_x86::AugmentUnwindPlanFromCallSite() so
that it won't try to augment an UnwindPlan that already describes
the function epilogue.
Add a test case for backtracing out of _sigtramp on Darwin systems.
This could probably be adapted to test the same thing on linux/bsd but
the function names of sigtramp and kill are probably platform
specific and I'm not sure what they should be.
llvm-svn: 225578
This fixes an issue of running "script" commands via SBDebugger::HandleCommand(...) and SBCommandInterpreter::HandleCommand(...) deadlocking Xcode.
<rdar://problem/18075038>
llvm-svn: 225567
MS ABI guard variables end with @4IA, so this patch teaches the
interpreter about that. Additionally, there was an issue with
TurnGuardLoadIntoZero which was causing some guard uses of a
variable to be missed. This fixes that by calling
Instruction::replaceAllUsesWith() instead of trying to replicate
that function.
llvm-svn: 225547
Variable was being declared as signed, but treated as unsigned at
every point of use.
Patch by Dan Sinclair
Differential Revision: http://reviews.llvm.org/D6897
llvm-svn: 225540
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
This new command will delete user defined regular commands, but not aliases. We still have "command unalias" to remove aliases as they are currently in different buckets. Appropriate error messages are displayed to inform the user when "command unalias" is used on removable user defined commands that points users to the "command delete" command.
Added a test to verify we can remove user defined commands and also verify that "command unalias" fails when used on a user defined command.
<rdar://problem/18248300>
llvm-svn: 225535
Change the default of prefer-dynamic-value to eDynamicDontRunTarget (i.e. enable dynamic values, but do not run code to do so)
Of course, disable this for the test suite, since testing no-dynamic-values is actually valuable
Fixes rdar://17363061
llvm-svn: 225486
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
which registers have been spilled (saved to the stack) - and
if we see that same register being saved to the stack again,
don't record that, it's something specific to this stack frame.
I found a code sequence for i386 where clang did a push %esi
and then later in the function it did movl %esi, -0x7c(%ebp)
and that second save of a scratch value overrode the original
push location.
<rdar://problem/19171178>
llvm-svn: 225431
Jim Ingham