<rdar://problem/11374963>

When attaching on ARM hosted debuggers we were incorrectly setting the triple to "arm-apple-ios". This was happening because in the post attach code, we would lookup the pr

<rdar://problem/11374963>

When attaching on ARM hosted debuggers we were incorrectly setting the triple to "arm-apple-ios". This was happening because in the post attach code, we would lookup the process info through the platform, and if successful, we would get the architecture of the process. This code uses sysctl() calls, but we can only get the CPU type, not the subtype, so we would get ARM for CPU type and nothing for the cpu subtype, so this would map to "arm-apple-ios". I fixed the code to get the cpu subtype from "hw.cpusubtype" which is what we really want for ARM, and not the architecture is already correct. "add-dsym" then works like a charm. I also improved the command output when the architecture changes to show the entire triple instead of just the arch name.

llvm-svn: 163868

show more ...

Fixed a few places where we were doing:

uint32_t size = ThreadList.GetSize();
for (i=0; i < size; ++i)

without grabbing the thread list mutex.

llvm-svn: 163541

<rdar://problem/11757916>

Make breakpoint setting by file and line much more efficient by only looking for inlined breakpoint locations if we are setting a breakpoint in anything but a source implem

<rdar://problem/11757916>

Make breakpoint setting by file and line much more efficient by only looking for inlined breakpoint locations if we are setting a breakpoint in anything but a source implementation file. Implementing this complex for a many reasons. Turns out that parsing compile units lazily had some issues with respect to how we need to do things with DWARF in .o files. So the fixes in the checkin for this makes these changes:
- Add a new setting called "target.inline-breakpoint-strategy" which can be set to "never", "always", or "headers". "never" will never try and set any inlined breakpoints (fastest). "always" always looks for inlined breakpoint locations (slowest, but most accurate). "headers", which is the default setting, will only look for inlined breakpoint locations if the breakpoint is set in what are consudered to be header files, which is realy defined as "not in an implementation source file".
- modify the breakpoint setting by file and line to check the current "target.inline-breakpoint-strategy" setting and act accordingly
- Modify compile units to be able to get their language and other info lazily. This allows us to create compile units from the debug map and not have to fill all of the details in, and then lazily discover this information as we go on debuggging. This is needed to avoid parsing all .o files when setting breakpoints in implementation only files (no inlines). Otherwise we would need to parse the .o file, the object file (mach-o in our case) and the symbol file (DWARF in the object file) just to see what the compile unit was.
- modify the "SymbolFileDWARFDebugMap" to subclass lldb_private::Module so that the virtual "GetObjectFile()" and "GetSymbolVendor()" functions can be intercepted when the .o file contenst are later lazilly needed. Prior to this fix, when we first instantiated the "SymbolFileDWARFDebugMap" class, we would also make modules, object files and symbol files for every .o file in the debug map because we needed to fix up the sections in the .o files with information that is in the executable debug map. Now we lazily do this in the DebugMapModule::GetObjectFile()

Cleaned up header includes a bit as well.

llvm-svn: 162860

show more ...

Reimplemented the code that backed the "settings" in lldb. There were many issues with the previous implementation:
- no setting auto completion
- very manual and error prone way of getting/setting v

Reimplemented the code that backed the "settings" in lldb. There were many issues with the previous implementation:
- no setting auto completion
- very manual and error prone way of getting/setting variables
- tons of code duplication
- useless instance names for processes, threads

Now settings can easily be defined like option values. The new settings makes use of the "OptionValue" classes so we can re-use the option value code that we use to set settings in command options. No more instances, just "does the right thing".

llvm-svn: 162366

show more ...

Add an option to "process continue" to ignore the next <N> crossings of the breakpoint under
the currently selected thread.

<rdar://problem/10458225>

llvm-svn: 161723

Use the file completer for "process launch" arguments.
<rdar://problem/11274012>

llvm-svn: 161704

Added an lldb_private & equivalent SB API to send an AsyncInterrupt to the event loop.
Convert from calling Halt in the lldb Driver.cpp's input reader's sigint handler to sending this AsyncInterrupt

Added an lldb_private & equivalent SB API to send an AsyncInterrupt to the event loop.
Convert from calling Halt in the lldb Driver.cpp's input reader's sigint handler to sending this AsyncInterrupt so it can be handled in the
event loop.
If you are attaching and get an async interrupt, abort the attach attempt.
Also remember to destroy the process if get interrupted while attaching.
Getting this to work also required handing the eBroadcastBitInterrupt in a few more places in Process WaitForEvent & friends.

