These changes were written by Greg Clayton, Jim Ingham, Jason Molenda.
It builds cleanly against TOT llvm with xcodebuild. I updated the
cmake files by visual inspection but did not try a build. I haven't
built these sources on any non-Mac platforms - I don't think this
patch adds any code that requires darwin, but please let me know if
I missed something.
In debugserver, MachProcess.cpp and MachTask.cpp were renamed to
MachProcess.mm and MachTask.mm as they picked up some new Objective-C
code needed to launch processes when running on iOS.
llvm-svn: 205113
add a new pure virtual CalculateTrapHandlerSymbolNames() that Platform
subclasses must implement which fills in the function name list with any
trap handlers that are expected on that platform.
llvm-svn: 201364
aka asynchronous signal handlers, which subclasses should fill
in as appropriate. For most Unix user process environments,
the one entry in this list is _sigtramp. For bare-board and
kernel environments, there will be different sets of trap
handlers.
The unwinder needs to know when a frame is a trap handler
because the rules it enforces for the frame "above" the
trap handler is different from most middle-of-the-stack frames.
<rdar://problem/15835846>
llvm-svn: 201300
did a manual "target modules add", it would be a file path. If the kext bundle lookup fails,
fall back to calling PlatformDarwin's GetSharedModule which will handle a file path correctly.
<rdar://problem/14179858>
llvm-svn: 184237
<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
help performance -- if the FileSpec we're examining does not contain the
UUID we're looking for, don't bother examining the file any further.
llvm-svn: 181063
with directories, without increasing the size of the FileSpec object.
GetPath() returns a std::string of the full pathname of the file.
IsDirectory(), IsPipe(), IsRegularFile(), IsSocket(), and IsSymbolicLink()
can be used instead of getting the FileType() and comparing it to an enum.
Update PlatformDarwinKernel to use these new methods.
llvm-svn: 180704
platform.plugin.darwin-kernel.kext-directories
platform.plugin.darwin-kernel.search-locally-for-kexts
and fix a few FileSpec handling issues for the kext-directories setting.
llvm-svn: 178920
Add two initial settings for the PlatformDarwinKernel plugin,
plugin.platform.darwin-kernel.search-locally-for-kexts [true|false]
plugin.platform.darwin-kernel.kext-directories [directory list]
llvm-svn: 178846
plugin will index the kext bundles on the local filesystem when
created. During a kernel debug session, when the DynamicLoader
plugin needs to locate a kext by name like
"com.apple.com.apple.filesystems.autofs", the Platform can quickly
look for a UUID match in those kernel debug kit directories it
previously indexed.
I'm still working on profiling the performance impact of the inital
kext bundle scan; there will likely need to be a switch to enable
or disable this plugin's scan.
This only affects Mac kernel debugging and the code is only built
on Apple systems because of some use of low-level CoreFoundation
to parse plists.
<rdar://problem/13503583>
llvm-svn: 178827