llvm-svn: 164753

Don't leak mach ports when calling "mach_thread_self()".

llvm-svn: 164152

The attached patch adds support for debugging 32-bit processes when running a 64-bit lldb on an x86_64 Linux system.
 
Making this work required two basic changes:
 
1)      Getting lldb to report that it could debug 32-bit processes
2)      Changing an assumption about how ptrace works when debugging cross-platform
 
For the first change, I took a conservative approach and only enabled this for x86_64 Linux platforms.  It may be that the change I made in Host.cpp could be extended to other 64-bit Linux platforms, but I'm not familiar enough with the other platforms to know for sure.
 
For the second change, the Linux ProcessMonitor class was assuming that ptrace(PTRACE_[PEEK|POKE]DATA...) would read/write a "word" based on the child process word size.  However, the ptrace documentation says that the "word" size read or written is "determined by the OS variant."  I verified experimentally that when ptracing a 32-bit child from a 64-bit parent a 64-bit word is read or written.

llvm-svn: 163398

llvm-svn: 160979

Fixed ePathTypePythonDir for Linux and FreeBSD (at least). This works for non-installed compilations. I will test further.

llvm-svn: 160963

Fixes the case where we created a dummy target, deleted it, and then tried to evaluate an expression with no target.

llvm-svn: 157110

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

Fixed the test suite not working on i386 due to recent default arch detection changes.

llvm-svn: 156796

"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

Restore expressions with no target.

llvm-svn: 156669

Fix a think in Mutex::Locker::Locker(pthread_mutex_t *)  Really should lock the mutex handed in, not the m_mutex_ptr that you've set to NULL...
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

Added a new host function that allows us to run shell command and get the output from them along with the status and signal:

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

We sometimes need to be able to call functions (via Process::RunThreadPlan) from code run on the private state thread.  To do that we have to 
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

Added ability to debug root processes on OS X. This uses XPC service that is available on Lion and above only.

llvm-svn: 151419

Tracking modules down when you have a UUID and a path has been improved.

DynamicLoaderDarwinKernel no longer parses mach-o load commands and it
now uses the memory based modules now that we can load modules from memory.

Added a target setting named "target.exec-search-paths" which can be used
to supply a list of directories to use when trying to look for executables.
This allows one or more directories to be used when searching for modules
that may not exist in the SDK/PDK. The target automatically adds the directory
for the main executable to this list so this should help us in tracking down
shared libraries and other binaries. 

llvm-svn: 150426

so that we don't have "fprintf (stderr, ...)" calls sprinkled everywhere.
Changed all needed locations over to using this.

For non-darwin, we log to stderr only. On darwin, we log to stderr _and_
to ASL (Apple System Log facility). This will allow GUI apps to have a place
for these error and warning messages to go, and also allows the command line
apps to log directly to the terminal.

llvm-svn: 147596

monitoring on darwin in the host layer.

llvm-svn: 144918

After recent changes we weren't reaping child processes resulting in many
zombie processes. 

This was fixed by adding more settings to the ProcessLaunchOptions class
that allow clients to specify a callback function and baton to be notified
when their process dies. If one is not supplied a default callback will be
used that "does the right thing". 

Cleaned up a race condition in the ProcessGDBRemote class that would attempt
to monitor when debugserver died. 

Added an extra boolean to the process monitor callbacks that indicate if a
process exited or not. If your process exited with a zero exit status and no
signal, both items could be zero.

Modified the process monitor functions to not require a callback function
in order to reap the child process.

llvm-svn: 144780

llvm-svn: 143774

llvm-svn: 143703

llvm-svn: 143679

- If you download and build the sources in the Xcode project, x86_64 builds
  by default using the "llvm.zip" checkpointed LLVM.
- If you delete the "lldb/llvm.zip" and the "lldb/llvm" folder, and build the
  Xcode project will download the right LLVM sources and build them from 
  scratch
- If you have a "lldb/llvm" folder already that contains a "lldb/llvm/lib"
  directory, we will use the sources you have placed in the LLDB directory.
  
Python can now be disabled for platforms that don't support it. 

Changed the way the libllvmclang.a files get used. They now all get built into
arch specific directories and never get merged into universal binaries as this
was causing issues where you would have to go and delete the file if you wanted
to build an extra architecture slice.

llvm-svn: 143678

llvm-svn: 143613

for it, so that people who want to use LLDB as a
calculator can run simple expressions without needing
a target or process.

llvm-svn: 143147

llvm-svn: 136951

