| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
| |
Mach-O files.
<rdar://problem/20113673>
llvm-svn: 233893
|
|
|
|
|
|
|
|
|
| |
So that we don't have to update every single #include in the entire
codebase to #include this new header (which used to get included by
lldb-private-log.h, we automatically #include "Logging.h" from
within "Log.h".
llvm-svn: 232653
|
|
|
|
|
|
|
|
| |
- in order to allow modules caching from remote targets.
http://reviews.llvm.org/D8037
llvm-svn: 231734
|
|
|
|
|
|
|
| |
No functional change here, only deletes unnecessary headers
and moves one function's body from the .h file to the .cpp.
llvm-svn: 231145
|
|
|
|
|
|
|
|
| |
could cause ObjectFileMachO::ParseSymtab() to crash.
<rdar://problem/19989491>
llvm-svn: 231048
|
|
|
|
|
|
| |
"_OBJC_CLASS_$_", "_OBJC_METACLASS_$_", and "_OBJC_IVAR_$_" non debug symbols. This allows the symbol that represents the object file to contain the eSymbolTypeObjCClass and eSymbolTypeObjCMetaClass and will help us to be able to efficiently lookup the real definition of an objective C class without loading all .o files linearly to find the .o file that contains the true definition.
llvm-svn: 230509
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is implemented by making a new FileSystem function:
bool
FileSystem::IsLocal(const FileSpec &spec)
Then using this in a new function:
DataBufferSP
FileSpec::MemoryMapFileContentsIfLocal(off_t file_offset, size_t file_size) const;
This function only mmaps data if the file is a local file since that means we can reliably page in data. We were experiencing crashes where people would use debug info files on network mounted file systems and that mount would go away and cause the next access to a page that wasn't paged in to crash LLDB.
We now avoid this by just copying the data into a heap buffer and keeping a permanent copy to avoid the crash. Updated all previous users of FileSpec::MemoryMapFileContentsIfLocal() in ObjectFile subclasses over to use the new FileSpec::MemoryMapFileContentsIfLocal() function.
<rdar://problem/19470249>
llvm-svn: 230283
|
|
|
|
| |
llvm-svn: 230076
|
|
|
|
|
|
|
|
| |
in order to reproduce them since this dyld trie info can be missing.
<rdar://problem/19749670>
llvm-svn: 229201
|
|
|
|
|
|
|
|
|
|
| |
figure it out through the ObjectFile.
Background: dyld binaries often have extra symbols in their symbol table like "malloc" and "free" for the early bringup of dyld and we often don't want to set breakpoints in dynamic linker binaries. We also don't want to call the "malloc" or "free" function in dyld when a user writes an expression like "(void *)malloc(123)" so we need to avoid doing name lookups in dyld. We mark Modules as being dynamic link editors and this helps do correct lookups for breakpoints by name and function lookups.
<rdar://problem/19716267>
llvm-svn: 228261
|
|
|
|
|
|
|
|
| |
ObjectFileMachO::GetMinimumOSVersion(...) and ObjectFileMachO::GetSDKVersion(...).
<rdar://problem/19697053>
llvm-svn: 228092
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
section for x86_64 and i386 targets on Darwin systems. Currently only the
compact unwind encoding for normal frame-using functions is supported but it
will be easy handle frameless functions when I have a bit more free time to
test it. The LSDA and personality routines for functions are also retrieved
correctly for functions from the compact unwind section.
This new code is very fresh -- it passes the lldb testsuite and I've done
by-hand inspection of many functions and am getting correct behavior for all
of them. There may need to be some bug fixing over the next couple weeks as
I exercise and test it further. But I think it's fine right now so I'm
committing it.
<rdar://problem/13220837>
llvm-svn: 223625
|
|
|
|
|
|
|
| |
The problems with the dyld all image infos struct
seems to be specific to arm64.
llvm-svn: 221760
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ObjectFileMachO. It's close but we seem to be missing some
of the memory region segments - not exactly sure how that's
happening. The register context writing into the LC_THREAD
load commands is working correctly though.
Slightly reordered the arm64 definitions in ArchSpec.cpp so
when we look for an arm64 core file definiton we're getting
a cpu subtype of CPU_ANY which we can't put in the mach
header of a core file. Make the first definition we find by
linear search have the currently correct '1' cpu subtype.
llvm-svn: 221743
|
|
|
|
|
|
| |
file dumping.
llvm-svn: 221683
|
|
|
|
|
|
| |
clang static analyzer fixit.
llvm-svn: 219904
|
|
|
|
|
|
|
|
|
|
| |
not be read in where N was the number of LC_THREAD load commands.
I now properly increment the ncmds for each LC_THREAD and now core files are saved correctly.
<rdar://problem/18312703>
llvm-svn: 217905
|
|
|
|
|
|
| |
Changes reference to 4th element in version_min_command from reserved to sdk.
llvm-svn: 217185
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
with binaries in the dyld shared cache (esp on iOS) where the file
address for the executable binary (maybe from memory, maybe from
an expanded copy of the dyld shared cache) is different from the
file address in the dSYM. In that case, ObjectFileMachO replaces
the file addresses from the original binary with the dSYM file
addresses (usually 0-based) -- lldb doesn't have a notion of two
file addresses for a given module so they need to agree.
There was a cache of file addresses over in the Symtab so I added
a method to the Module and the objects within to clear any file address
caches if they exist, and added an implementation in the Symtab
module to do that.
<rdar://problem/16929569>
llvm-svn: 216258
|
|
|
|
|
|
|
|
| |
the OS for x86_64 and x86 in case the binary ends up being for macosx or ios.
<rdar://problem/17819272>
llvm-svn: 214188
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
File::SeekFromStart returns an off_t representing the position of the
file after seeking. This return value is always going to be one of two
values: the input or -1 in the case of failure.
ObjectFileMachO compares an expression of type off_t from the return of
File::SeekFromStart(segment.fileoff) and compares it for equality with
segment.fileoff.
The type of segment_command_64::fileoff is unsigned while off_t is
signed, comparing them emits a diagnostic under GCC.
Instead, we can just compare SeekFromSTart with -1 to see if we
successfully seeked.
Differential Revision: http://reviews.llvm.org/D4634
llvm-svn: 213822
|
|
|
|
|
|
| |
Address a few signed-compare warnings that were triggered on GCC 4.8.2.
llvm-svn: 213716
|
|
|
|
|
|
|
|
|
| |
GCC emits a warning:
warning: enumeral and non-enumeral type in conditional expression [enabled by default]
which does not seem to have a flag to control it. Simply add an explicit cast
for the boolean value.
llvm-svn: 213715
|
|
|
|
| |
llvm-svn: 213366
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes all of the hidden ivar test cases and any case where we try to find the full definition of an objective C class.
This also means hidden ivars show up again.
<rdar://problem/15458957>
llvm.org/pr20270
llvm.org/pr20269
llvm.org/pr20272
llvm-svn: 213328
|
|
|
|
|
|
|
|
| |
Change by Paul Osmialowski
See http://reviews.llvm.org/D4379 for details.
llvm-svn: 212583
|
|
|
|
| |
llvm-svn: 212132
|
|
|
|
|
|
| |
The patch is as is with the functionality left disabled for apple vendors because of performance regressions. If this is enabled it ends up searching for symbols in all shared libraries that are loadeded.
llvm-svn: 211638
|
|
|
|
|
|
|
|
|
|
| |
S_ATTR_PURE_INSTRUCTIONS and S_ATTR_SOME_INSTRUCTIONS section flags.
Also correctly set the symbol type of symbols for S_REGULAR and other section types.
<rdar://problem/16896734>
llvm-svn: 211073
|
|
|
|
|
|
|
|
| |
Address the 'variable set but not used' warning from GCC. In some cases a few
additional calls were removed where there should be no visible side effects of
the calls (i.e. should not effect any cached state).
llvm-svn: 210879
|
|
|
|
|
|
|
|
|
|
|
| |
(lldb) file /bin/ls
(lldb) b malloc
(lldb) run
(lldb) process save-core /tmp/ls.core
Each ObjectFile plug-in now has the option to save core files by registering a new static callback.
llvm-svn: 210864
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
apps and binaries.
Changes include:
- ObjectFileMachO can now determine if a binary is "*-apple-ios" or "*-apple-macosx" by checking the min OS and SDK load commands
- ArchSpec now says "<arch>-apple-macosx" is equivalent to "<arch>-apple-ios" since the simulator mixes and matches binaries (some from the system and most from the iOS SDK).
- Getting process inforamtion on MacOSX now correctly classifies iOS simulator processes so they have "*-apple-ios" architectures in the ProcessInstanceInfo
- PlatformiOSSimulator can now list iOS simulator processes correctly instead of showing nothing by using:
(lldb) platform select ios-simulator
(lldb) platform process list
- debugserver can now properly return "*-apple-ios" for the triple in the process info packets for iOS simulator executables
- GDBRemoteCommunicationClient now correctly passes along the triples it gets for process info by setting the OS in the llvm::Triple correctly
<rdar://problem/17060217>
llvm-svn: 209852
|
|
|
|
|
|
|
|
|
| |
contain the symbol, but just reexports wholesale from another
library. Handle this case.
<rdar://problem/16977589>
llvm-svn: 209270
|
|
|
|
|
|
|
|
| |
plus the size of the load commands in case the LC_UUID load command comes near
the end of the file.
<rdar://problem/16599318>
llvm-svn: 206865
|
|
|
|
|
|
|
| |
This is a purely mechanical change explicitly casting any parameters for printf
style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux.
llvm-svn: 205607
|
|
|
|
|
|
|
|
|
|
| |
headers
on Mac OS X (in particular mach/machine.h).
<rdar://problem/16494607>
llvm-svn: 205480
|
|
|
|
|
|
|
|
| |
This is a mechanical change addressing the various sign comparison warnings that
are identified by both clang and gcc. This helps cleanup some of the warning
spew that occurs during builds.
llvm-svn: 205390
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
instace of ProcessElfCore or ProcessMachCore respectively.
llvm-svn: 203274
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ObjectFile::SetLoadAddress (Target &target,
lldb::addr_t value,
bool value_is_offset);
Now "value" is a slide if "value_is_offset" is true, and "value" is an image base address otherwise. All previous usage of this API was using slides.
Updated the ObjectFileELF and ObjectFileMachO SetLoadAddress methods to do the right thing.
Also updated the ObjectFileMachO::SetLoadAddress() function to not load __LINKEDIT when it isn't needed and to only load sections that belong to the executable object file.
llvm-svn: 201003
|
|
|
|
| |
llvm-svn: 200943
|
|
|
|
|
|
|
|
| |
symbols, now we do.
<rdar://problem/15831334>
llvm-svn: 199345
|
|
|
|
|
|
|
|
| |
there are multiple symbols with the same name.
<rdar://problem/15831292>
llvm-svn: 199344
|
|
|
|
|
|
| |
marked with the EXPORT_SYMBOL_FLAGS_STUB_AND_RESOLVER, it is given in the address in the “other” field in that entry.
llvm-svn: 198967
|
|
|
|
|
|
|
|
| |
plugins. If LLDB lives inside an Xcode.app bundle, it will select the SDK in the Xcode bundle, else it will use the currently selected Xcode.
Also added the DWARFDataExtractor classes to the Xcode project file.
llvm-svn: 193380
|
|
|
|
|
|
|
|
| |
Fixed an issue with reexported symbols on MacOSX by adding support for symbols re-exporting symbols. There is now a new symbol type eSymbolTypeReExported which contains a new name for the re-exported symbol and the new shared library. These symbols are only used when a symbol is re-exported as a symbol under a different name.
Modified the expression parser to be able to deal with finding the re-exported symbols and track down the actual symbol it refers to.
llvm-svn: 193101
|
|
|
|
|
|
| |
Fixed Module::ResolveSymbolContextForAddress() to be able to also look in the SymbolVendor's SymbolFile's ObjectFile for a more meaningful symbol when a symbol lookup finds a synthetic symbol from the main object file. This will help lookups on MacOSX as the main executable might be stripped, but the dSYM file always has a full symbol table.
llvm-svn: 192510
|
|
|
|
| |
llvm-svn: 191367
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
and a mach kernel in all the pages of the core file. If it finds
a user-process dyld binary, assume this is a user process that had
a copy of the mach kernel in memory when it crashed (e.g. lldb doing
kernel debugging) even though we found the kernel binary first.
Also, change the error messages about sections extending past the end
of the file to be warnings and make the messages sound less severe.
Most user process core files have one section that isn't included in
the file and there's no reason to worry people about that.
<rdar://problem/14473235>
llvm-svn: 190741
|
|
|
|
| |
llvm-svn: 189355
|