| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 189317
|
| |
|
|
|
|
|
|
|
| |
out of a binary, if the Mach-O binary is MH_PRELOAD ("standalone"), don't
let the OS be set to "ios" or "macosx" - there will be no dynamic loader
used when debugging this process.
<rdar://problem/9956443>
llvm-svn: 189305
|
| |
|
|
|
|
| |
portability.
llvm-svn: 189107
|
| |
|
|
|
|
|
| |
we've read the ObjectFile's Symtab before we change the
File addresses in the Sections.
llvm-svn: 188604
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
address.
When loading a dSYM, and the file addresses of the dSYM Sections are
different than the executable binary Sections' file addresses, the
debug info won't be remapped to the actual load addresses correctly.
This only happens with binaries on the in-memory shared cache binaries
where their File addresses have been set to their actual load address
(outside an offset value) whereas the original executable and dSYM
have 0-based File addresses.
I think this patch will not be activated for other cases -- this is
the only case we know of where the dSYM and the executable's File
addresses differ -- but if this causes other problems we can restrict
it more carefully.
<rdar://problem/12335086>
llvm-svn: 188532
|
| |
|
|
|
|
| |
Improve the documentation for the new target.memory-module-load-level setting, and also return an error when there is no nlist data when appropriate.
llvm-svn: 188317
|
| |
|
|
|
|
|
|
|
|
|
|
| |
LLDB needs in memory module load level settings to control how much information is read from memory when loading in memory modules. This change adds a new setting:
(lldb) settings set target.memory-module-load-level [minimal|partial|complete]
minimal will load only sections (no symbols, or function bounds via function starts or EH frame)
partial will load sections + bounds
complete will load sections + bounds + symbols
llvm-svn: 188246
|
| |
|
|
|
|
|
|
|
|
|
| |
- MachO files now correctly extract the UUID all the time
- More file size and offset verification done for universal mach-o files to watch for truncated files
- ObjectContainerBSDArchive now supports enumerating all objects in BSD archives (.a files)
- lldb_private::Module() can not be properly constructed using a ModuleSpec for a .o file in a .a file
- The BSD archive plug-in shares its cache for GetModuleSpecifications() and the create callback
- Improved printing for ModuleSpec objects
llvm-svn: 186211
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- ObjectFile::GetSymtab() and ObjectFile::ClearSymtab() no longer takes any flags
- Module coordinates with the object files and contain a unified section list so that object file and symbol file can share sections when they need to, yet contain their own sections.
Other cleanups:
- Fixed Symbol::GetByteSize() to not have the symbol table compute the byte sizes on the fly
- Modified the ObjectFileMachO class to compute symbol sizes all at once efficiently
- Modified the Symtab class to store a file address lookup table for more efficient lookups
- Removed Section::Finalize() and SectionList::Finalize() as they did nothing
- Improved performance of the detection of symbol files that have debug maps by excluding stripped files and core files, debug files, object files and stubs
- Added the ability to tell if an ObjectFile has been stripped with ObjectFile::IsStripped() (used this for the above performance improvement)
llvm-svn: 185990
|
| |
|
|
| |
llvm-svn: 185366
|
| |
|
|
|
|
| |
Accept mach-o files with bad segments. Many core files are not created correctly and we should still be able to glean any information we can from them.
llvm-svn: 183247
|
| |
|
|
|
|
|
|
| |
Fixed "target symbols add" to correctly extract all module specifications from a dSYM file that is supplied and match the symbol file to a current target module using the UUID values if they are available.
This fixes the case where you add a dSYM file (like "foo.dSYM") which is for a renamed executable (like "bar"). In our case it was "mach_kernel.dSYM" which didn't match "mach_kernel.sys".
llvm-svn: 181916
|
| |
|
|
|
|
| |
Combine N_GSYM stab entries with their non-stab counterpart (data symbols) to make the symbol table smaller with less duplicate named symbols.
llvm-svn: 181841
|