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
Most importantly, have DoReadGPR/DoReadFPU/DoReadEXC return -1
to indicate failure if they're called. Else these could override
the Error setting for the relevant thread state -- if the core file
didn't include a floating point thread state, for instance, these
functions would clear the Error setting for that register set and
lldb would display random bytes as those registers' contents.
<rdar://problem/13665075>
llvm-svn: 181757
<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
std::string
Module::GetSpecificationDescription () const;
This returns the module as "/usr/lib/libfoo.dylib" for normal files (calls "std::string FileSpec::GetPath()" on m_file) but it also might include the object name in case the module is for a .o file in a BSD archive ("/usr/lib/libfoo.a(bar.o)"). Cleaned up necessary logging code to use it.
llvm-svn: 180717
There is a new static ObjectFile function you can call:
size_t
ObjectFile::GetModuleSpecifications (const FileSpec &file,
lldb::offset_t file_offset,
ModuleSpecList &specs)
This will fill in "specs" which the details of all the module specs (file + arch + UUID (if there is one) + object name (for BSD archive objects eventually) + file offset to the object in question).
This helps us when a user specifies a file that contains a single architecture, and also helps us when we are given a debug symbol file (like a dSYM file on MacOSX) that contains one or more architectures and we need to be able to match it up to an existing Module that has no debug info.
llvm-svn: 180224
differs from lldb's own shared cache, and where the inferior process shared
cache does not match up with the on-disk shared cache file.
Simplify the code where lldb gets its own shared cache uuid a little bit.
llvm-svn: 179633
Show an error message when we have a corrupt mach-o file where the LC_SEGMENT or LC_SEGMENT_64 load command have file offsets or file offsets + sizes that extend beyond the end of the file.
llvm-svn: 179605
a UUID for the shared cache libraries that can be used to confirm
that one process' shared cache is the same as another, or that a
process' in-memory shared cache is a match for a given on-disk
dyld_shared_cache binary file. Use these UUIDs to catch some
uncommon problems when the shared caches are being changed for debug
purposes.
<rdar://problem/13524467>
llvm-svn: 179583
SectionList so we don't try to do anything with this file. Currently we end up crashing
later in the debug session when we read past the end of the file -- this at least gets us
closer with something like ProcessMachCore printing "error: core file has no sections".
<rdar://problem/13468295>
llvm-svn: 179152
LLDB is crashing when logging is enabled from lldb-perf-clang. This has to do with the global destructor chain as the process and its threads are being torn down.
All logging channels now make one and only one instance that is kept in a global pointer which is never freed. This guarantees that logging can correctly continue as the process tears itself down.
llvm-svn: 178191
This returns a vector of <file address, size> entries for all of
the functions in the module that have an eh_frame FDE.
Update ObjectFileMachO to use the eh_frame FDE function addresses if
the LC_FUNCTION_STARTS section is missing, to fill in the start
addresses of any symbols that have been stripped from the binary.
Generally speaking, lldb works best if it knows the actual start
address of every function in a module - it's especially important
for unwinding, where lldb inspects the instructions in the prologue
of the function. In a stripped binary, it is deprived of this
information and it reduces the quality of our unwinds and saved
register retrieval.
Other ObjectFile users may want to use the function addresses from
DWARFCallFrameInfo to fill in any stripped symbols like ObjectFileMachO
does already.
<rdar://problem/13365659>
llvm-svn: 177624
DWARF with .o files now uses 40-60% less memory!
Big fixes include:
- Change line table internal representation to contain "file addresses". Since each line table is owned by a compile unit that is owned by a module, it makes address translation into lldb_private::Address easy to do when needed.
- Removed linked address members/methods from lldb_private::Section and lldb_private::Address
- lldb_private::LineTable can now relink itself using a FileRangeMap to make it easier to re-link line tables in the future
- Added ObjectFile::ClearSymtab() so that we can get rid of the object file symbol tables after we parse them once since they are not needed and kept memory allocated for no reason
- Moved the m_sections_ap (std::auto_ptr to section list) and m_symtab_ap (std::auto_ptr to the lldb_private::Symtab) out of each of the ObjectFile subclasses and put it into lldb_private::ObjectFile.
- Changed how the debug map is parsed and stored to be able to:
- Lazily parse the debug map for each object file
- not require the address map for a .o file until debug information is linked for a .o file
llvm-svn: 176454
lldb was mmap'ing archive files once per .o file it loads, now it correctly shares the archive between modules.
LLDB was also always mapping entire contents of universal mach-o files, now it maps just the slice that is required.
Added a new logging channel for "lldb" called "mmap" to help track future regressions.
Modified the ObjectFile and ObjectContainer plugin interfaces to take a data offset along with the file offset and size so we can implement the correct caching and efficient reading of parts of files without mmap'ing the entire file like we used to.
The current implementation still keeps entire .a files mmaped (once) and entire slices from universal files mmaped to ensure that if a client builds their binaries during a debug session we don't lose our data and get corrupt object file info and debug info.
llvm-svn: 174524
function stub routine addresses from an in-memory-only
MachO object file. This was the only remaining part of
ParseSymtab() that was assuming a file exists.
<rdar://problem/13139585>
llvm-svn: 174455
Major fixed to allow reading files that are over 4GB. The main problems were that the DataExtractor was using 32 bit offsets as a data cursor, and since we mmap all of our object files we could run into cases where if we had a very large core file that was over 4GB, we were running into the 4GB boundary.
So I defined a new "lldb::offset_t" which should be used for all file offsets.
After making this change, I enabled warnings for data loss and for enexpected implicit conversions temporarily and found a ton of things that I fixed.
Any functions that take an index internally, should use "size_t" for any indexes and also should return "size_t" for any sizes of collections.
llvm-svn: 173463
equality can be strict or loose and we want code to
explicitly choose one or the other.
Also renamed the Compare function to IsEqualTo, to
avoid confusion.
<rdar://problem/12856749>
llvm-svn: 170152
When using the same-device optimization for shared cache libraries, if
we have an invalid load address for __LINKEDIT, don't try to read
anything out of lldb's own address space. Reading it out of the remote
address space will fail gracefully if we have bad addresses but reading
it out of lldb's own address space will result in a crash.
llvm-svn: 169582
Allow the expression parser to see more than just data symbols. We now accept any symbol that has an address. We take precautions to only accept symbols by their mangled or demangled names only if the demangled name was not synthesized. If the demangled name is synthesized, then we now mark symbols accordingly and only compare against the mangled original name.
llvm-svn: 168668
RegisterContextKDP_i386 was not correctly writing registers due to missing "virtual" keywords. Added the virtual keywords and made the functions pure virtual to ensure subclasses can't get away without implementing these functions.
llvm-svn: 167066
is being run on iOS natively and we are examining a binary that is
in the shared-cache. The shared cache may be set up to not load the
symbol names in memory (and may be missing some local symbols entirely,
to boot) so we need to read the on-disk-but-not-mapped-into-memory cache
of symbol names/symbols before we start processing the in-memory nlist
entries.
This code needs to be reorganized into its own separate method, ideally
we'll find some way to not duplicate the nlist symbol handling. But
we need to handle this new format quickly and we'll clean up later.
Thanks for James McIlree for the patch. Fixes <rdar://problem/11639018>.
llvm-svn: 158891
a cache of address ranges for child sections,
accelerating lookups. This cache is built during
object file loading, and is then set in stone once
the object files are done loading. (In Debug builds,
we ensure that the cache is never invalidated after
that.)
llvm-svn: 158188
Fixed an issue with the symbol table parsing of files that have STAB entries in them where there are two N_SO entries where the first has a directory, and the second contains a full path:
[ 0] 00000002 64 (N_SO ) 00 0000 0000000000000000 '/Volumes/data/src/'
[ 1] 0000001e 64 (N_SO ) 00 0000 0000000000000000 '/Volumes/data/src/Source/main.m'
[ 2] 00000047 66 (N_OSO ) 09 0001 000000004fc642d2 '/tmp/main.o'
[ 3] 00000001 2e (N_BNSYM ) 01 0000 0000000000003864
[ 4] 000000bd 24 (N_FUN ) 01 0000 0000000000003864 '_main'
[ 5] 00000001 24 (N_FUN ) 00 0000 00000000000000ae
[ 6] 00000001 4e (N_ENSYM ) 01 0000 00000000000000ae
[ 7] 00000001 64 (N_SO ) 01 0000 0000000000000000
We now correctly combine entries 0 and 1 into a single entry.
llvm-svn: 157712