<rdar://problem/10792425>

llvm-svn: 160903

show more ...

Add "vAttachOrWait" to debugserver, so you can implement "attach to the process if it exists OR wait for it" without race conditions. Use that in lldb.

llvm-svn: 160578

Make raw & parsed commands subclasses of CommandObject rather than having the raw version implement an
Execute which was never going to get run and another ExecuteRawCommandString. Took the knowled

Make raw & parsed commands subclasses of CommandObject rather than having the raw version implement an
Execute which was never going to get run and another ExecuteRawCommandString. Took the knowledge of how
to prepare raw & parsed commands out of CommandInterpreter and put it in CommandObject where it belongs.

Also took all the cases where there were the subcommands of Multiword commands declared in the .h file for
the overall command and moved them into the .cpp file.

Made the CommandObject flags work for raw as well as parsed commands.

Made "expr" use the flags so that it requires you to be paused to run "expr".

llvm-svn: 158235

show more ...

Fix a typo for 'waitfor' option help wording.

llvm-svn: 157853

Fixed a missed case in the patch to make
HandleCommand take a LazyBool instead of a bool.

llvm-svn: 157728

rdar://problem/11457634

Supports the use-case scenario of immediately continuing the process once attached.
Add a simple completion test case from "process attach --con" to "process attach --continu

rdar://problem/11457634

Supports the use-case scenario of immediately continuing the process once attached.
Add a simple completion test case from "process attach --con" to "process attach --continue ".

llvm-svn: 157361

show more ...

rdar://problem/11140741

For "process attach", make the success criterion as the inferior changes its state to eStateStopped.
Otherwise, mark it as a failure and say so.

llvm-svn: 157036

Patch from Viktor Kutuzov: delete the temporary process we created when "process connect" fails.

llvm-svn: 153790

Add a general mechanism to wait on the debugger for Broadcasters of a given class/event bit set.
Use this to allow the lldb Driver to emit notifications for breakpoint modifications.
<rdar://problem/

Add a general mechanism to wait on the debugger for Broadcasters of a given class/event bit set.
Use this to allow the lldb Driver to emit notifications for breakpoint modifications.
<rdar://problem/10619974>

llvm-svn: 150665

show more ...

First pass at mach-o core file support is in. It currently works for x86_64
user space programs. The core file support is implemented by making a process
plug-in that will dress up the threads and s

First pass at mach-o core file support is in. It currently works for x86_64
user space programs. The core file support is implemented by making a process
plug-in that will dress up the threads and stack frames by using the core file
memory.

Added many default implementations for the lldb_private::Process functions so
that plug-ins like the ProcessMachCore don't need to override many many
functions only to have to return an error.

Added new virtual functions to the ObjectFile class for extracting the frozen
thread states that might be stored in object files. The default implementations
return no thread information, but any platforms that support core files that
contain frozen thread states (like mach-o) can make a module using the core
file and then extract the information. The object files can enumerate the
threads and also provide the register state for each thread. Since each object
file knows how the thread registers are stored, they are responsible for
creating a suitable register context that can be used by the core file threads.

Changed the process CreateInstace callbacks to return a shared pointer and
to also take an "const FileSpec *core_file" parameter to allow for core file
support. This will also allow for lldb_private::Process subclasses to be made
that could load crash logs. This should be possible on darwin where the crash
logs contain all of the stack frames for all of the threads, yet the crash
logs only contain the registers for the crashed thrad. It should also allow
some variables to be viewed for the thread that crashed.

llvm-svn: 150154

show more ...

<rdar://problem/10429064>

Fixed an issue where if we are debugging on a remote platform and set a
platform path for our executable, it was not being honored by the new
launch functions that used the

<rdar://problem/10429064>

Fixed an issue where if we are debugging on a remote platform and set a
platform path for our executable, it was not being honored by the new
launch functions that used the ProcessLaunchInfo.

llvm-svn: 145371

show more ...

CommandObjectProcess was recently changed to automatically use the platform
to launch a process for debugging. Since this isn't supported on all platforms,
we need to do what we used to do if this is

CommandObjectProcess was recently changed to automatically use the platform
to launch a process for debugging. Since this isn't supported on all platforms,
we need to do what we used to do if this isn't supported. I added:

