The "run" and "r" aliases were for gdb compatability, so make then do what GDB does by default: launch in a shell.
For those that don't want launching with a shell by default, add the following to your ~/.lldbinit file:
command unalias run
command unalias r
command alias r process launch --
command alias run process launch --
llvm-svn: 157028
boxed expressions returning numbers and strings.
I also added boxed expressions to our testcases, and
enabled boxed expressions when libarclite is linked into
the inferior.
llvm-svn: 157026
path on rerunning, evict the old module from the target module list, inform the breakpoints
about this so they can do something intelligent as well.
rdar://problem/11273043
llvm-svn: 157008
TestBackticksWithoutATarget.BackticksWithNoTargetTestCase was calling
GetDummyTarget() when executing for x86_64. When performing session
tearDown, it would get destroyed (and everything would be invalid (arch,
etc).
Then the test would run for i386. The dummy target wasn't being
reinitialized and was invalid. lldb complained that 'current process state
is unsuitable for expression parsing'.
llvm-svn: 156994
various other syntactic sugar work. Lambdas do
not due to some problems relocating code containing
lambdas. Rvalue references work when returned from
expressions, but need more testing.
llvm-svn: 156948
Make sure our debugger STDIN read thread shuts down quickly when we are done with it. We had a case where the owner of the file handle was not closing it and caused spins.
llvm-svn: 156879
Add "--name" option to "image lookup" that will search both functions and symbols.
Also made all of the output from any of the "image lookup" commands be the same regardless of the lookup type (function name, symbol name, func or symbol, file and line, address, etc). The --verbose or -v option also will expand the results as needed and display things so they look the same.
llvm-svn: 156835
that dynamically discovers remote register context information.
o GDBRemoteRegisterContext.h:
Change the prototype of HardcodeARMRegisters() to take a boolean flag, which now becomes
void
HardcodeARMRegisters(bool from_scratch);
o GDBRemoteRegisterContext.cpp:
HardcodeARMRegisters() now checks the from_scratch flag and decides whether to add composite registers to the already
existing primordial registers based on a table called g_composites which describes the composite registers.
o ProcessGDBRemote.cpp:
Modify the logic of ProcessGDBRemote::BuildDynamicRegisterInfo() to call m_register_info.HardcodeARMRegisters()
with the newly introduced 'bool from_scrach' flag.
rdar://problem/10652076
llvm-svn: 156773
"lldb -a i386" doesn't set the calculator mode correctly if run on a 64 bit system.
The previous logic always used the current host architecture, not the default architecture. The default arch gets set into a static varaible in lldb_private::Target when an arch is set from the command line:
lldb -a i386
We now use the default arch correctly.
llvm-svn: 156680
Also changed the defaults for SBThread::Step* to not delete extant plans.
Also added some test cases to test more complex stepping scenarios.
llvm-svn: 156667
Fixed the DisassemblerLLVMC disassembler to parse more efficiently instead of parsing opcodes over and over. The InstructionLLVMC class now only reads the opcode in the InstructionLLVMC::Decode function. This can be done very efficiently for ARM and architectures that have fixed opcode sizes. For x64 it still calls the disassembler to get the byte size.
Moved the lldb_private::Instruction::Dump(...) function up into the lldb_private::Instruction class and it now uses the function that gets the mnemonic, operandes and comments so that all disassembly is using the same code.
Added StreamString::FillLastLineToColumn() to allow filling a line up to a column with a character (which is used by the lldb_private::Instruction::Dump(...) function).
Modified the Opcode::GetData() fucntion to "do the right thing" for thumb instructions.
llvm-svn: 156532
the controlling plans so that they don't lose control.
Also change "ThreadPlanStepThrough" to take the return StackID for its backstop breakpoint as an argument
to the constructor rather than having it try to figure it out itself, since it might get it wrong whereas
the caller always knows where it is coming from.
rdar://problem/11402287
llvm-svn: 156529
On Lion, because the rights initially doesn't exist in /etc/authorization, if an admin user logs in and uses lldb within the first 5 minutes, it is possible to do AuthorizationCopyRights on LaunchUsingXPCRightName and get the rights back. As another security measure, we make sure that the LaunchUsingXPCRightName rights actually exists.
Removed Xcode as the user of the XPC service to shrink the security surface area.
llvm-svn: 156424
We make sure that if the user cancels out of the authentication dialog to add 'com.apple.lldb.LaunchUsingXPC' rights to /etc/authorization, we don't try to do AuthorizationCopyRights.
As well, refactored a bit so that control flow is easier to read for other folks. Added more comments.
llvm-svn: 156423
Fixed the command callback override lookup function so we can now override the "process launch" command (or any other multi-word commands).
llvm-svn: 156368
Switch over to the "*-apple-macosx" for desktop and "*-apple-ios" for iOS triples.
Also make the selection process for auto selecting platforms based off of an arch much better.
llvm-svn: 156354
Correctly specify the LLDB_OPT_SET's that the 'shlib' command option belongs to by using a newly added macro like this:
#define LLDB_OPT_NOT_10 ( LLDB_OPT_SET_FROM(1, 10) & ~LLDB_OPT_SET_10 )
rdar://problem/11393864
llvm-svn: 156337
No one was using it and Locker(pthread_mutex_t *) immediately asserts for
pthread_mutex_t's that don't come from a Mutex anyway. Rather than try to make
that work, we should maintain the Mutex abstraction and not pass around the
platform implementation...
Make Mutex::Locker::Lock take a Mutex & or a Mutex *, and remove the constructor
taking a pthread_mutex_t *. You no longer need to call Mutex::GetMutex to pass
your mutex to a Locker (you can't in fact, since I made it private.)
llvm-svn: 156221
Rework the Host.cpp::ThreadNameAccessor to use ThreadSafeSTLMap - we've got it so we might as well use it. Also works around a problem with the
Mutex::Locker class raising fallacious asserts in debug mode when used with pthread_mutex_t's that weren't backed by Mutex objects.
llvm-svn: 156193
us of its architecture, use that to set the Target's arch if it
doesn't already have one set.
In Process::CompleteAttach(), if the Target has a valid arch make
sure that the Platform we pick up is compatible with that arch; if
not, find a Platform that is compatible. Don't let the the default
platform override the Target's arch.
<rdar://problem/11185420>
llvm-svn: 156116
should be MasterPlans that want to stay on the plan stack. So make all plans NOT
MasterPlans by default and then have the SB API's and the CommandObjectThread step
commands set this explicitly.
Also added a "clean up" phase to the Thread::ShouldStop so that if plans get stranded
on the stack, we can remove them. This is done by adding an IsPlanStale method to the
thread plans, and if the plan can know that it is no longer relevant, it returns true,
and the plan and its sub-plans will get discarded.
llvm-svn: 156101
since we now run the condition in the StopInfoBreakpoint's PerformAction, and don't need
to refer it to another "continue". Actually, we haven't needed to do this for a year or
so, I just hadn't gotten around to deleting the dead wood.
llvm-svn: 155967
Just call SBDebugger::SetTerminalWidth on the driver's SBDebugger, which does the same job, but no locks.
Also add the value checking to SetTerminalWidth you get with SetInternalVariable(..., "term-width", ...).
rdar://problem/11310563
llvm-svn: 155665
ones, to its own constant pool. This reflects the fact
that the LLVM code generators for different targets move
floats to their constant pools under varying conditions,
and the JIT cannot (yet) be relied upon to relocate references to
its constant pool correctly.
llvm-svn: 155660
<rdar://problem/11285931>
Use the DWARRF end prologue markers when trying to skip prologue instructions instead of blindly using the second line table address entry.
llvm-svn: 155600
ObjCPlusPlus as Objective-C classes. Really the
compiler should say they have Objective-C runtime
class, but we should be a little more resilient
(we were refusing to find ivars in those classes
before).
Also added a test case.
llvm-svn: 155515
Fixed an issue that would happen when using debug map with DWARF in the .o files where we wouldn't ever track down the actual definition for a type when things were in namespaces. We now serialize the decl context information into an intermediate format which allows us to track down the correct definition for a type regardless of which DWARF symbol file it comes from. We do this by creating a "DWARFDeclContext" object that contains the DW_TAG + name for each item in a decl context which we can then use to veto potential accelerator table matches. For example, the accelerator tables store the basename of the type, so if you have "std::vector<int>", we would end up with an accelerator table entry for the type that contained "vector<int>", which we would then search for using a DWARFDeclContext object that contained:
[0] DW_TAG_class_type "vector<int>"
[1] DW_TAG_namespace "std"
This is currently used to track down forward declarations for things like "class a:🅱️:Foo;".
llvm-svn: 155488
doesn't return a result. If that expression can't
be run in the current context (for example, if it
uses a function and there is no running process)
then we used to try to destroy the nonexistent
result variable. We now only destroy the result
variable if we actually made one.
llvm-svn: 155455
This worked correctly for 64-bit targets, but broke down data formatters in i386 mode. The formatters would try to read pointers out of the frozen-dried objects,
but were unable to do so because they would try fetching 8 bytes from a DataExtractor with only 4 bytes in it. This patch fixes the issue by always making the pointer-size
for a DataExtractor match the target setting.
llvm-svn: 155418
Fixed an issue where we get NULL compile units back from the symbol vendor. We need symbol vendors to be able to quickly give an estimate of the compile units that they have without having to fully vette them first, so anyone getting compile units from a module should be able to deal with a NULL compile unit being returned for a given index.
llvm-svn: 155398
ask to continue that should short-circuit the thread plans for that thread. Also add a bit more explanation for
how this machinery is supposed to work.
Also pass eExecutionPolicyOnlyWhenNeeded, not eExecutionPolicyAlways when evaluating the expression for breakpoint
conditions.
llvm-svn: 155236
class AnalysisResolver;
And we will look for it everywhere and find many many matches, but the decl context of those matching DIEs is "clang::AnalysisResolver", so we never match anything, yet we pull in waaayyy too much DWARF in the process.
To enable this logging enable the "lookups" category in the "dwarf" log channel:
(lldb) log enable dwarf lookups
llvm-svn: 155233
Fixed an issue where iOS debugging would trust the first file it found in the SDK regardless of the UUID not matching. Now we actually get smart and can find modules in ANY of the installed SDKs and remember which SDK is our fallback SDK.
llvm-svn: 155184
Also enabled PlatformRemoteiOS to select an SDK using the build number in case you have mutliple 5.0 SDKs installed:
(lldb) platform select remote-ios --build 11C123
llvm-svn: 154978
Error
Host::RunShellCommand (const char *command,
const char *working_dir,
int *status_ptr,
int *signo_ptr,
std::string *command_output_ptr,
uint32_t timeout_sec);
This will allow us to use this functionality in the host lldb_private::Platform, and also use it in our lldb-platform binary. It leverages the existing code in Host::LaunchProcess and ProcessLaunchInfo.
llvm-svn: 154730
Hello everyone,
please find the attached patch for TOT and lldb-platform-work branch, which provides the following changes:
- fixed a crash in the ProcessPOSIX constructor when an executable module object is not yet created.
- added support for the multi instanciated FreeBSD platform objects (the local host and remote as example).
- enabled the remote gdb plugin on FreeBSD.
llvm-svn: 154724
Enable logging the packet history when registers fail to read due to not getting the sequence mutex if "--verbose" is enabled on the log channel for the "gdb-remote" log category.
This will help us track down some issues.
llvm-svn: 154704
The less locks there are, the better. I removed the thread ID mutex and now just shared the m_thread_list's mutex to make sure we don't deadlock due to lock inversion.
llvm-svn: 154652
the debug information individual Decls came from.
We've had a metadata infrastructure for a while,
which was intended to solve a problem we've since
dealt with in a different way. (It was meant to
keep track of which definition of an Objective-C
class was the "true" definition, but we now find
it by searching the symbols for the class symbol.)
The metadata is attached to the ExternalASTSource,
which means it has a one-to-one correspondence with
AST contexts.
I've repurposed the metadata infrastructure to
hold the object file and DIE offset for the DWARF
information corresponding to a Decl. There are
methods in ClangASTContext that get and set this
metadata, and the ClangASTImporter is capable of
tracking down the metadata for Decls that have been
copied out of the debug information into the
parser's AST context without using any additional
memory.
To see the metadata, you just have to enable the
expression log:
-
(lldb) log enable lldb expr
-
and watch the import messages. The high 32 bits
of the metadata indicate the index of the object
file in its containing DWARFDebugMap; I have also
added a log which you can use to track that mapping:
-
(lldb) log enable dwarf map
-
This adds 64 bits per Decl, which in my testing
hasn't turned out to be very much (debugging Clang
produces around 6500 Decls in my tests). To track
how much data is being consumed, I've also added a
global variable g_TotalSizeOfMetadata which tracks
the total number of Decls that have metadata in all
active AST contexts.
Right now this metadata is enormously useful for
tracking down bugs in the debug info parser. In the
future I also want to use this information to provide
more intelligent error messages instead of printing
empty source lines wherever Clang refers to the
location where something is defined.
llvm-svn: 154634
FunctionDecls into classes if it looked up a
method in a different DWARF context than the
one where it found the parent class's definition.
The symptom of this was, for a method A::B(),
1) LLDB finds A in context 1, creating a
CXXRecordDecl for A and marking it as needing
completion
2) LLDB looks up B in context 2, finds that its
parent A already has a CXXRecordDecl, but can't
find a CXXMethodDecl for B
3) Not finding a CXXMethodDecl for B, LLDB doesn't
set the flag indicating that B was resolved
4) Because the flag wasn't set, LLDB's fallthrough
code creates a FunctionDecl for B and sticks it
in the DeclContext -- in this case, A.
5) Clang crashes on finding a FunctionDecl inside a
CXXRecordDecl.
llvm-svn: 154627
for packet confirmation.
Also added a bit more logging.
Also, unlock the writer end of the run lock in Process.cpp on our way out of the private state
thread so that the Process can shut down cleanly.
<rdar://problem/11228538>
llvm-svn: 154601
Cleaned up the Mutex::Locker and the ReadWriteLock classes a bit.
Also cleaned up the GDBRemoteCommunication class to not have so many packet functions. Used the "NoLock" versions of send/receive packet functions when possible for a bit of performance.
llvm-svn: 154458
QListThreadsInStopReply
This GDB remote query command can enable added a "threads" key/value pair to all stop reply packets so that we always get a list of all threads in each stop reply packet. It increases performance if enabled (the reply to the "QListThreadsInStopReply" is "OK") by saving us from sending to command/reply pairs (the "qfThreadInfo" and "qsThreadInfo" packets), and also helps us keep the current process state up to date.
llvm-svn: 154380
The next step is to have our stop reply packets send the thread list in the actual stop reply packet to avoid a 2 packet overhead of sending the qfThreadInfo + response and qfThreadInfo + response.
llvm-svn: 154376
1) Start the PrivateStateThread stopped, and then in
StartPrivateStateThread, make the private state thread and then
resume it before we say the thread is created. That way we know it is
listening for events by the time we get out of
StartPrivateStateThread.
2) Backstop running a thread plan when calling Process::RunThreadPlan
on the private state thread with a ThreadPlanBase so that running the
plan doesn't pass its stop events to whatever plans happen to be above
us on the thread plan stack.
llvm-svn: 154368
The current ProcessGDBRemote function that updates the threads could end up with an empty list if any other thread had the sequence mutex. We now don't clear the thread list when we can't access it, and we also have changed how lldb_private::Process handles the return code from the:
virtual bool
Process::UpdateThreadList (lldb_private::ThreadList &old_thread_list,
lldb_private::ThreadList &new_thread_list) = 0;
A bool is now returned to indicate if the list was actually updated or not and the lldb_private::Process class will only update the stop ID of the validity of the thread list if "true" is returned.
The ProcessGDBRemote also got an extra assertion that will hopefully assert when running debug builds so we can find the source of this issue.
llvm-svn: 154365
Work around a deadlocking issue where "SBDebugger::MemoryPressureDetected ()" is being called and is causing a deadlock. We now just try and get the lock when trying to trim down the unique modules so we don't deadlock debugger GUI programs until we can find the root cause.
llvm-svn: 154339
nanoseconds in 32-bit expression would cause pthread_cond_timedwait
to time out immediately. Add explicit casts to the TimeValue::TimeValue
ctor that takes a struct timeval and change the NanoSecsPerSec etc
constants defined in TimeValue to be uint64_t so any other calculations
involving these should be promoted to 64-bit even when lldb is built
for 32-bit.
<rdar://problem/11204073>, <rdar://problem/11179821>, <rdar://problem/11194705>.
llvm-svn: 154250
spin up a temporary "private state thread" that will respond to events from the lower level process plugins. This check-in should work to do
that, but it is still buggy. However, if you don't call functions on the private state thread, these changes make no difference.
This patch also moves the code in the AppleObjCRuntime step-through-trampoline handler that might call functions (in the case where the debug
server doesn't support the memory allocate/deallocate packet) out to a safe place to do that call.
llvm-svn: 154230
Also test for the process to be stopped when many SBValue API calls are made to make sure it is safe to evaluate values, children of values and much more.
llvm-svn: 154160
This abstracts read/write locks on the current host system. It is currently backed by pthread_rwlock_t objects so it should work on all unix systems.
We also need a way to control multi-threaded access to the process through the public API when it is running. For example it isn't a good idea to try and get stack frames while the process is running. To implement this, the lldb_private::Process class now contains a ReadWriteLock member variable named m_run_lock which is used to control the public process state. The public process state represents the state of the process as the client knows it. The private is used to control the actual current process state. So the public state of the process can be stopped, yet the private state can be running when evaluating an expression for example.
Adding the read/write lock where readers are clients that want the process to stay stopped, and writers are clients that run the process, allows us to accurately control multi-threaded access to the process.
Switched the SBThread and SBFrame over to us shared pointers to the ExecutionContextRef class instead of making their own class to track this. This fixed an issue with assigning on SBFrame to another and will also centralize the code that tracks weak references to execution context objects into one location.
llvm-svn: 154099
correctly if the setter/getter were not present
in the debug information. The fixes are as follows:
- We not only look for the method by its full name,
but also look for automatically-generated methods
when searching for a selector in an Objective-C
interface. This is necessary to find accessors.
- Extract the getter and setter name from the
DW_TAG_APPLE_Property declaration in the DWARF
if they are present; generate them if not.
llvm-svn: 154067
Found an issue where we might still have shared pointer references to lldb_private::Thread objects where the object itself is not valid and has been removed from the Process. When a thread is removed from a process, it will call Thread::DestroyThread() which well set a boolean member variable which is exposed now via:
bool
Thread::IsValid() const;
We then check the thread validity before handing out a shared pointer.
llvm-svn: 154048
Fixed an issue where there were more than one way to get a CompileUnitSP created when using SymbolFileDWARF with SymbolFileDWARFDebugMap. This led to an assertion that would fire under certain conditions. Now there is only one way to create the compile unit and it will "do the right thing".
llvm-svn: 153908
Greg Clayton