I did not take the patch for ClangExpressionParser.cpp since there was a
recent change by Peter for the same line.  Feel free to disagree. :-)

Reference:
----------------------------------------------------------------------
r136580 | pcc | 2011-07-30 15:42:24 -0700 (Sat, 30 Jul 2011) | 3 lines

Add reloc arg to standard JIT createJIT()

Fixes non-__APPLE__ build.  Patch by Matt Johnson!
----------------------------------------------------------------------

Also, I ignore the part of the patch to remove the RegisterContextDarwin*.h/.cpp.

llvm-svn: 136720

Used hand merge to apply the diffs.  I did not apply the diffs for FormatManager.h and
the diffs for memberwise initialization for ValueObject.cpp because they changed since.
I will ask my colleague to apply them later.

llvm-svn: 135508

breakage due to its presence.

Patch by Marco Minutoli <mminutoli@gmail.com>

llvm-svn: 131303

the CommandInterpreter where it was always being used.

Make sure that Modules can track their object file offsets correctly to
allow opening of sub object files (like the "__commpage" on darwin).

Modified the Platforms to be able to launch processes. The first part of this
move is the platform soon will become the entity that launches your program
and when it does, it uses a new ProcessLaunchInfo class which encapsulates
all process launching settings. This simplifies the internal APIs needed for
launching. I want to slowly phase out process launching from the process
classes, so for now we can still launch just as we used to, but eventually
the platform is the object that should do the launching.

Modified the Host::LaunchProcess in the MacOSX Host.mm to correctly be able
to launch processes with all of the new eLaunchFlag settings. Modified any
code that was manually launching processes to use the Host::LaunchProcess
functions.

Fixed an issue where lldb_private::Args had implicitly defined copy 
constructors that could do the wrong thing. This has now been fixed by adding
an appropriate copy constructor and assignment operator.

Make sure we don't add empty ModuleSP entries to a module list.

Fixed the commpage module creation on MacOSX, but we still need to train
the MacOSX dynamic loader to not get rid of it when it doesn't have an entry
in the all image infos.

Abstracted many more calls from in ProcessGDBRemote down into the 
GDBRemoteCommunicationClient subclass to make the classes cleaner and more
efficient.

Fixed the default iOS ARM register context to be correct and also added support
for targets that don't support the qThreadStopInfo packet by selecting the
current thread (only if needed) and then sending a stop reply packet.

Debugserver can now start up with a --unix-socket (-u for short) and can 
then bind to port zero and send the port it bound to to a listening process
on the other end. This allows the GDB remote platform to spawn new GDB server
instances (debugserver) to allow platform debugging.

llvm-svn: 129351

Something changed in commit r129112 where a few standard headers vanished from
the include chain when building on Linux.  Fix up by including limits.h for
INT_MAX and PATH_MAX where needed, and stdio.h for printf().

llvm-svn: 129130

class now implements the Host functionality for a lot of things that make 
sense by default so that subclasses can check:

int
PlatformSubclass::Foo ()
{
    if (IsHost())
        return Platform::Foo (); // Let the platform base class do the host specific stuff
    
    // Platform subclass specific code...
    int result = ...
    return result;
}

Added new functions to the platform:

    virtual const char *Platform::GetUserName (uint32_t uid);
    virtual const char *Platform::GetGroupName (uint32_t gid);

The user and group names are cached locally so that remote platforms can avoid
sending packets multiple times to resolve this information.

Added the parent process ID to the ProcessInfo class. 

Added a new ProcessInfoMatch class which helps us to match processes up
and changed the Host layer over to using this new class. The new class allows
us to search for processs:
1 - by name (equal to, starts with, ends with, contains, and regex)
2 - by pid
3 - And further check for parent pid == value, uid == value, gid == value, 
    euid == value, egid == value, arch == value, parent == value.
    
This is all hookup up to the "platform process list" command which required
adding dumping routines to dump process information. If the Host class 
implements the process lookup routines, you can now lists processes on 
your local machine:

machine1.foo.com % lldb
(lldb) platform process list 
PID    PARENT USER       GROUP      EFF USER   EFF GROUP  TRIPLE                   NAME
====== ====== ========== ========== ========== ========== ======================== ============================
99538  1      username   usergroup  username   usergroup  x86_64-apple-darwin      FileMerge
94943  1      username   usergroup  username   usergroup  x86_64-apple-darwin      mdworker
94852  244    username   usergroup  username   usergroup  x86_64-apple-darwin      Safari
94727  244    username   usergroup  username   usergroup  x86_64-apple-darwin      Xcode
92742  92710  username   usergroup  username   usergroup  i386-apple-darwin        debugserver


