Summary:
The only usage there was in GetModificationTime(). I also took the opportunity
to move this function from FileSpec to the FileSystem class - since we are
using FileSpecs to also represent remote files for which we cannot (easily)
retrieve modification time, it makes sense to make the decision to get the
modification time more explicit.
The new function returns a llvm::sys::TimePoint<>. To aid the transition
from TimeValue, I have added a constructor to it which enables implicit
conversion from a time_point.
Reviewers: zturner, clayborg
Subscribers: mehdi_amini, tberghammer, danalbert, beanz, mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D25392
llvm-svn: 285702
This updates getters and setters to use StringRef instead of
const char *. I tested the build on Linux, Windows, and OSX
and saw no build or test failures. I cannot test any BSD
or Android variants, however I expect the required changes
to be minimal or non-existant.
llvm-svn: 282079
*** 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
for the fall (northern hemisphere) 2016 Darwin platforms to learn
about loaded images, instead of reading dyld internal data structures.
These new SPI don't exist on older releases, and new packets are
needed from debugserver to use them (those changes are already committed).
I had to change the minimum deployment target for debugserver in the xcode
project file to macOS 10.10 so that debugserver will use the
[[NSProcessInfo processInfo] operatingSystemVersion]
call in MachProcess::GetOSVersionNumbers to get the operarting system
version # -- this API is only available in macOS 10.10 and newer
("OS X Yosemite", released Oct 2014). If we have many people building
llvm.org lldb on older systems still, we can back off on this for the
llvm.org sources.
There should be no change in behavior with this commit, either to
older darwin systems or newer darwin systems.
For now the new DynamicLoader plugin is never activated - I'm forcing
the old plugin to be used in DynamicLoaderDarwin::UseDYLDSPI.
I'll remove that unconditional use of the old plugin soon, so the
newer plugin is used on the newest Darwin platforms.
<rdar://problem/25251243>
llvm-svn: 276254
a base class and a derived class, with the derived class containing
the methods specific to reading dyld's all_image_infos, dyld's
method of specifying images that have been loaded or unloaded, the
place where we put a breakpoint in dyld to get notified about newly
loaded or unloaded images.
This is in preparation for a second derived class which will use
some alternate methods for getting this information; that will be
a separate commit in the next few days.
There's a couple of ivars that should probably be in the derived
DyanmicLoaderMacOSX class instead of the base DynamicLoaderDarwin
class (m_dyld_image_infos, m_dyld_image_infos_stop_id). I don't
think I'll need to use these in the new derived class - I'll
move them down to DynamicLoaderMacOSX if it works out that way;
it'll simplify locking if I can do that.
<rdar://problem/25251243>
llvm-svn: 275733
Pavel Labath