Fixed the LLDB build so that we can have private types, private enums and
public types and public enums. This was done to keep the SWIG stuff from
parsing all sorts of enums and types that weren't ne

Fixed the LLDB build so that we can have private types, private enums and
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

show more ...

LLDB now has "Platform" plug-ins. Platform plug-ins are plug-ins that provide
an interface to a local or remote debugging platform. By default each host OS
that supports LLDB should be registering a

LLDB now has "Platform" plug-ins. Platform plug-ins are plug-ins that provide
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

show more ...

Fix ObjectFileElf::GetEntryPointAddress()

ELF object files do not implicitly have a symbol named "start" as an entry
point. For example, on Linux it is often named "_start", but can be trivially
se

Fix ObjectFileElf::GetEntryPointAddress()

ELF object files do not implicitly have a symbol named "start" as an entry
point. For example, on Linux it is often named "_start", but can be trivially
set to any symbol by passing an --entry argument to the linker.

Use the ELF header to determine the entry point and resolve the associated
section based on that address.

Also, update the linux dynamic loader to call GetEntryPointAddress instead of
GetEntryPoint.

llvm-svn: 127218

show more ...

I didn't notice there was already an ObjectFile::GetEntryPoint. Move that over to GetEntryPointAddress 'cause that's more consistent with other functions in ObjectFile, do the mutatis mutandi and al

I didn't notice there was already an ObjectFile::GetEntryPoint. Move that over to GetEntryPointAddress 'cause that's more consistent with other functions in ObjectFile, do the mutatis mutandi and also in the ELF case I return a section offset address rather than a bare load address.

llvm-svn: 127205

show more ...

Add a method "GetEntryPoint" to the ObjectFile class, and implement it on MachO & ELF - though the ELF implementation is probably a little weak. Then use this method in place of directly looking for

Add a method "GetEntryPoint" to the ObjectFile class, and implement it on MachO & ELF - though the ELF implementation is probably a little weak. Then use this method in place of directly looking for "start" in the ThreadPlanCallFunction constructor to find the stopping point for our function evaluation.

llvm-svn: 127194

show more ...

linux: Remove a local ObjectFileELF version of GetArchitecture.

Also fix a bug where we were not lazily parsing the ELF header and thus
returning an ArchSpec with invalid cpu type components. Initi

linux: Remove a local ObjectFileELF version of GetArchitecture.

Also fix a bug where we were not lazily parsing the ELF header and thus
returning an ArchSpec with invalid cpu type components. Initialize the cpu
subtype as LLDB_INVALID_CPUTYPE for compatibility with the new ArchSpec
implementation.

llvm-svn: 126405

show more ...