This of course also works remotely with the lldb-platform:

machine1.foo.com % lldb-platform --listen 1234

machine2.foo.com % lldb
(lldb) platform create remote-macosx
  Platform: remote-macosx
 Connected: no
(lldb) platform connect connect://localhost:1444
  Platform: remote-macosx
    Triple: x86_64-apple-darwin
OS Version: 10.6.7 (10J869)
    Kernel: Darwin Kernel Version 10.7.0: Sat Jan 29 15:17:16 PST 2011; root:xnu-1504.9.37~1/RELEASE_I386
  Hostname: machine1.foo.com
 Connected: yes
(lldb) platform process list 
PID    PARENT USER       GROUP      EFF USER   EFF GROUP  TRIPLE                   NAME
====== ====== ========== ========== ========== ========== ======================== ============================
99556  244    username   usergroup  username   usergroup  x86_64-apple-darwin      trustevaluation
99548  65539  username   usergroup  username   usergroup  x86_64-apple-darwin      lldb
99538  1      username   usergroup  username   usergroup  x86_64-apple-darwin      FileMerge
94943  1      username   usergroup  username   usergroup  x86_64-apple-darwin      mdworker
94852  244    username   usergroup  username   usergroup  x86_64-apple-darwin      Safari

The lldb-platform implements everything with the Host:: layer, so this should
"just work" for linux. I will probably be adding more stuff to the Host layer
for launching processes and attaching to processes so that this support should
eventually just work as well.

Modified the target to be able to be created with an architecture that differs
from the main executable. This is needed for iOS debugging since we can have
an "armv6" binary which can run on an "armv7" machine, so we want to be able
to do:

% lldb
(lldb) platform create remote-ios
(lldb) file --arch armv7 a.out

Where "a.out" is an armv6 executable. The platform then can correctly decide
to open all "armv7" images for all dependent shared libraries.

Modified the disassembly to show the current PC value. Example output:

