ModuleSpecs::FindMatchingModuleSpec looks for matching filenames but when
looking for the dSYM we should only be looking for a matching architecture and
and UUID. Jason pointed out this mistake in http://reviews.llvm.org/D9174 when
this function was incorrectly converted to not be Mac specific.
Test Plan:
Running LLDB on test/lang/c/shared_lib_stripped_symbols/a.out in a debugger I've
verified LocateDSYMInVincinityOfExecutable correctly locates the matching dSYM.
Differential Revision: http://reviews.llvm.org/D9896
llvm-svn: 237907
Removed some unused variables, added some consts, changed some casts
to const_cast. I don't think any of these changes are very
controversial.
Differential Revision: http://reviews.llvm.org/D9674
llvm-svn: 237218
Currently Symbols::LocateExecutableSymbolFile on MacOSX only looks for external
dsym debugging information, however if running on a stripped dwarf executable it
should also check for a .debug file as well.
Test Plan:
./dotest.py $DOTEST_OPTS -t -p TestSharedLibStrippedSymbols.py
This test now passes when running a remote Mac -> Linux test, and still passes
running locally on Mac or locally on Linux.
Differential Revision: http://reviews.llvm.org/D9174
llvm-svn: 235737
This is part of a larger effort to reduce header file footprints.
Combined, these patches reduce the build time of LLDB locally by
over 30%. However, they touch many files and make many changes,
so will be submitted in small incremental pieces.
Reviewed By: Greg Clayton
Differential Revision: http://reviews.llvm.org/D8022
llvm-svn: 231097
Summary:
Symbols::LocateExecutableSymbolFile tries to locate the file in containing the debug info in a
splitdebug configuration. It tries to skip over the original file in its search path, but it was
easily fooled by symlinks. This changes the function to use llvm::sys::fs::equivalent, which can
correctly compare symlinks.
As a side effect, I had to fix one test because the address for the "abort" function resolves on
my system to "__GI_abort" now. With the debug info, the libc on my system contains two symbols
associated with the address of the abort function, and lldb prefers __GI_abort, possibly because
the debug info is associated with it. It would be nice at some point to have it prefer the public
symbol name.
Reviewers: emaste, zturner
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D7836
llvm-svn: 230476
Partial fix for the above radar where we now resolve dsym mach-o files within the dSYM bundle when using "add-dsym" through the platform.
llvm-svn: 163676
more of the local path, platform path, associated symbol file, UUID, arch,
object name and object offset. This allows many of the calls that were
GetSharedModule to reduce the number of arguments that were used in a call
to these functions. It also allows a module to be created with a ModuleSpec
which allows many things to be specified prior to any accessors being called
on the Module class itself.
I was running into problems when adding support for "target symbol add"
where you can specify a stand alone debug info file after debugging has started
where I needed to specify the associated symbol file path and if I waited until
after construction, the wrong symbol file had already been located. By using
the ModuleSpec it allows us to construct a module with as little or as much
information as needed and not have to change the parameter list.
llvm-svn: 151476
Robert Flack