Abtracted all mach-o and ELF out of ArchSpec. This patch is a modified form
of Stephen Wilson's idea (thanks for the input Stephen!). What I ended up
doing was:
- Got rid of ArchSpec::CPU (which was

Abtracted all mach-o and ELF out of ArchSpec. This patch is a modified form
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

show more ...

linux: Set ArchSpec m_type correctly from object file.

An ArchSpec's type defaults to MachO. Ensure the type is properly set
on ELF systems.

llvm-svn: 125654

Made lldb_private::ArchSpec contain much more than just an architecture. It
now, in addition to cpu type/subtype and architecture flavor, contains:
- byte order (big endian, little endian)
- address

Made lldb_private::ArchSpec contain much more than just an architecture. It
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

show more ...

Applied a fix to qualify "UUID" with the lldb_private namespace to fix
build issues on MinGW.

llvm-svn: 124888

Test if an ELF object is executable by checking if an entry point is defined.

The previous check on header type ET_EXEC is not general enough. Position
independent executables have type ET_DYN.

ll

Test if an ELF object is executable by checking if an entry point is defined.

The previous check on header type ET_EXEC is not general enough. Position
independent executables have type ET_DYN.

llvm-svn: 123498

show more ...

Implement GetEntryPoint, GetImageInfoAddress and GetArchitecture for ObjectFileELF.

llvm-svn: 123496

Added the ability to dump sections to a certain depth (for when sections
have children sections).

Modified SectionLoadList to do it's own multi-threaded protected on its map.
The ThreadSafeSTLMap cl

Added the ability to dump sections to a certain depth (for when sections
have children sections).

Modified SectionLoadList to do it's own multi-threaded protected on its map.
The ThreadSafeSTLMap class was difficult to deal with and wasn't providing
much utility, it was only getting in the way.

Make sure when the communication read thread is about to exit, it clears the
thread in the main class.

Fixed the ModuleList to correctly ignore architectures and UUIDs if they aren't
valid when searching for a matching module. If we specified a file with no arch,
and then modified the file and loaded it again, it would not match on subsequent
searches if the arch was invalid since it would compare an invalid architecture
to the one that was found or selected within the shared library or executable.
This was causing stale modules to stay around in the global module list when they
should have been removed.

Removed deprecated functions from the DynamicLoaderMacOSXDYLD class.

Modified "ProcessGDBRemote::IsAlive" to check if we are connected to a gdb
server and also make sure our process hasn't exited.

llvm-svn: 121236

show more ...

Fixed an issue where we were resolving paths when we should have been.

So the issue here was that we have lldb_private::FileSpec that by default was
always resolving a path when using the:

FileSpe

Fixed an issue where we were resolving paths when we should have been.

So the issue here was that we have lldb_private::FileSpec that by default was
always resolving a path when using the:

FileSpec::FileSpec (const char *path);

and in the:

void FileSpec::SetFile(const char *pathname, bool resolve = true);

This isn't what we want in many many cases. One example is you have "/tmp" on
your file system which is really "/private/tmp". You compile code in that
directory and end up with debug info that mentions "/tmp/file.c". Then you
type:

(lldb) breakpoint set --file file.c --line 5

If your current working directory is "/tmp", then "file.c" would be turned
into "/private/tmp/file.c" which won't match anything in the debug info.
Also, it should have been just a FileSpec with no directory and a filename
of "file.c" which could (and should) potentially match any instances of "file.c"
in the debug info.

So I removed the constructor that just takes a path:

FileSpec::FileSpec (const char *path); // REMOVED

You must now use the other constructor that has a "bool resolve" parameter that you must always supply:

FileSpec::FileSpec (const char *path, bool resolve);

I also removed the default parameter to SetFile():

void FileSpec::SetFile(const char *pathname, bool resolve);

And fixed all of the code to use the right settings.

llvm-svn: 116944

show more ...

Fixed the Objective C method prototypes to be correct (the selectors weren't
being chopped up correctly). The DWARF plug-in also keeps a map of the ObjC
class names to selectors for easy parsing of a

Fixed the Objective C method prototypes to be correct (the selectors weren't
being chopped up correctly). The DWARF plug-in also keeps a map of the ObjC
class names to selectors for easy parsing of all class selectors when we parse
the class type.

llvm-svn: 116290

show more ...

Added mutex protection to the Symtab class.

Added a new SortOrder enumeration and hooked it up to the "image dump symtab"
command so we can dump symbol tables in the original order, sorted by addres

Added mutex protection to the Symtab class.

Added a new SortOrder enumeration and hooked it up to the "image dump symtab"
command so we can dump symbol tables in the original order, sorted by address,
or sorted by name.

llvm-svn: 116049

show more ...

Looks like this is how you identify executables in ELF.

llvm-svn: 110641

Change Target & Process so they can really be initialized with an invalid architecture.
Arrange that this then gets properly set on attach, or when a "file" is set.
Add a completer for "process atta

Change Target & Process so they can really be initialized with an invalid architecture.
Arrange that this then gets properly set on attach, or when a "file" is set.
Add a completer for "process attach -n".

Caveats: there isn't currently a way to handle multiple processes with the same name. That
will have to wait on a way to pass annotations along with the completion strings.

llvm-svn: 110624

show more ...

Modified both the ObjectFileMachO and ObjectFileELF to correctly set the
SectionType for Section objects for DWARF.

Modified the DWARF plug-in to get the DWARF sections by SectionType so we
can safe

Modified both the ObjectFileMachO and ObjectFileELF to correctly set the
SectionType for Section objects for DWARF.

Modified the DWARF plug-in to get the DWARF sections by SectionType so we
can safely abstract the LLDB core from section names for the various object
file formats.

Modified the SectionType definitions for .debug_pubnames and .debug_pubtypes
to use the correct case.

llvm-svn: 109054

show more ...

Combine 32 and 64 bit ELF readers.

This patch provides a generic ELF reader plugin to handle both 32 and 64 bit
formats.

llvm-svn: 108292

64 bit ELF support from Stephen Wilson.

llvm-svn: 107817

Remove Mac-specific includes.

llvm-svn: 105905

Made lldb_private::ArchSpec more generic so that it can take a mach-o cpu
type and sub-type, or an ELF e_machine value. Also added a generic CPU type
to the arch spec class so we can have a single ar

Made lldb_private::ArchSpec more generic so that it can take a mach-o cpu
type and sub-type, or an ELF e_machine value. Also added a generic CPU type
to the arch spec class so we can have a single arch definition that the LLDB
core code can use. Previously a lot of places in the code were using the
mach-o definitions from a macosx header file.

Switches over to using "llvm/Support/MachO.h" for the llvm::MachO::XXX for the
CPU types and sub types for mach-o ArchSpecs. Added "llvm/Support/ELF.h" so
we can use the "llvm::ELF::XXX" defines for the ELF ArchSpecs.

Got rid of all CPU_TYPE_ and CPU_SUBTYPE_ defines that were previously being
used in LLDB.

llvm-svn: 105806

show more ...

Initial checkin of lldb code from internal Apple repo.

llvm-svn: 105619