2019-05-13 12:42:32 +08:00
|
|
|
//===-- LocateSymbolFile.cpp ------------------------------------*- C++ -*-===//
|
2010-07-03 03:28:44 +08:00
|
|
|
//
|
2019-01-19 16:50:56 +08:00
|
|
|
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
|
|
|
|
// See https://llvm.org/LICENSE.txt for license information.
|
|
|
|
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
|
2010-07-03 03:28:44 +08:00
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
Move Host/Symbols.cpp to Symbols/LocateSymbolFile.cpp
Given that we have a target named Symbols, one wonders why a
file named Symbols.cpp is not in this target. To be clear,
the functions exposed from this file are really focused on
*locating* a symbol file on a given host, which is where the
ambiguity comes in. However, it makes more sense conceptually
to be in the Symbols target. While some of the specific places
to search for symbol files might change depending on the Host,
this is not inherently true in the same way that, for example,
"accessing the file system" or "starting threads" is
fundamentally dependent on the Host.
PDBs, for example, recently became a reality on non-Windows platforms,
and it's theoretically possible that DSYMs could become a thing on non
MacOSX platforms (maybe in a remote debugging scenario). Other types of
symbol files, such as DWO, DWP, etc have never been tied to any Host
platform anyway.
After this patch, there is only one remaining dependency from
Host to Target.
Differential Revision: https://reviews.llvm.org/D58730
llvm-svn: 355032
2019-02-28 05:42:10 +08:00
|
|
|
#include "lldb/Symbol/LocateSymbolFile.h"
|
|
|
|
|
2019-03-07 02:20:23 +08:00
|
|
|
#include "lldb/Core/ModuleList.h"
|
2013-07-02 03:45:50 +08:00
|
|
|
#include "lldb/Core/ModuleSpec.h"
|
2018-02-05 18:50:38 +08:00
|
|
|
#include "lldb/Host/FileSystem.h"
|
2013-07-02 03:45:50 +08:00
|
|
|
#include "lldb/Symbol/ObjectFile.h"
|
2017-11-14 00:16:33 +08:00
|
|
|
#include "lldb/Utility/ArchSpec.h"
|
2017-03-04 09:30:05 +08:00
|
|
|
#include "lldb/Utility/DataBuffer.h"
|
|
|
|
#include "lldb/Utility/DataExtractor.h"
|
2017-03-04 04:56:28 +08:00
|
|
|
#include "lldb/Utility/Log.h"
|
2017-02-03 05:39:50 +08:00
|
|
|
#include "lldb/Utility/StreamString.h"
|
2017-06-29 22:32:17 +08:00
|
|
|
#include "lldb/Utility/Timer.h"
|
2017-03-04 09:30:05 +08:00
|
|
|
#include "lldb/Utility/UUID.h"
|
2010-07-03 03:28:44 +08:00
|
|
|
|
2015-03-04 02:34:26 +08:00
|
|
|
#include "llvm/Support/FileSystem.h"
|
|
|
|
|
2015-04-25 02:09:54 +08:00
|
|
|
// From MacOSX system header "mach/machine.h"
|
|
|
|
typedef int cpu_type_t;
|
|
|
|
typedef int cpu_subtype_t;
|
|
|
|
|
2010-07-03 03:28:44 +08:00
|
|
|
using namespace lldb;
|
|
|
|
using namespace lldb_private;
|
|
|
|
|
2015-04-25 02:09:54 +08:00
|
|
|
#if defined(__APPLE__)
|
2013-07-02 03:45:50 +08:00
|
|
|
|
2015-04-25 02:09:54 +08:00
|
|
|
// Forward declaration of method defined in source/Host/macosx/Symbols.cpp
|
|
|
|
int LocateMacOSXFilesUsingDebugSymbols(const ModuleSpec &module_spec,
|
2015-10-09 05:48:35 +08:00
|
|
|
ModuleSpec &return_module_spec);
|
2013-07-02 03:45:50 +08:00
|
|
|
|
2015-04-25 02:09:54 +08:00
|
|
|
#else
|
2013-07-02 03:45:50 +08:00
|
|
|
|
2015-04-25 02:09:54 +08:00
|
|
|
int LocateMacOSXFilesUsingDebugSymbols(const ModuleSpec &module_spec,
|
2015-10-09 05:48:35 +08:00
|
|
|
ModuleSpec &return_module_spec) {
|
2015-04-25 02:09:54 +08:00
|
|
|
// Cannot find MacOSX files using debug symbols on non MacOSX.
|
|
|
|
return 0;
|
|
|
|
}
|
2013-07-02 03:45:50 +08:00
|
|
|
|
2015-04-25 02:09:54 +08:00
|
|
|
#endif
|
2013-07-02 03:45:50 +08:00
|
|
|
|
2015-05-21 23:44:24 +08:00
|
|
|
static bool FileAtPathContainsArchAndUUID(const FileSpec &file_fspec,
|
|
|
|
const ArchSpec *arch,
|
|
|
|
const lldb_private::UUID *uuid) {
|
|
|
|
ModuleSpecList module_specs;
|
|
|
|
if (ObjectFile::GetModuleSpecifications(file_fspec, 0, 0, module_specs)) {
|
|
|
|
ModuleSpec spec;
|
|
|
|
for (size_t i = 0; i < module_specs.GetSize(); ++i) {
|
2017-02-16 10:08:33 +08:00
|
|
|
bool got_spec = module_specs.GetModuleSpecAtIndex(i, spec);
|
2017-03-23 17:52:26 +08:00
|
|
|
UNUSED_IF_ASSERT_DISABLED(got_spec);
|
2017-02-16 10:08:33 +08:00
|
|
|
assert(got_spec);
|
[lldb] NFC modernize codebase with modernize-use-nullptr
Summary:
NFC = [[ https://llvm.org/docs/Lexicon.html#nfc | Non functional change ]]
This commit is the result of modernizing the LLDB codebase by using
`nullptr` instread of `0` or `NULL`. See
https://clang.llvm.org/extra/clang-tidy/checks/modernize-use-nullptr.html
for more information.
This is the command I ran and I to fix and format the code base:
```
run-clang-tidy.py \
-header-filter='.*' \
-checks='-*,modernize-use-nullptr' \
-fix ~/dev/llvm-project/lldb/.* \
-format \
-style LLVM \
-p ~/llvm-builds/debug-ninja-gcc
```
NOTE: There were also changes to `llvm/utils/unittest` but I did not
include them because I felt that maybe this library shall be updated in
isolation somehow.
NOTE: I know this is a rather large commit but it is a nobrainer in most
parts.
Reviewers: martong, espindola, shafik, #lldb, JDevlieghere
Reviewed By: JDevlieghere
Subscribers: arsenm, jvesely, nhaehnle, hiraditya, JDevlieghere, teemperor, rnkovacs, emaste, kubamracek, nemanjai, ki.stfu, javed.absar, arichardson, kbarton, jrtc27, MaskRay, atanasyan, dexonsmith, arphaman, jfb, jsji, jdoerfert, lldb-commits, llvm-commits
Tags: #lldb, #llvm
Differential Revision: https://reviews.llvm.org/D61847
llvm-svn: 361484
2019-05-23 19:14:47 +08:00
|
|
|
if ((uuid == nullptr || (spec.GetUUIDPtr() && spec.GetUUID() == *uuid)) &&
|
|
|
|
(arch == nullptr ||
|
|
|
|
(spec.GetArchitecturePtr() &&
|
|
|
|
spec.GetArchitecture().IsCompatibleMatch(*arch)))) {
|
2015-05-21 23:44:24 +08:00
|
|
|
return true;
|
|
|
|
}
|
|
|
|
}
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
2015-05-21 23:44:24 +08:00
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2018-10-17 05:49:31 +08:00
|
|
|
// Given a binary exec_fspec, and a ModuleSpec with an architecture/uuid,
|
|
|
|
// return true if there is a matching dSYM bundle next to the exec_fspec,
|
Move Host/Symbols.cpp to Symbols/LocateSymbolFile.cpp
Given that we have a target named Symbols, one wonders why a
file named Symbols.cpp is not in this target. To be clear,
the functions exposed from this file are really focused on
*locating* a symbol file on a given host, which is where the
ambiguity comes in. However, it makes more sense conceptually
to be in the Symbols target. While some of the specific places
to search for symbol files might change depending on the Host,
this is not inherently true in the same way that, for example,
"accessing the file system" or "starting threads" is
fundamentally dependent on the Host.
PDBs, for example, recently became a reality on non-Windows platforms,
and it's theoretically possible that DSYMs could become a thing on non
MacOSX platforms (maybe in a remote debugging scenario). Other types of
symbol files, such as DWO, DWP, etc have never been tied to any Host
platform anyway.
After this patch, there is only one remaining dependency from
Host to Target.
Differential Revision: https://reviews.llvm.org/D58730
llvm-svn: 355032
2019-02-28 05:42:10 +08:00
|
|
|
// and return that value in dsym_fspec.
|
|
|
|
// If there is a .dSYM.yaa compressed archive next to the exec_fspec,
|
2018-10-17 05:49:31 +08:00
|
|
|
// call through Symbols::DownloadObjectAndSymbolFile to download the
|
|
|
|
// expanded/uncompressed dSYM and return that filepath in dsym_fspec.
|
|
|
|
|
|
|
|
static bool LookForDsymNextToExecutablePath(const ModuleSpec &mod_spec,
|
|
|
|
const FileSpec &exec_fspec,
|
|
|
|
FileSpec &dsym_fspec) {
|
|
|
|
ConstString filename = exec_fspec.GetFilename();
|
|
|
|
FileSpec dsym_directory = exec_fspec;
|
|
|
|
dsym_directory.RemoveLastPathComponent();
|
|
|
|
|
|
|
|
std::string dsym_filename = filename.AsCString();
|
|
|
|
dsym_filename += ".dSYM";
|
|
|
|
dsym_directory.AppendPathComponent(dsym_filename);
|
|
|
|
dsym_directory.AppendPathComponent("Contents");
|
|
|
|
dsym_directory.AppendPathComponent("Resources");
|
|
|
|
dsym_directory.AppendPathComponent("DWARF");
|
2018-11-02 01:09:25 +08:00
|
|
|
|
|
|
|
if (FileSystem::Instance().Exists(dsym_directory)) {
|
2018-10-17 05:49:31 +08:00
|
|
|
|
|
|
|
// See if the binary name exists in the dSYM DWARF
|
|
|
|
// subdir.
|
|
|
|
dsym_fspec = dsym_directory;
|
|
|
|
dsym_fspec.AppendPathComponent(filename.AsCString());
|
2018-11-02 01:09:25 +08:00
|
|
|
if (FileSystem::Instance().Exists(dsym_fspec) &&
|
|
|
|
FileAtPathContainsArchAndUUID(dsym_fspec, mod_spec.GetArchitecturePtr(),
|
|
|
|
mod_spec.GetUUIDPtr())) {
|
2018-10-17 05:49:31 +08:00
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
// See if we have "../CF.framework" - so we'll look for
|
|
|
|
// CF.framework.dSYM/Contents/Resources/DWARF/CF
|
Move Host/Symbols.cpp to Symbols/LocateSymbolFile.cpp
Given that we have a target named Symbols, one wonders why a
file named Symbols.cpp is not in this target. To be clear,
the functions exposed from this file are really focused on
*locating* a symbol file on a given host, which is where the
ambiguity comes in. However, it makes more sense conceptually
to be in the Symbols target. While some of the specific places
to search for symbol files might change depending on the Host,
this is not inherently true in the same way that, for example,
"accessing the file system" or "starting threads" is
fundamentally dependent on the Host.
PDBs, for example, recently became a reality on non-Windows platforms,
and it's theoretically possible that DSYMs could become a thing on non
MacOSX platforms (maybe in a remote debugging scenario). Other types of
symbol files, such as DWO, DWP, etc have never been tied to any Host
platform anyway.
After this patch, there is only one remaining dependency from
Host to Target.
Differential Revision: https://reviews.llvm.org/D58730
llvm-svn: 355032
2019-02-28 05:42:10 +08:00
|
|
|
// We need to drop the last suffix after '.' to match
|
2018-10-17 05:49:31 +08:00
|
|
|
// 'CF' in the DWARF subdir.
|
Move Host/Symbols.cpp to Symbols/LocateSymbolFile.cpp
Given that we have a target named Symbols, one wonders why a
file named Symbols.cpp is not in this target. To be clear,
the functions exposed from this file are really focused on
*locating* a symbol file on a given host, which is where the
ambiguity comes in. However, it makes more sense conceptually
to be in the Symbols target. While some of the specific places
to search for symbol files might change depending on the Host,
this is not inherently true in the same way that, for example,
"accessing the file system" or "starting threads" is
fundamentally dependent on the Host.
PDBs, for example, recently became a reality on non-Windows platforms,
and it's theoretically possible that DSYMs could become a thing on non
MacOSX platforms (maybe in a remote debugging scenario). Other types of
symbol files, such as DWO, DWP, etc have never been tied to any Host
platform anyway.
After this patch, there is only one remaining dependency from
Host to Target.
Differential Revision: https://reviews.llvm.org/D58730
llvm-svn: 355032
2019-02-28 05:42:10 +08:00
|
|
|
std::string binary_name(filename.AsCString());
|
2018-10-17 05:49:31 +08:00
|
|
|
auto last_dot = binary_name.find_last_of('.');
|
|
|
|
if (last_dot != std::string::npos) {
|
|
|
|
binary_name.erase(last_dot);
|
|
|
|
dsym_fspec = dsym_directory;
|
|
|
|
dsym_fspec.AppendPathComponent(binary_name);
|
2018-11-02 01:09:25 +08:00
|
|
|
if (FileSystem::Instance().Exists(dsym_fspec) &&
|
|
|
|
FileAtPathContainsArchAndUUID(dsym_fspec,
|
|
|
|
mod_spec.GetArchitecturePtr(),
|
|
|
|
mod_spec.GetUUIDPtr())) {
|
2018-10-17 05:49:31 +08:00
|
|
|
return true;
|
|
|
|
}
|
|
|
|
}
|
2018-11-02 01:09:25 +08:00
|
|
|
}
|
|
|
|
|
2018-10-17 05:49:31 +08:00
|
|
|
// See if we have a .dSYM.yaa next to this executable path.
|
|
|
|
FileSpec dsym_yaa_fspec = exec_fspec;
|
|
|
|
dsym_yaa_fspec.RemoveLastPathComponent();
|
|
|
|
std::string dsym_yaa_filename = filename.AsCString();
|
|
|
|
dsym_yaa_filename += ".dSYM.yaa";
|
|
|
|
dsym_yaa_fspec.AppendPathComponent(dsym_yaa_filename);
|
|
|
|
|
2018-11-02 01:09:25 +08:00
|
|
|
if (FileSystem::Instance().Exists(dsym_yaa_fspec)) {
|
2018-10-17 05:49:31 +08:00
|
|
|
ModuleSpec mutable_mod_spec = mod_spec;
|
2018-11-02 01:09:25 +08:00
|
|
|
if (Symbols::DownloadObjectAndSymbolFile(mutable_mod_spec, true) &&
|
|
|
|
FileSystem::Instance().Exists(mutable_mod_spec.GetSymbolFileSpec())) {
|
2018-10-17 05:49:31 +08:00
|
|
|
dsym_fspec = mutable_mod_spec.GetSymbolFileSpec();
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Given a ModuleSpec with a FileSpec and optionally uuid/architecture
|
|
|
|
// filled in, look for a .dSYM bundle next to that binary. Returns true
|
|
|
|
// if a .dSYM bundle is found, and that path is returned in the dsym_fspec
|
|
|
|
// FileSpec.
|
|
|
|
//
|
|
|
|
// This routine looks a few directory layers above the given exec_path -
|
|
|
|
// exec_path might be /System/Library/Frameworks/CF.framework/CF and the
|
|
|
|
// dSYM might be /System/Library/Frameworks/CF.framework.dSYM.
|
|
|
|
//
|
|
|
|
// If there is a .dSYM.yaa compressed archive found next to the binary,
|
|
|
|
// we'll call DownloadObjectAndSymbolFile to expand it into a plain .dSYM
|
|
|
|
|
2015-04-25 02:09:54 +08:00
|
|
|
static bool LocateDSYMInVincinityOfExecutable(const ModuleSpec &module_spec,
|
|
|
|
FileSpec &dsym_fspec) {
|
2015-07-25 10:39:42 +08:00
|
|
|
Log *log = lldb_private::GetLogIfAllCategoriesSet(LIBLLDB_LOG_HOST);
|
2018-10-17 05:49:31 +08:00
|
|
|
const FileSpec &exec_fspec = module_spec.GetFileSpec();
|
2015-04-25 02:09:54 +08:00
|
|
|
if (exec_fspec) {
|
Move Host/Symbols.cpp to Symbols/LocateSymbolFile.cpp
Given that we have a target named Symbols, one wonders why a
file named Symbols.cpp is not in this target. To be clear,
the functions exposed from this file are really focused on
*locating* a symbol file on a given host, which is where the
ambiguity comes in. However, it makes more sense conceptually
to be in the Symbols target. While some of the specific places
to search for symbol files might change depending on the Host,
this is not inherently true in the same way that, for example,
"accessing the file system" or "starting threads" is
fundamentally dependent on the Host.
PDBs, for example, recently became a reality on non-Windows platforms,
and it's theoretically possible that DSYMs could become a thing on non
MacOSX platforms (maybe in a remote debugging scenario). Other types of
symbol files, such as DWO, DWP, etc have never been tied to any Host
platform anyway.
After this patch, there is only one remaining dependency from
Host to Target.
Differential Revision: https://reviews.llvm.org/D58730
llvm-svn: 355032
2019-02-28 05:42:10 +08:00
|
|
|
if (::LookForDsymNextToExecutablePath(module_spec, exec_fspec,
|
|
|
|
dsym_fspec)) {
|
|
|
|
if (log) {
|
2019-07-25 01:56:10 +08:00
|
|
|
LLDB_LOGF(log, "dSYM with matching UUID & arch found at %s",
|
|
|
|
dsym_fspec.GetPath().c_str());
|
Move Host/Symbols.cpp to Symbols/LocateSymbolFile.cpp
Given that we have a target named Symbols, one wonders why a
file named Symbols.cpp is not in this target. To be clear,
the functions exposed from this file are really focused on
*locating* a symbol file on a given host, which is where the
ambiguity comes in. However, it makes more sense conceptually
to be in the Symbols target. While some of the specific places
to search for symbol files might change depending on the Host,
this is not inherently true in the same way that, for example,
"accessing the file system" or "starting threads" is
fundamentally dependent on the Host.
PDBs, for example, recently became a reality on non-Windows platforms,
and it's theoretically possible that DSYMs could become a thing on non
MacOSX platforms (maybe in a remote debugging scenario). Other types of
symbol files, such as DWO, DWP, etc have never been tied to any Host
platform anyway.
After this patch, there is only one remaining dependency from
Host to Target.
Differential Revision: https://reviews.llvm.org/D58730
llvm-svn: 355032
2019-02-28 05:42:10 +08:00
|
|
|
}
|
|
|
|
return true;
|
2018-10-17 05:49:31 +08:00
|
|
|
} else {
|
|
|
|
FileSpec parent_dirs = exec_fspec;
|
|
|
|
|
|
|
|
// Remove the binary name from the FileSpec
|
|
|
|
parent_dirs.RemoveLastPathComponent();
|
|
|
|
|
|
|
|
// Add a ".dSYM" name to each directory component of the path,
|
|
|
|
// stripping off components. e.g. we may have a binary like
|
|
|
|
// /S/L/F/Foundation.framework/Versions/A/Foundation and
|
|
|
|
// /S/L/F/Foundation.framework.dSYM
|
|
|
|
//
|
|
|
|
// so we'll need to start with
|
|
|
|
// /S/L/F/Foundation.framework/Versions/A, add the .dSYM part to the
|
|
|
|
// "A", and if that doesn't exist, strip off the "A" and try it again
|
|
|
|
// with "Versions", etc., until we find a dSYM bundle or we've
|
|
|
|
// stripped off enough path components that there's no need to
|
|
|
|
// continue.
|
|
|
|
|
|
|
|
for (int i = 0; i < 4; i++) {
|
|
|
|
// Does this part of the path have a "." character - could it be a
|
|
|
|
// bundle's top level directory?
|
|
|
|
const char *fn = parent_dirs.GetFilename().AsCString();
|
|
|
|
if (fn == nullptr)
|
|
|
|
break;
|
|
|
|
if (::strchr(fn, '.') != nullptr) {
|
Move Host/Symbols.cpp to Symbols/LocateSymbolFile.cpp
Given that we have a target named Symbols, one wonders why a
file named Symbols.cpp is not in this target. To be clear,
the functions exposed from this file are really focused on
*locating* a symbol file on a given host, which is where the
ambiguity comes in. However, it makes more sense conceptually
to be in the Symbols target. While some of the specific places
to search for symbol files might change depending on the Host,
this is not inherently true in the same way that, for example,
"accessing the file system" or "starting threads" is
fundamentally dependent on the Host.
PDBs, for example, recently became a reality on non-Windows platforms,
and it's theoretically possible that DSYMs could become a thing on non
MacOSX platforms (maybe in a remote debugging scenario). Other types of
symbol files, such as DWO, DWP, etc have never been tied to any Host
platform anyway.
After this patch, there is only one remaining dependency from
Host to Target.
Differential Revision: https://reviews.llvm.org/D58730
llvm-svn: 355032
2019-02-28 05:42:10 +08:00
|
|
|
if (::LookForDsymNextToExecutablePath(module_spec, parent_dirs,
|
|
|
|
dsym_fspec)) {
|
2018-10-17 05:49:31 +08:00
|
|
|
if (log) {
|
2019-07-25 01:56:10 +08:00
|
|
|
LLDB_LOGF(log, "dSYM with matching UUID & arch found at %s",
|
|
|
|
dsym_fspec.GetPath().c_str());
|
2017-06-16 12:19:36 +08:00
|
|
|
}
|
2018-10-17 05:49:31 +08:00
|
|
|
return true;
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
2013-07-02 03:45:50 +08:00
|
|
|
}
|
2018-10-17 05:49:31 +08:00
|
|
|
parent_dirs.RemoveLastPathComponent();
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
2013-07-02 03:45:50 +08:00
|
|
|
}
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
2015-04-25 02:09:54 +08:00
|
|
|
dsym_fspec.Clear();
|
|
|
|
return false;
|
2010-07-03 03:28:44 +08:00
|
|
|
}
|
2010-09-08 04:11:56 +08:00
|
|
|
|
2018-12-19 16:57:10 +08:00
|
|
|
static FileSpec LocateExecutableSymbolFileDsym(const ModuleSpec &module_spec) {
|
2015-04-25 02:09:54 +08:00
|
|
|
const FileSpec *exec_fspec = module_spec.GetFileSpecPtr();
|
|
|
|
const ArchSpec *arch = module_spec.GetArchitecturePtr();
|
|
|
|
const UUID *uuid = module_spec.GetUUIDPtr();
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2017-05-15 21:02:37 +08:00
|
|
|
static Timer::Category func_cat(LLVM_PRETTY_FUNCTION);
|
2016-08-10 07:06:08 +08:00
|
|
|
Timer scoped_timer(
|
2017-05-15 21:02:37 +08:00
|
|
|
func_cat,
|
2015-04-25 02:09:54 +08:00
|
|
|
"LocateExecutableSymbolFileDsym (file = %s, arch = %s, uuid = %p)",
|
|
|
|
exec_fspec ? exec_fspec->GetFilename().AsCString("<NULL>") : "<NULL>",
|
|
|
|
arch ? arch->GetArchitectureName() : "<NULL>", (const void *)uuid);
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2015-04-25 02:09:54 +08:00
|
|
|
FileSpec symbol_fspec;
|
2015-10-09 05:48:35 +08:00
|
|
|
ModuleSpec dsym_module_spec;
|
2015-04-25 02:09:54 +08:00
|
|
|
// First try and find the dSYM in the same directory as the executable or in
|
|
|
|
// an appropriate parent directory
|
2018-12-15 08:15:33 +08:00
|
|
|
if (!LocateDSYMInVincinityOfExecutable(module_spec, symbol_fspec)) {
|
2015-04-25 02:09:54 +08:00
|
|
|
// We failed to easily find the dSYM above, so use DebugSymbols
|
2015-10-09 05:48:35 +08:00
|
|
|
LocateMacOSXFilesUsingDebugSymbols(module_spec, dsym_module_spec);
|
|
|
|
} else {
|
|
|
|
dsym_module_spec.GetSymbolFileSpec() = symbol_fspec;
|
|
|
|
}
|
|
|
|
return dsym_module_spec.GetSymbolFileSpec();
|
2015-04-25 02:09:54 +08:00
|
|
|
}
|
2013-07-02 03:45:50 +08:00
|
|
|
|
|
|
|
ModuleSpec Symbols::LocateExecutableObjectFile(const ModuleSpec &module_spec) {
|
2015-10-09 05:48:35 +08:00
|
|
|
ModuleSpec result;
|
2019-11-29 00:02:07 +08:00
|
|
|
const FileSpec &exec_fspec = module_spec.GetFileSpec();
|
2015-04-25 02:09:54 +08:00
|
|
|
const ArchSpec *arch = module_spec.GetArchitecturePtr();
|
|
|
|
const UUID *uuid = module_spec.GetUUIDPtr();
|
2017-05-15 21:02:37 +08:00
|
|
|
static Timer::Category func_cat(LLVM_PRETTY_FUNCTION);
|
2016-08-10 07:06:08 +08:00
|
|
|
Timer scoped_timer(
|
2017-05-15 21:02:37 +08:00
|
|
|
func_cat, "LocateExecutableObjectFile (file = %s, arch = %s, uuid = %p)",
|
2019-11-29 00:02:07 +08:00
|
|
|
exec_fspec ? exec_fspec.GetFilename().AsCString("<NULL>") : "<NULL>",
|
2015-04-25 02:09:54 +08:00
|
|
|
arch ? arch->GetArchitectureName() : "<NULL>", (const void *)uuid);
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2015-04-25 02:09:54 +08:00
|
|
|
ModuleSpecList module_specs;
|
|
|
|
ModuleSpec matched_module_spec;
|
|
|
|
if (exec_fspec &&
|
2019-11-29 00:02:07 +08:00
|
|
|
ObjectFile::GetModuleSpecifications(exec_fspec, 0, 0, module_specs) &&
|
2015-04-25 02:09:54 +08:00
|
|
|
module_specs.FindMatchingModuleSpec(module_spec, matched_module_spec)) {
|
2015-10-09 05:48:35 +08:00
|
|
|
result.GetFileSpec() = exec_fspec;
|
2015-04-25 02:09:54 +08:00
|
|
|
} else {
|
2015-10-09 05:48:35 +08:00
|
|
|
LocateMacOSXFilesUsingDebugSymbols(module_spec, result);
|
2015-04-25 02:09:54 +08:00
|
|
|
}
|
2015-10-09 05:48:35 +08:00
|
|
|
return result;
|
2013-07-02 03:45:50 +08:00
|
|
|
}
|
|
|
|
|
2019-01-04 07:11:06 +08:00
|
|
|
// Keep "symbols.enable-external-lookup" description in sync with this function.
|
|
|
|
|
2019-03-07 02:20:23 +08:00
|
|
|
FileSpec
|
|
|
|
Symbols::LocateExecutableSymbolFile(const ModuleSpec &module_spec,
|
|
|
|
const FileSpecList &default_search_paths) {
|
2015-07-30 20:38:18 +08:00
|
|
|
FileSpec symbol_file_spec = module_spec.GetSymbolFileSpec();
|
2018-11-02 01:09:25 +08:00
|
|
|
if (symbol_file_spec.IsAbsolute() &&
|
|
|
|
FileSystem::Instance().Exists(symbol_file_spec))
|
2015-07-30 20:38:18 +08:00
|
|
|
return symbol_file_spec;
|
|
|
|
|
SymbolVendorELF: Perform build-id lookup even without a debug link
Summary:
The debug link and build-id lookups are two independent ways one can
search for a separate symbol file. However, our implementation in
SymbolVendorELF was tying the two together and refusing to look up the
symbol file based on a build id if the file did not contain a debug
link.
This patch makes it possible to search for the symbol file with
just one of the two methods available. To demonstrate, I split the
build-id-case test into two, so that we test the search using both
methods.
Reviewers: jankratochvil, mgorny, clayborg, espindola, alexshap
Subscribers: emaste, arichardson, MaskRay, lldb-commits
Differential Revision: https://reviews.llvm.org/D65561
llvm-svn: 367994
2019-08-06 16:18:39 +08:00
|
|
|
FileSpecList debug_file_search_paths = default_search_paths;
|
|
|
|
|
|
|
|
// Add module directory.
|
|
|
|
FileSpec module_file_spec = module_spec.GetFileSpec();
|
|
|
|
// We keep the unresolved pathname if it fails.
|
|
|
|
FileSystem::Instance().ResolveSymbolicLink(module_file_spec,
|
|
|
|
module_file_spec);
|
|
|
|
|
|
|
|
ConstString file_dir = module_file_spec.GetDirectory();
|
|
|
|
{
|
|
|
|
FileSpec file_spec(file_dir.AsCString("."));
|
|
|
|
FileSystem::Instance().Resolve(file_spec);
|
|
|
|
debug_file_search_paths.AppendIfUnique(file_spec);
|
|
|
|
}
|
2015-04-25 02:09:54 +08:00
|
|
|
|
SymbolVendorELF: Perform build-id lookup even without a debug link
Summary:
The debug link and build-id lookups are two independent ways one can
search for a separate symbol file. However, our implementation in
SymbolVendorELF was tying the two together and refusing to look up the
symbol file based on a build id if the file did not contain a debug
link.
This patch makes it possible to search for the symbol file with
just one of the two methods available. To demonstrate, I split the
build-id-case test into two, so that we test the search using both
methods.
Reviewers: jankratochvil, mgorny, clayborg, espindola, alexshap
Subscribers: emaste, arichardson, MaskRay, lldb-commits
Differential Revision: https://reviews.llvm.org/D65561
llvm-svn: 367994
2019-08-06 16:18:39 +08:00
|
|
|
if (ModuleList::GetGlobalModuleListProperties().GetEnableExternalLookup()) {
|
2018-02-05 18:50:38 +08:00
|
|
|
|
SymbolVendorELF: Perform build-id lookup even without a debug link
Summary:
The debug link and build-id lookups are two independent ways one can
search for a separate symbol file. However, our implementation in
SymbolVendorELF was tying the two together and refusing to look up the
symbol file based on a build id if the file did not contain a debug
link.
This patch makes it possible to search for the symbol file with
just one of the two methods available. To demonstrate, I split the
build-id-case test into two, so that we test the search using both
methods.
Reviewers: jankratochvil, mgorny, clayborg, espindola, alexshap
Subscribers: emaste, arichardson, MaskRay, lldb-commits
Differential Revision: https://reviews.llvm.org/D65561
llvm-svn: 367994
2019-08-06 16:18:39 +08:00
|
|
|
// Add current working directory.
|
2018-11-02 05:05:36 +08:00
|
|
|
{
|
SymbolVendorELF: Perform build-id lookup even without a debug link
Summary:
The debug link and build-id lookups are two independent ways one can
search for a separate symbol file. However, our implementation in
SymbolVendorELF was tying the two together and refusing to look up the
symbol file based on a build id if the file did not contain a debug
link.
This patch makes it possible to search for the symbol file with
just one of the two methods available. To demonstrate, I split the
build-id-case test into two, so that we test the search using both
methods.
Reviewers: jankratochvil, mgorny, clayborg, espindola, alexshap
Subscribers: emaste, arichardson, MaskRay, lldb-commits
Differential Revision: https://reviews.llvm.org/D65561
llvm-svn: 367994
2019-08-06 16:18:39 +08:00
|
|
|
FileSpec file_spec(".");
|
2018-11-02 05:05:36 +08:00
|
|
|
FileSystem::Instance().Resolve(file_spec);
|
|
|
|
debug_file_search_paths.AppendIfUnique(file_spec);
|
|
|
|
}
|
2015-04-25 02:09:54 +08:00
|
|
|
|
2018-04-10 21:33:45 +08:00
|
|
|
#ifndef _WIN32
|
Add NetBSD path for Debugging Information in Separate Files
Summary:
NetBSD stores debug information files in the `/usr/libdata/debug` path.
This change fixes debugging distribution executables, e.g. `look`(1):
```
$ lldb /usr/bin/look
(lldb) target create "/usr/bin/look"
Current executable set to '/usr/bin/look' (x86_64).
(lldb) b main
Breakpoint 1: where = look`main + 22 at look.c:107, address = 0x0000000000000da6
(lldb) r
Process 23473 launched: '/usr/bin/look' (x86_64)
Process 23473 stopped
* thread #1, stop reason = breakpoint 1.1
frame #0: 0x0000000186600da6 look`main(argc=1, argv=0x00007f7fffc7c488) at look.c:107
104
105 string = NULL;
106 file = _PATH_WORDS;
-> 107 termchar = '\0';
108 while ((ch = getopt(argc, argv, "dft:")) != -1)
109 switch(ch) {
110 case 'd':
(lldb)
```
There is no `/usr/lib/debug` path on NeBSD, so remove it from search.
Sponsored by <The NetBSD Foundation>
Reviewers: jingham, emaste, kettenis, labath, joerg
Reviewed By: labath
Subscribers: aprantl, #lldb
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D31461
llvm-svn: 299023
2017-03-30 03:52:24 +08:00
|
|
|
#if defined(__NetBSD__)
|
SymbolVendorELF: Perform build-id lookup even without a debug link
Summary:
The debug link and build-id lookups are two independent ways one can
search for a separate symbol file. However, our implementation in
SymbolVendorELF was tying the two together and refusing to look up the
symbol file based on a build id if the file did not contain a debug
link.
This patch makes it possible to search for the symbol file with
just one of the two methods available. To demonstrate, I split the
build-id-case test into two, so that we test the search using both
methods.
Reviewers: jankratochvil, mgorny, clayborg, espindola, alexshap
Subscribers: emaste, arichardson, MaskRay, lldb-commits
Differential Revision: https://reviews.llvm.org/D65561
llvm-svn: 367994
2019-08-06 16:18:39 +08:00
|
|
|
// Add /usr/libdata/debug directory.
|
|
|
|
{
|
|
|
|
FileSpec file_spec("/usr/libdata/debug");
|
|
|
|
FileSystem::Instance().Resolve(file_spec);
|
|
|
|
debug_file_search_paths.AppendIfUnique(file_spec);
|
|
|
|
}
|
Add NetBSD path for Debugging Information in Separate Files
Summary:
NetBSD stores debug information files in the `/usr/libdata/debug` path.
This change fixes debugging distribution executables, e.g. `look`(1):
```
$ lldb /usr/bin/look
(lldb) target create "/usr/bin/look"
Current executable set to '/usr/bin/look' (x86_64).
(lldb) b main
Breakpoint 1: where = look`main + 22 at look.c:107, address = 0x0000000000000da6
(lldb) r
Process 23473 launched: '/usr/bin/look' (x86_64)
Process 23473 stopped
* thread #1, stop reason = breakpoint 1.1
frame #0: 0x0000000186600da6 look`main(argc=1, argv=0x00007f7fffc7c488) at look.c:107
104
105 string = NULL;
106 file = _PATH_WORDS;
-> 107 termchar = '\0';
108 while ((ch = getopt(argc, argv, "dft:")) != -1)
109 switch(ch) {
110 case 'd':
(lldb)
```
There is no `/usr/lib/debug` path on NeBSD, so remove it from search.
Sponsored by <The NetBSD Foundation>
Reviewers: jingham, emaste, kettenis, labath, joerg
Reviewed By: labath
Subscribers: aprantl, #lldb
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D31461
llvm-svn: 299023
2017-03-30 03:52:24 +08:00
|
|
|
#else
|
SymbolVendorELF: Perform build-id lookup even without a debug link
Summary:
The debug link and build-id lookups are two independent ways one can
search for a separate symbol file. However, our implementation in
SymbolVendorELF was tying the two together and refusing to look up the
symbol file based on a build id if the file did not contain a debug
link.
This patch makes it possible to search for the symbol file with
just one of the two methods available. To demonstrate, I split the
build-id-case test into two, so that we test the search using both
methods.
Reviewers: jankratochvil, mgorny, clayborg, espindola, alexshap
Subscribers: emaste, arichardson, MaskRay, lldb-commits
Differential Revision: https://reviews.llvm.org/D65561
llvm-svn: 367994
2019-08-06 16:18:39 +08:00
|
|
|
// Add /usr/lib/debug directory.
|
|
|
|
{
|
|
|
|
FileSpec file_spec("/usr/lib/debug");
|
|
|
|
FileSystem::Instance().Resolve(file_spec);
|
|
|
|
debug_file_search_paths.AppendIfUnique(file_spec);
|
|
|
|
}
|
Add NetBSD path for Debugging Information in Separate Files
Summary:
NetBSD stores debug information files in the `/usr/libdata/debug` path.
This change fixes debugging distribution executables, e.g. `look`(1):
```
$ lldb /usr/bin/look
(lldb) target create "/usr/bin/look"
Current executable set to '/usr/bin/look' (x86_64).
(lldb) b main
Breakpoint 1: where = look`main + 22 at look.c:107, address = 0x0000000000000da6
(lldb) r
Process 23473 launched: '/usr/bin/look' (x86_64)
Process 23473 stopped
* thread #1, stop reason = breakpoint 1.1
frame #0: 0x0000000186600da6 look`main(argc=1, argv=0x00007f7fffc7c488) at look.c:107
104
105 string = NULL;
106 file = _PATH_WORDS;
-> 107 termchar = '\0';
108 while ((ch = getopt(argc, argv, "dft:")) != -1)
109 switch(ch) {
110 case 'd':
(lldb)
```
There is no `/usr/lib/debug` path on NeBSD, so remove it from search.
Sponsored by <The NetBSD Foundation>
Reviewers: jingham, emaste, kettenis, labath, joerg
Reviewed By: labath
Subscribers: aprantl, #lldb
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D31461
llvm-svn: 299023
2017-03-30 03:52:24 +08:00
|
|
|
#endif
|
2018-04-10 21:33:45 +08:00
|
|
|
#endif // _WIN32
|
SymbolVendorELF: Perform build-id lookup even without a debug link
Summary:
The debug link and build-id lookups are two independent ways one can
search for a separate symbol file. However, our implementation in
SymbolVendorELF was tying the two together and refusing to look up the
symbol file based on a build id if the file did not contain a debug
link.
This patch makes it possible to search for the symbol file with
just one of the two methods available. To demonstrate, I split the
build-id-case test into two, so that we test the search using both
methods.
Reviewers: jankratochvil, mgorny, clayborg, espindola, alexshap
Subscribers: emaste, arichardson, MaskRay, lldb-commits
Differential Revision: https://reviews.llvm.org/D65561
llvm-svn: 367994
2019-08-06 16:18:39 +08:00
|
|
|
}
|
2015-04-25 02:09:54 +08:00
|
|
|
|
SymbolVendorELF: Perform build-id lookup even without a debug link
Summary:
The debug link and build-id lookups are two independent ways one can
search for a separate symbol file. However, our implementation in
SymbolVendorELF was tying the two together and refusing to look up the
symbol file based on a build id if the file did not contain a debug
link.
This patch makes it possible to search for the symbol file with
just one of the two methods available. To demonstrate, I split the
build-id-case test into two, so that we test the search using both
methods.
Reviewers: jankratochvil, mgorny, clayborg, espindola, alexshap
Subscribers: emaste, arichardson, MaskRay, lldb-commits
Differential Revision: https://reviews.llvm.org/D65561
llvm-svn: 367994
2019-08-06 16:18:39 +08:00
|
|
|
std::string uuid_str;
|
|
|
|
const UUID &module_uuid = module_spec.GetUUID();
|
|
|
|
if (module_uuid.IsValid()) {
|
|
|
|
// Some debug files are stored in the .build-id directory like this:
|
|
|
|
// /usr/lib/debug/.build-id/ff/e7fe727889ad82bb153de2ad065b2189693315.debug
|
|
|
|
uuid_str = module_uuid.GetAsString("");
|
|
|
|
std::transform(uuid_str.begin(), uuid_str.end(), uuid_str.begin(),
|
|
|
|
::tolower);
|
|
|
|
uuid_str.insert(2, 1, '/');
|
|
|
|
uuid_str = uuid_str + ".debug";
|
|
|
|
}
|
2015-04-25 02:09:54 +08:00
|
|
|
|
SymbolVendorELF: Perform build-id lookup even without a debug link
Summary:
The debug link and build-id lookups are two independent ways one can
search for a separate symbol file. However, our implementation in
SymbolVendorELF was tying the two together and refusing to look up the
symbol file based on a build id if the file did not contain a debug
link.
This patch makes it possible to search for the symbol file with
just one of the two methods available. To demonstrate, I split the
build-id-case test into two, so that we test the search using both
methods.
Reviewers: jankratochvil, mgorny, clayborg, espindola, alexshap
Subscribers: emaste, arichardson, MaskRay, lldb-commits
Differential Revision: https://reviews.llvm.org/D65561
llvm-svn: 367994
2019-08-06 16:18:39 +08:00
|
|
|
size_t num_directories = debug_file_search_paths.GetSize();
|
|
|
|
for (size_t idx = 0; idx < num_directories; ++idx) {
|
|
|
|
FileSpec dirspec = debug_file_search_paths.GetFileSpecAtIndex(idx);
|
|
|
|
FileSystem::Instance().Resolve(dirspec);
|
|
|
|
if (!FileSystem::Instance().IsDirectory(dirspec))
|
|
|
|
continue;
|
2016-09-07 04:57:50 +08:00
|
|
|
|
SymbolVendorELF: Perform build-id lookup even without a debug link
Summary:
The debug link and build-id lookups are two independent ways one can
search for a separate symbol file. However, our implementation in
SymbolVendorELF was tying the two together and refusing to look up the
symbol file based on a build id if the file did not contain a debug
link.
This patch makes it possible to search for the symbol file with
just one of the two methods available. To demonstrate, I split the
build-id-case test into two, so that we test the search using both
methods.
Reviewers: jankratochvil, mgorny, clayborg, espindola, alexshap
Subscribers: emaste, arichardson, MaskRay, lldb-commits
Differential Revision: https://reviews.llvm.org/D65561
llvm-svn: 367994
2019-08-06 16:18:39 +08:00
|
|
|
std::vector<std::string> files;
|
|
|
|
std::string dirname = dirspec.GetPath();
|
2016-09-07 04:57:50 +08:00
|
|
|
|
SymbolVendorELF: Perform build-id lookup even without a debug link
Summary:
The debug link and build-id lookups are two independent ways one can
search for a separate symbol file. However, our implementation in
SymbolVendorELF was tying the two together and refusing to look up the
symbol file based on a build id if the file did not contain a debug
link.
This patch makes it possible to search for the symbol file with
just one of the two methods available. To demonstrate, I split the
build-id-case test into two, so that we test the search using both
methods.
Reviewers: jankratochvil, mgorny, clayborg, espindola, alexshap
Subscribers: emaste, arichardson, MaskRay, lldb-commits
Differential Revision: https://reviews.llvm.org/D65561
llvm-svn: 367994
2019-08-06 16:18:39 +08:00
|
|
|
if (!uuid_str.empty())
|
2015-04-25 02:09:54 +08:00
|
|
|
files.push_back(dirname + "/.build-id/" + uuid_str);
|
SymbolVendorELF: Perform build-id lookup even without a debug link
Summary:
The debug link and build-id lookups are two independent ways one can
search for a separate symbol file. However, our implementation in
SymbolVendorELF was tying the two together and refusing to look up the
symbol file based on a build id if the file did not contain a debug
link.
This patch makes it possible to search for the symbol file with
just one of the two methods available. To demonstrate, I split the
build-id-case test into two, so that we test the search using both
methods.
Reviewers: jankratochvil, mgorny, clayborg, espindola, alexshap
Subscribers: emaste, arichardson, MaskRay, lldb-commits
Differential Revision: https://reviews.llvm.org/D65561
llvm-svn: 367994
2019-08-06 16:18:39 +08:00
|
|
|
if (symbol_file_spec.GetFilename()) {
|
|
|
|
files.push_back(dirname + "/" +
|
|
|
|
symbol_file_spec.GetFilename().GetCString());
|
|
|
|
files.push_back(dirname + "/.debug/" +
|
|
|
|
symbol_file_spec.GetFilename().GetCString());
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2015-10-06 18:17:34 +08:00
|
|
|
// Some debug files may stored in the module directory like this:
|
|
|
|
// /usr/lib/debug/usr/lib/library.so.debug
|
|
|
|
if (!file_dir.IsEmpty())
|
SymbolVendorELF: Perform build-id lookup even without a debug link
Summary:
The debug link and build-id lookups are two independent ways one can
search for a separate symbol file. However, our implementation in
SymbolVendorELF was tying the two together and refusing to look up the
symbol file based on a build id if the file did not contain a debug
link.
This patch makes it possible to search for the symbol file with
just one of the two methods available. To demonstrate, I split the
build-id-case test into two, so that we test the search using both
methods.
Reviewers: jankratochvil, mgorny, clayborg, espindola, alexshap
Subscribers: emaste, arichardson, MaskRay, lldb-commits
Differential Revision: https://reviews.llvm.org/D65561
llvm-svn: 367994
2019-08-06 16:18:39 +08:00
|
|
|
files.push_back(dirname + file_dir.AsCString() + "/" +
|
|
|
|
symbol_file_spec.GetFilename().GetCString());
|
|
|
|
}
|
|
|
|
|
|
|
|
const uint32_t num_files = files.size();
|
|
|
|
for (size_t idx_file = 0; idx_file < num_files; ++idx_file) {
|
|
|
|
const std::string &filename = files[idx_file];
|
|
|
|
FileSpec file_spec(filename);
|
|
|
|
FileSystem::Instance().Resolve(file_spec);
|
|
|
|
|
|
|
|
if (llvm::sys::fs::equivalent(file_spec.GetPath(),
|
|
|
|
module_file_spec.GetPath()))
|
|
|
|
continue;
|
|
|
|
|
|
|
|
if (FileSystem::Instance().Exists(file_spec)) {
|
|
|
|
lldb_private::ModuleSpecList specs;
|
|
|
|
const size_t num_specs =
|
|
|
|
ObjectFile::GetModuleSpecifications(file_spec, 0, 0, specs);
|
|
|
|
assert(num_specs <= 1 &&
|
|
|
|
"Symbol Vendor supports only a single architecture");
|
|
|
|
if (num_specs == 1) {
|
|
|
|
ModuleSpec mspec;
|
|
|
|
if (specs.GetModuleSpecAtIndex(0, mspec)) {
|
|
|
|
// Skip the uuids check if module_uuid is invalid. For example,
|
|
|
|
// this happens for *.dwp files since at the moment llvm-dwp
|
|
|
|
// doesn't output build ids, nor does binutils dwp.
|
|
|
|
if (!module_uuid.IsValid() || module_uuid == mspec.GetUUID())
|
|
|
|
return file_spec;
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
2015-04-25 02:09:54 +08:00
|
|
|
}
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
2015-04-25 02:09:54 +08:00
|
|
|
}
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
2015-04-25 02:09:54 +08:00
|
|
|
|
|
|
|
return LocateExecutableSymbolFileDsym(module_spec);
|
2013-07-02 03:45:50 +08:00
|
|
|
}
|
|
|
|
|
2015-04-25 02:09:54 +08:00
|
|
|
#if !defined(__APPLE__)
|
|
|
|
|
2013-07-02 03:45:50 +08:00
|
|
|
FileSpec Symbols::FindSymbolFileInBundle(const FileSpec &symfile_bundle,
|
|
|
|
const lldb_private::UUID *uuid,
|
|
|
|
const ArchSpec *arch) {
|
2015-04-25 02:09:54 +08:00
|
|
|
// FIXME
|
2013-07-02 03:45:50 +08:00
|
|
|
return FileSpec();
|
|
|
|
}
|
|
|
|
|
|
|
|
bool Symbols::DownloadObjectAndSymbolFile(ModuleSpec &module_spec,
|
|
|
|
bool force_lookup) {
|
|
|
|
// Fill in the module_spec.GetFileSpec() for the object file and/or the
|
|
|
|
// module_spec.GetSymbolFileSpec() for the debug symbols file.
|
|
|
|
return false;
|
|
|
|
}
|
2012-09-12 10:03:59 +08:00
|
|
|
|
2010-09-08 04:11:56 +08:00
|
|
|
#endif
|