Commit Graph

8 Commits

Author SHA1 Message Date
Kate Stone b9c1b51e45 *** This commit represents a complete reformatting of the LLDB source code
*** to conform to clang-format’s LLVM style.  This kind of mass change has
*** two obvious implications:

Firstly, merging this particular commit into a downstream fork may be a huge
effort.  Alternatively, it may be worth merging all changes up to this commit,
performing the same reformatting operation locally, and then discarding the
merge for this particular commit.  The commands used to accomplish this
reformatting were as follows (with current working directory as the root of
the repository):

    find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} +
    find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ;

The version of clang-format used was 3.9.0, and autopep8 was 1.2.4.

Secondly, “blame” style tools will generally point to this commit instead of
a meaningful prior commit.  There are alternatives available that will attempt
to look through this change and find the appropriate prior commit.  YMMV.

llvm-svn: 280751
2016-09-06 20:57:50 +00:00
Saleem Abdulrasool 16ff860469 remove use of Mutex in favour of std::{,recursive_}mutex
This is a pretty straightforward first pass over removing a number of uses of
Mutex in favor of std::mutex or std::recursive_mutex. The problem is that there
are interfaces which take Mutex::Locker & to lock internal locks. This patch
cleans up most of the easy cases. The only non-trivial change is in
CommandObjectTarget.cpp where a Mutex::Locker was split into two.

llvm-svn: 269877
2016-05-18 01:59:10 +00:00
Eugene Zelenko 4c3f2b9446 Fix Clang-tidy modernize-use-override warnings in some files in source/Plugins; other minor fixes.
Differential Revision: http://reviews.llvm.org/D13916

llvm-svn: 250872
2015-10-21 01:03:30 +00:00
Jim Ingham 46d005dbc4 Workaround for collision between enum members in LLVM's MachO.h and system headers
on Mac OS X (in particular mach/machine.h).

<rdar://problem/16494607>

llvm-svn: 205480
2014-04-02 22:53:21 +00:00
Greg Clayton 3657e9c592 Don’t include “llvm/Support/MachO.h” as it isn’t needed here.
llvm-svn: 205461
2014-04-02 20:38:03 +00:00
Greg Clayton 57abc5d6a6 <rdar://problem/13854277>
<rdar://problem/13594769>

Main changes in this patch include:
- cleanup plug-in interface and use ConstStrings for plug-in names
- Modfiied the BSD Archive plug-in to be able to pick out the correct .o file when .a files contain multiple .o files with the same name by using the timestamp
- Modified SymbolFileDWARFDebugMap to properly verify the timestamp on .o files it loads to ensure we don't load updated .o files and cause problems when debugging

The plug-in interface changes:

Modified the lldb_private::PluginInterface class that all plug-ins inherit from:

Changed:

virtual const char * GetPluginName() = 0;

To: 

virtual ConstString GetPluginName() = 0;

Removed:

virtual const char * GetShortPluginName() = 0;

- Fixed up all plug-in to adhere to the new interface and to return lldb_private::ConstString values for the plug-in names. 
- Fixed all plug-ins to return simple names with no prefixes. Some plug-ins had prefixes and most ones didn't, so now they all don't have prefixed names, just simple names like "linux", "gdb-remote", etc.

llvm-svn: 181631
2013-05-10 21:47:16 +00:00
Greg Clayton e996fd30be 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
2011-03-08 22:40:15 +00:00
Greg Clayton fc7117ae93 Added a DynamicLoaderStatic plug-in that will act as a static dynamic loader.
It will just load all files exactly where the files state they are (file
addresses == load addresses). This is used when the llvm::Triple::OSType is
set to llvm::Triple::UnknownOS or llvm::Triple::NoOS.

llvm-svn: 127053
2011-03-05 01:04:56 +00:00