(lldb) disassemble --frame
a.out`main:
   0x1eb7:  pushl  %ebp
   0x1eb8:  movl   %esp, %ebp
   0x1eba:  pushl  %ebx
   0x1ebb:  subl   $20, %esp
   0x1ebe:  calll  0x1ec3                   ; main + 12 at test.c:18
   0x1ec3:  popl   %ebx
-> 0x1ec4:  calll  0x1f12                   ; getpid
   0x1ec9:  movl   %eax, 4(%esp)
   0x1ecd:  leal   199(%ebx), %eax
   0x1ed3:  movl   %eax, (%esp)
   0x1ed6:  calll  0x1f18                   ; printf
   0x1edb:  leal   213(%ebx), %eax
   0x1ee1:  movl   %eax, (%esp)
   0x1ee4:  calll  0x1f1e                   ; puts
   0x1ee9:  calll  0x1f0c                   ; getchar
   0x1eee:  movl   $20, (%esp)
   0x1ef5:  calll  0x1e6a                   ; sleep_loop at test.c:6
   0x1efa:  movl   $12, %eax
   0x1eff:  addl   $20, %esp
   0x1f02:  popl   %ebx
   0x1f03:  leave
   0x1f04:  ret
   
This can be handy when dealing with the new --line options that was recently
added:

(lldb) disassemble --line
a.out`main + 13 at test.c:19
   18  	{
-> 19  		printf("Process: %i\n\n", getpid());
   20  	    puts("Press any key to continue..."); getchar();
-> 0x1ec4:  calll  0x1f12                   ; getpid
   0x1ec9:  movl   %eax, 4(%esp)
   0x1ecd:  leal   199(%ebx), %eax
   0x1ed3:  movl   %eax, (%esp)
   0x1ed6:  calll  0x1f18                   ; printf

Modified the ModuleList to have a lookup based solely on a UUID. Since the
UUID is typically the MD5 checksum of a binary image, there is no need
to give the path and architecture when searching for a pre-existing
image in an image list.

Now that we support remote debugging a bit better, our lldb_private::Module
needs to be able to track what the original path for file was as the platform
knows it, as well as where the file is locally. The module has the two 
following functions to retrieve both paths:

const FileSpec &Module::GetFileSpec () const;
const FileSpec &Module::GetPlatformFileSpec () const;

llvm-svn: 128563

public types and public enums. This was done to keep the SWIG stuff from
parsing all sorts of enums and types that weren't needed, and allows us to
abstract our API better.

llvm-svn: 128239

On Mac OS X we now have 3 platforms:
PlatformDarwin - must be subclassed to fill in the missing pure virtual funcs
                 but this implements all the common functionality between
                 remote-macosx and remote-ios. It also allows for another
                 platform to be used (remote-gdb-server for now) when doing
                 remote connections. Keeping this pluggable will allow for
                 flexibility.
PlatformMacOSX - Now implements both local and remote macosx desktop platforms.
PlatformRemoteiOS - Remote only iOS that knows how to locate SDK files in the
                    cached SDK locations on the host.

A new agnostic platform has been created:
PlatformRemoteGDBServer - this implements the platform using the GDB remote 
                          protocol and uses the built in lldb_private::Host
                          static functions to implement many queries.

llvm-svn: 128193

process ID to the ProcessInfo.

llvm-svn: 128023

an interface to a local or remote debugging platform. By default each host OS
that supports LLDB should be registering a "default" platform that will be
used unless a new platform is selected. Platforms are responsible for things
such as:
- getting process information by name or by processs ID
- finding platform files. This is useful for remote debugging where there is 
  an SDK with files that might already or need to be cached for debug access.
- getting a list of platform supported architectures in the exact order they
  should be selected. This helps the native x86 platform on MacOSX select the
  correct x86_64/i386 slice from universal binaries.
- Connect to remote platforms for remote debugging
- Resolving an executable including finding an executable inside platform
  specific bundles (macosx uses .app bundles that contain files) and also
  selecting the appropriate slice of universal files for a given platform.

So by default there is always a local platform, but remote platforms can be
connected to. I will soon be adding a new "platform" command that will support
the following commands:
(lldb) platform connect --name machine1 macosx connect://host:port
Connected to "machine1" platform.
(lldb) platform disconnect macosx

This allows LLDB to be well setup to do remote debugging and also once 
connected process listing and finding for things like:
(lldb) process attach --name x<TAB>

The currently selected platform plug-in can now auto complete any available
processes that start with "x". The responsibilities for the platform plug-in
will soon grow and expand.

llvm-svn: 127286

Previously we were using a set of preprocessor defines and returning an ArchSpec
without any OS/Vendor information.  This fixes an issue with plugin resolution
on Linux where a valid OS component is needed.

llvm-svn: 126404

of Stephen Wilson's idea (thanks for the input Stephen!). What I ended up
doing was:
- Got rid of ArchSpec::CPU (which was a generic CPU enumeration that mimics
  the contents of llvm::Triple::ArchType). We now rely upon the llvm::Triple 
  to give us the machine type from llvm::Triple::ArchType.
- There is a new ArchSpec::Core definition which further qualifies the CPU
  core we are dealing with into a single enumeration. If you need support for
  a new Core and want to debug it in LLDB, it must be added to this list. In
  the future we can allow for dynamic core registration, but for now it is
  hard coded.
- The ArchSpec can now be initialized with a llvm::Triple or with a C string
  that represents the triple (it can just be an arch still like "i386").
- The ArchSpec can still initialize itself with a architecture type -- mach-o
  with cpu type and subtype, or ELF with e_machine + e_flags -- and this will
  then get translated into the internal llvm::Triple::ArchSpec + ArchSpec::Core.
  The mach-o cpu type and subtype can be accessed using the getter functions:
  
  uint32_t
  ArchSpec::GetMachOCPUType () const;

  uint32_t
  ArchSpec::GetMachOCPUSubType () const;
  
  But these functions are just converting out internal llvm::Triple::ArchSpec 
  + ArchSpec::Core back into mach-o. Same goes for ELF.

All code has been updated to deal with the changes.

This should abstract us until later when the llvm::TargetSpec stuff gets
finalized and we can then adopt it.

llvm-svn: 126278

llvm-svn: 125706

it should live and the lldb_private::Process takes care of managing the 
auto pointer to the dynamic loader instance.

Also, now that the ArchSpec contains the target triple, we are able to 
correctly set the Target architecture in DidLaunch/DidAttach in the subclasses,
and then the lldb_private::Process will find the dynamic loader plug-in 
by letting the dynamic loader plug-ins inspect the arch/triple in the target.

So now the ProcessGDBRemote plug-in is another step closer to be purely 
process/platform agnostic.

I updated the ProcessMacOSX and the ProcessLinux plug-ins accordingly.

llvm-svn: 125650

now, in addition to cpu type/subtype and architecture flavor, contains:
- byte order (big endian, little endian)
- address size in bytes
- llvm::Triple for true target triple support and for more powerful plug-in
  selection.

llvm-svn: 125602