bool
Platform::CanDebugProcess ();

This will get checked before trying to launch a process for debugging and then
fall back to launching the process through the current host debugger. This
should solve the issue for linux and keep the platform code clean.

Centralized logging code for logging errors, warnings and logs when reporting
things for modules or symbol files. Both lldb_private::Module and
lldb_private::SymbolFile now have the following member functions:

void
LogMessage (Log *log, const char *format, ...);

void
ReportWarning (const char *format, ...);

void
ReportError (const char *format, ...);

These will all output the module name and object (if any) such as:

"error: lldb.so ...."
"warning: my_archive.a(foo.o) ...."

This will keep the output consistent and stop a lot of logging calls from
having to try and output all of the information that uniquely identifies
a module or symbol file. Many places in the code were grabbing the path to the
object file manually and if the module represented a .o file in an archive, we
would see log messages like:

error: foo.a - some error happened

llvm-svn: 145219

show more ...

Save the arguments for a process launch in the target.run-args so they can
easily be used in the next run.

llvm-svn: 145051

Use a pseudoterminal for local processes if no STDIO redirection or other
file actions have been specified.

llvm-svn: 144922

Fixed an issue with the pthread_setspecific() where we weren't NULL-ing out
the thread specific data and were destroying the thread specfic data more
than once.

Also added the ability to ask a lldb:

Fixed an issue with the pthread_setspecific() where we weren't NULL-ing out
the thread specific data and were destroying the thread specfic data more
than once.

Also added the ability to ask a lldb::StateType if it is stopped with an
additional paramter of "must_exist" which means that the state must be a
stopped state for a process that still exists. This means that eStateExited
and eStateUnloaded will no longer return true if "must_exist" is set to true.

llvm-svn: 144875

show more ...

Added a new class to Process.h: ProcessAttachInfo. This class contains enough
info for us to attach by pid, or by name and will also allow us to eventually
do a lot more powerful attaches. If you loo

Added a new class to Process.h: ProcessAttachInfo. This class contains enough
info for us to attach by pid, or by name and will also allow us to eventually
do a lot more powerful attaches. If you look at the options for the "platform
process list" command, there are many options which we should be able to
specify. This will allow us to do things like "attach to a process named 'tcsh'
that has a parent process ID of 123", or "attach to a process named 'x' which
has an effective user ID of 345".

I finished up the --shell implementation so that it can be used without the
--tty option in "process launch". The "--shell" option now can take an
optional argument which is the path to the shell to use (or a partial name
like "sh" which we will find using the current PATH environment variable).

Modified the Process::Attach to use the new ProcessAttachInfo as the sole
argument and centralized a lot of code that was in the "process attach"
Execute function so that everyone can take advantage of the powerful new
attach functionality.

llvm-svn: 144615

show more ...

Added the ability to run a process in a shell on MacOSX currently when using
the --tty option. So you can now get shell expansion and file redirection:

(lldb) process launch --tty --shell -- *.jpg <

Added the ability to run a process in a shell on MacOSX currently when using
the --tty option. So you can now get shell expansion and file redirection:

(lldb) process launch --tty --shell -- *.jpg < in.txt > out.txt

Again, the "--tty" is mandatory for now until we hook this up to other
functions. The shell is also currently hard coded to "/bin/bash" and not the
"SHELL" variable. "/bin/tcsh" was causing problems which I need to dig into.

llvm-svn: 144443

show more ...

Moved many of the "settings" that used to be in "target.process.*" to just
be in the target. All of the environment, args, stdin/out/err files, etc have
all been moved. Also re-enabled the ability to

Moved many of the "settings" that used to be in "target.process.*" to just
be in the target. All of the environment, args, stdin/out/err files, etc have
all been moved. Also re-enabled the ability to launch a process in a separate
terminal on MacOSX.

llvm-svn: 144061

show more ...

Modified all Process::Launch() calls to use a ProcessLaunchInfo structure
on internal only (public API hasn't changed) to simplify the paramter list
to the launch calls down into just one argument. A

Modified all Process::Launch() calls to use a ProcessLaunchInfo structure
on internal only (public API hasn't changed) to simplify the paramter list
to the launch calls down into just one argument. Also all of the argument,
envronment and stdio things are now handled in a much more centralized fashion.

llvm-svn: 143656

show more ...