[lldb][NFC] Fix all formatting errors in .cpp file headers
Summary:
A *.cpp file header in LLDB (and in LLDB) should like this:
```
//===-- TestUtilities.cpp -------------------------------------------------===//
```
However in LLDB most of our source files have arbitrary changes to this format and
these changes are spreading through LLDB as folks usually just use the existing
source files as templates for their new files (most notably the unnecessary
editor language indicator `-*- C++ -*-` is spreading and in every review
someone is pointing out that this is wrong, resulting in people pointing out that this
is done in the same way in other files).
This patch removes most of these inconsistencies including the editor language indicators,
all the different missing/additional '-' characters, files that center the file name, missing
trailing `===//` (mostly caused by clang-format breaking the line).
Reviewers: aprantl, espindola, jfb, shafik, JDevlieghere
Reviewed By: JDevlieghere
Subscribers: dexonsmith, wuzish, emaste, sdardis, nemanjai, kbarton, MaskRay, atanasyan, arphaman, jfb, abidh, jsji, JDevlieghere, usaxena95, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D73258
2020-01-24 08:23:27 +01:00
|
|
|
//===-- ObjectFile.cpp ----------------------------------------------------===//
|
2010-06-08 16:52:24 +00:00
|
|
|
//
|
2019-01-19 08:50:56 +00: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-06-08 16:52:24 +00:00
|
|
|
//
|
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
|
|
|
|
#include "lldb/Symbol/ObjectFile.h"
|
|
|
|
|
#include "lldb/Core/Module.h"
|
2013-04-24 22:29:28 +00:00
|
|
|
#include "lldb/Core/ModuleSpec.h"
|
2010-06-08 16:52:24 +00:00
|
|
|
#include "lldb/Core/PluginManager.h"
|
<rdar://problem/11757916>
Make breakpoint setting by file and line much more efficient by only looking for inlined breakpoint locations if we are setting a breakpoint in anything but a source implementation file. Implementing this complex for a many reasons. Turns out that parsing compile units lazily had some issues with respect to how we need to do things with DWARF in .o files. So the fixes in the checkin for this makes these changes:
- Add a new setting called "target.inline-breakpoint-strategy" which can be set to "never", "always", or "headers". "never" will never try and set any inlined breakpoints (fastest). "always" always looks for inlined breakpoint locations (slowest, but most accurate). "headers", which is the default setting, will only look for inlined breakpoint locations if the breakpoint is set in what are consudered to be header files, which is realy defined as "not in an implementation source file".
- modify the breakpoint setting by file and line to check the current "target.inline-breakpoint-strategy" setting and act accordingly
- Modify compile units to be able to get their language and other info lazily. This allows us to create compile units from the debug map and not have to fill all of the details in, and then lazily discover this information as we go on debuggging. This is needed to avoid parsing all .o files when setting breakpoints in implementation only files (no inlines). Otherwise we would need to parse the .o file, the object file (mach-o in our case) and the symbol file (DWARF in the object file) just to see what the compile unit was.
- modify the "SymbolFileDWARFDebugMap" to subclass lldb_private::Module so that the virtual "GetObjectFile()" and "GetSymbolVendor()" functions can be intercepted when the .o file contenst are later lazilly needed. Prior to this fix, when we first instantiated the "SymbolFileDWARFDebugMap" class, we would also make modules, object files and symbol files for every .o file in the debug map because we needed to fix up the sections in the .o files with information that is in the executable debug map. Now we lazily do this in the DebugMapModule::GetObjectFile()
Cleaned up header includes a bit as well.
llvm-svn: 162860
2012-08-29 21:13:06 +00:00
|
|
|
#include "lldb/Core/Section.h"
|
[Windows] Use information from the PE32 exceptions directory to construct unwind plans
This patch adds an implementation of unwinding using PE EH info. It allows to
get almost ideal call stacks on 64-bit Windows systems (except some epilogue
cases, but I believe that they can be fixed with unwind plan disassembly
augmentation in the future).
To achieve the goal the CallFrameInfo abstraction was made. It is based on the
DWARFCallFrameInfo class interface with a few changes to make it less
DWARF-specific.
To implement the new interface for PECOFF object files the class PECallFrameInfo
was written. It uses the next helper classes:
- UnwindCodesIterator helps to iterate through UnwindCode structures (and
processes chained infos transparently);
- EHProgramBuilder with the use of UnwindCodesIterator constructs EHProgram;
- EHProgram is, by fact, a vector of EHInstructions. It creates an abstraction
over the low-level unwind codes and simplifies work with them. It contains
only the information that is relevant to unwinding in the unified form. Also
the required unwind codes are read from the object file only once with it;
- EHProgramRange allows to take a range of EHProgram and to build an unwind row
for it.
So, PECallFrameInfo builds the EHProgram with EHProgramBuilder, takes the ranges
corresponding to every offset in prologue and builds the rows of the resulted
unwind plan. The resulted plan covers the whole range of the function except the
epilogue.
Reviewers: jasonmolenda, asmith, amccarth, clayborg, JDevlieghere, stella.stamenova, labath, espindola
Reviewed By: jasonmolenda
Subscribers: leonid.mashinskiy, emaste, mgorny, aprantl, arichardson, MaskRay, lldb-commits, llvm-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D67347
llvm-svn: 374528
2019-10-11 09:03:29 +00:00
|
|
|
#include "lldb/Symbol/CallFrameInfo.h"
|
2010-06-08 16:52:24 +00:00
|
|
|
#include "lldb/Symbol/ObjectContainer.h"
|
|
|
|
|
#include "lldb/Symbol/SymbolFile.h"
|
2017-02-02 21:39:50 +00:00
|
|
|
#include "lldb/Target/Process.h"
|
2017-01-19 17:32:50 +00:00
|
|
|
#include "lldb/Target/SectionLoadList.h"
|
2017-02-02 21:39:50 +00:00
|
|
|
#include "lldb/Target/Target.h"
|
2017-03-04 01:30:05 +00:00
|
|
|
#include "lldb/Utility/DataBuffer.h"
|
|
|
|
|
#include "lldb/Utility/DataBufferHeap.h"
|
2022-02-03 13:26:10 +01:00
|
|
|
#include "lldb/Utility/LLDBLog.h"
|
2017-03-03 20:56:28 +00:00
|
|
|
#include "lldb/Utility/Log.h"
|
2017-06-29 14:32:17 +00:00
|
|
|
#include "lldb/Utility/Timer.h"
|
<rdar://problem/11757916>
Make breakpoint setting by file and line much more efficient by only looking for inlined breakpoint locations if we are setting a breakpoint in anything but a source implementation file. Implementing this complex for a many reasons. Turns out that parsing compile units lazily had some issues with respect to how we need to do things with DWARF in .o files. So the fixes in the checkin for this makes these changes:
- Add a new setting called "target.inline-breakpoint-strategy" which can be set to "never", "always", or "headers". "never" will never try and set any inlined breakpoints (fastest). "always" always looks for inlined breakpoint locations (slowest, but most accurate). "headers", which is the default setting, will only look for inlined breakpoint locations if the breakpoint is set in what are consudered to be header files, which is realy defined as "not in an implementation source file".
- modify the breakpoint setting by file and line to check the current "target.inline-breakpoint-strategy" setting and act accordingly
- Modify compile units to be able to get their language and other info lazily. This allows us to create compile units from the debug map and not have to fill all of the details in, and then lazily discover this information as we go on debuggging. This is needed to avoid parsing all .o files when setting breakpoints in implementation only files (no inlines). Otherwise we would need to parse the .o file, the object file (mach-o in our case) and the symbol file (DWARF in the object file) just to see what the compile unit was.
- modify the "SymbolFileDWARFDebugMap" to subclass lldb_private::Module so that the virtual "GetObjectFile()" and "GetSymbolVendor()" functions can be intercepted when the .o file contenst are later lazilly needed. Prior to this fix, when we first instantiated the "SymbolFileDWARFDebugMap" class, we would also make modules, object files and symbol files for every .o file in the debug map because we needed to fix up the sections in the .o files with information that is in the executable debug map. Now we lazily do this in the DebugMapModule::GetObjectFile()
Cleaned up header includes a bit as well.
llvm-svn: 162860
2012-08-29 21:13:06 +00:00
|
|
|
#include "lldb/lldb-private.h"
|
2010-06-08 16:52:24 +00:00
|
|
|
|
Added the ability to cache the finalized symbol tables subsequent debug sessions to start faster.
This is an updated version of the https://reviews.llvm.org/D113789 patch with the following changes:
- We no longer modify modification times of the cache files
- Use LLVM caching and cache pruning instead of making a new cache mechanism (See DataFileCache.h/.cpp)
- Add signature to start of each file since we are not using modification times so we can tell when caches are stale and remove and re-create the cache file as files are changed
- Add settings to control the cache size, disk percentage and expiration in days to keep cache size under control
This patch enables symbol tables to be cached in the LLDB index cache directory. All cache files are in a single directory and the files use unique names to ensure that files from the same path will re-use the same file as files get modified. This means as files change, their cache files will be deleted and updated. The modification time of each of the cache files is not modified so that access based pruning of the cache can be implemented.
The symbol table cache files start with a signature that uniquely identifies a file on disk and contains one or more of the following items:
- object file UUID if available
- object file mod time if available
- object name for BSD archive .o files that are in .a files if available
If none of these signature items are available, then the file will not be cached. This keeps temporary object files from expressions from being cached.
When the cache files are loaded on subsequent debug sessions, the signature is compare and if the file has been modified (uuid changes, mod time changes, or object file mod time changes) then the cache file is deleted and re-created.
Module caching must be enabled by the user before this can be used:
symbols.enable-lldb-index-cache (boolean) = false
(lldb) settings set symbols.enable-lldb-index-cache true
There is also a setting that allows the user to specify a module cache directory that defaults to a directory that defaults to being next to the symbols.clang-modules-cache-path directory in a temp directory:
(lldb) settings show symbols.lldb-index-cache-path
/var/folders/9p/472sr0c55l9b20x2zg36b91h0000gn/C/lldb/IndexCache
If this setting is enabled, the finalized symbol tables will be serialized and saved to disc so they can be quickly loaded next time you debug.
Each module can cache one or more files in the index cache directory. The cache file names must be unique to a file on disk and its architecture and object name for .o files in BSD archives. This allows universal mach-o files to support caching multuple architectures in the same module cache directory. Making the file based on the this info allows this cache file to be deleted and replaced when the file gets updated on disk. This keeps the cache from growing over time during the compile/edit/debug cycle and prevents out of space issues.
If the cache is enabled, the symbol table will be loaded from the cache the next time you debug if the module has not changed.
The cache also has settings to control the size of the cache on disk. Each time LLDB starts up with the index cache enable, the cache will be pruned to ensure it stays within the user defined settings:
(lldb) settings set symbols.lldb-index-cache-expiration-days <days>
A value of zero will disable cache files from expiring when the cache is pruned. The default value is 7 currently.
(lldb) settings set symbols.lldb-index-cache-max-byte-size <size>
A value of zero will disable pruning based on a total byte size. The default value is zero currently.
(lldb) settings set symbols.lldb-index-cache-max-percent <percentage-of-disk-space>
A value of 100 will allow the disc to be filled to the max, a value of zero will disable percentage pruning. The default value is zero.
Reviewed By: labath, wallace
Differential Revision: https://reviews.llvm.org/D115324
2021-12-16 09:59:25 -08:00
|
|
|
#include "llvm/Support/DJB.h"
|
|
|
|
|
|
2010-06-08 16:52:24 +00:00
|
|
|
using namespace lldb;
|
|
|
|
|
using namespace lldb_private;
|
|
|
|
|
|
Add llvm-style RTTI to ObjectFile hierarchy
Summary:
On the heels of D62934, this patch uses the same approach to introduce
llvm RTTI support to the ObjectFile hierarchy. It also replaces the
existing uses of GetPluginName doing run-time type checks with
llvm::dyn_cast and friends.
This formally introduces new dependencies from some other plugins to
ObjectFile plugins. However, I believe this is fine because:
- these dependencies were already kind of there, and the only reason
we could get away with not modeling them explicitly was because the
code was relying on magically knowing what will GetPluginName() return
for a particular kind of object files.
- the dependencies themselves are logical (it makes sense for
SymbolVendorELF to depend on ObjectFileELF), or at least don't
actively get in the way (the JitLoaderGDB->MachO thing).
- they don't introduce any new dependency loops as ObjectFile plugins
don't depend on any other plugins
Reviewers: xiaobai, JDevlieghere, espindola
Subscribers: emaste, mgorny, arichardson, MaskRay, lldb-commits
Differential Revision: https://reviews.llvm.org/D65450
llvm-svn: 367413
2019-07-31 11:57:34 +00:00
|
|
|
char ObjectFile::ID;
|
2022-04-01 15:59:18 -07:00
|
|
|
size_t ObjectFile::g_initial_bytes_to_read = 512;
|
Add llvm-style RTTI to ObjectFile hierarchy
Summary:
On the heels of D62934, this patch uses the same approach to introduce
llvm RTTI support to the ObjectFile hierarchy. It also replaces the
existing uses of GetPluginName doing run-time type checks with
llvm::dyn_cast and friends.
This formally introduces new dependencies from some other plugins to
ObjectFile plugins. However, I believe this is fine because:
- these dependencies were already kind of there, and the only reason
we could get away with not modeling them explicitly was because the
code was relying on magically knowing what will GetPluginName() return
for a particular kind of object files.
- the dependencies themselves are logical (it makes sense for
SymbolVendorELF to depend on ObjectFileELF), or at least don't
actively get in the way (the JitLoaderGDB->MachO thing).
- they don't introduce any new dependency loops as ObjectFile plugins
don't depend on any other plugins
Reviewers: xiaobai, JDevlieghere, espindola
Subscribers: emaste, mgorny, arichardson, MaskRay, lldb-commits
Differential Revision: https://reviews.llvm.org/D65450
llvm-svn: 367413
2019-07-31 11:57:34 +00:00
|
|
|
|
2020-12-23 13:47:52 -08:00
|
|
|
static ObjectFileSP
|
|
|
|
|
CreateObjectFromContainer(const lldb::ModuleSP &module_sp, const FileSpec *file,
|
|
|
|
|
lldb::offset_t file_offset, lldb::offset_t file_size,
|
2022-04-05 13:33:55 -07:00
|
|
|
DataBufferSP data_sp, lldb::offset_t &data_offset) {
|
2020-12-23 13:47:52 -08:00
|
|
|
ObjectContainerCreateInstance callback;
|
|
|
|
|
for (uint32_t idx = 0;
|
|
|
|
|
(callback = PluginManager::GetObjectContainerCreateCallbackAtIndex(
|
|
|
|
|
idx)) != nullptr;
|
|
|
|
|
++idx) {
|
|
|
|
|
std::unique_ptr<ObjectContainer> object_container_up(callback(
|
|
|
|
|
module_sp, data_sp, data_offset, file, file_offset, file_size));
|
|
|
|
|
if (object_container_up)
|
|
|
|
|
return object_container_up->GetObjectFile(file);
|
|
|
|
|
}
|
|
|
|
|
return {};
|
|
|
|
|
}
|
|
|
|
|
|
2025-12-11 10:08:56 -08:00
|
|
|
ObjectFileSP ObjectFile::FindPlugin(const lldb::ModuleSP &module_sp,
|
|
|
|
|
const FileSpec *file,
|
|
|
|
|
lldb::offset_t file_offset,
|
|
|
|
|
lldb::offset_t file_size,
|
|
|
|
|
DataExtractorSP extractor_sp,
|
|
|
|
|
lldb::offset_t &data_offset) {
|
2020-12-23 13:47:52 -08:00
|
|
|
LLDB_SCOPED_TIMERF(
|
|
|
|
|
"ObjectFile::FindPlugin (module = %s, file = %p, file_offset = "
|
|
|
|
|
"0x%8.8" PRIx64 ", file_size = 0x%8.8" PRIx64 ")",
|
|
|
|
|
module_sp->GetFileSpec().GetPath().c_str(),
|
|
|
|
|
static_cast<const void *>(file), static_cast<uint64_t>(file_offset),
|
|
|
|
|
static_cast<uint64_t>(file_size));
|
|
|
|
|
|
|
|
|
|
if (!module_sp)
|
|
|
|
|
return {};
|
|
|
|
|
|
|
|
|
|
if (!file)
|
|
|
|
|
return {};
|
|
|
|
|
|
2025-12-11 10:08:56 -08:00
|
|
|
if (!extractor_sp || !extractor_sp->HasData()) {
|
2020-12-23 13:47:52 -08:00
|
|
|
const bool file_exists = FileSystem::Instance().Exists(*file);
|
|
|
|
|
// We have an object name which most likely means we have a .o file in
|
|
|
|
|
// a static archive (.a file). Try and see if we have a cached archive
|
|
|
|
|
// first without reading any data first
|
|
|
|
|
if (file_exists && module_sp->GetObjectName()) {
|
|
|
|
|
ObjectFileSP object_file_sp = CreateObjectFromContainer(
|
2025-12-11 10:08:56 -08:00
|
|
|
module_sp, file, file_offset, file_size, DataBufferSP(), data_offset);
|
2020-12-23 13:47:52 -08:00
|
|
|
if (object_file_sp)
|
|
|
|
|
return object_file_sp;
|
|
|
|
|
}
|
|
|
|
|
// Ok, we didn't find any containers that have a named object, now lets
|
|
|
|
|
// read the first 512 bytes from the file so the object file and object
|
|
|
|
|
// container plug-ins can use these bytes to see if they can parse this
|
|
|
|
|
// file.
|
|
|
|
|
if (file_size > 0) {
|
2025-12-11 10:08:56 -08:00
|
|
|
DataBufferSP buffer_sp = FileSystem::Instance().CreateDataBuffer(
|
2022-04-01 15:59:18 -07:00
|
|
|
file->GetPath(), g_initial_bytes_to_read, file_offset);
|
2025-12-11 10:08:56 -08:00
|
|
|
extractor_sp = std::make_shared<DataExtractor>();
|
|
|
|
|
extractor_sp->SetData(buffer_sp, data_offset, buffer_sp->GetByteSize());
|
2020-12-23 13:47:52 -08:00
|
|
|
data_offset = 0;
|
|
|
|
|
}
|
|
|
|
|
}
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2025-12-11 10:08:56 -08:00
|
|
|
if (!extractor_sp || !extractor_sp->HasData()) {
|
2020-12-23 13:47:52 -08:00
|
|
|
// Check for archive file with format "/path/to/archive.a(object.o)"
|
|
|
|
|
llvm::SmallString<256> path_with_object;
|
|
|
|
|
module_sp->GetFileSpec().GetPath(path_with_object);
|
|
|
|
|
|
|
|
|
|
FileSpec archive_file;
|
|
|
|
|
ConstString archive_object;
|
|
|
|
|
const bool must_exist = true;
|
|
|
|
|
if (ObjectFile::SplitArchivePathWithObject(path_with_object, archive_file,
|
|
|
|
|
archive_object, must_exist)) {
|
|
|
|
|
file_size = FileSystem::Instance().GetByteSize(archive_file);
|
|
|
|
|
if (file_size > 0) {
|
|
|
|
|
file = &archive_file;
|
|
|
|
|
module_sp->SetFileSpecAndObjectName(archive_file, archive_object);
|
|
|
|
|
// Check if this is a object container by iterating through all
|
|
|
|
|
// object container plugin instances and then trying to get an
|
|
|
|
|
// object file from the container plugins since we had a name.
|
|
|
|
|
// Also, don't read
|
|
|
|
|
// ANY data in case there is data cached in the container plug-ins
|
|
|
|
|
// (like BSD archives caching the contained objects within an
|
|
|
|
|
// file).
|
|
|
|
|
ObjectFileSP object_file_sp = CreateObjectFromContainer(
|
2025-12-11 10:08:56 -08:00
|
|
|
module_sp, file, file_offset, file_size,
|
|
|
|
|
extractor_sp->GetSharedDataBuffer(), data_offset);
|
2020-12-23 13:47:52 -08:00
|
|
|
if (object_file_sp)
|
|
|
|
|
return object_file_sp;
|
|
|
|
|
// We failed to find any cached object files in the container plug-
|
|
|
|
|
// ins, so lets read the first 512 bytes and try again below...
|
2025-12-11 10:08:56 -08:00
|
|
|
DataBufferSP buffer_sp = FileSystem::Instance().CreateDataBuffer(
|
2022-04-01 15:59:18 -07:00
|
|
|
archive_file.GetPath(), g_initial_bytes_to_read, file_offset);
|
2025-12-11 10:08:56 -08:00
|
|
|
extractor_sp = std::make_shared<DataExtractor>(buffer_sp);
|
2011-09-18 18:59:15 +00:00
|
|
|
}
|
2020-12-23 13:47:52 -08:00
|
|
|
}
|
|
|
|
|
}
|
2014-04-04 04:06:10 +00:00
|
|
|
|
2025-12-11 10:08:56 -08:00
|
|
|
if (extractor_sp && extractor_sp->HasData()) {
|
2020-12-23 13:47:52 -08:00
|
|
|
// Check if this is a normal object file by iterating through all
|
|
|
|
|
// object file plugin instances.
|
|
|
|
|
ObjectFileCreateInstance callback;
|
|
|
|
|
for (uint32_t idx = 0;
|
|
|
|
|
(callback = PluginManager::GetObjectFileCreateCallbackAtIndex(idx)) !=
|
|
|
|
|
nullptr;
|
|
|
|
|
++idx) {
|
2025-12-11 10:08:56 -08:00
|
|
|
ObjectFileSP object_file_sp(callback(module_sp, extractor_sp, data_offset,
|
2020-12-23 13:47:52 -08:00
|
|
|
file, file_offset, file_size));
|
|
|
|
|
if (object_file_sp.get())
|
|
|
|
|
return object_file_sp;
|
2013-07-12 22:07:46 +00:00
|
|
|
}
|
2020-12-23 13:47:52 -08:00
|
|
|
|
|
|
|
|
// Check if this is a object container by iterating through all object
|
|
|
|
|
// container plugin instances and then trying to get an object file
|
|
|
|
|
// from the container.
|
2025-12-11 10:08:56 -08:00
|
|
|
DataBufferSP buffer_sp = extractor_sp->GetSharedDataBuffer();
|
2020-12-23 13:47:52 -08:00
|
|
|
ObjectFileSP object_file_sp = CreateObjectFromContainer(
|
2025-12-11 10:08:56 -08:00
|
|
|
module_sp, file, file_offset, file_size, buffer_sp, data_offset);
|
2020-12-23 13:47:52 -08:00
|
|
|
if (object_file_sp)
|
|
|
|
|
return object_file_sp;
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
2020-12-23 13:47:52 -08:00
|
|
|
|
2018-04-30 16:49:04 +00:00
|
|
|
// We didn't find it, so clear our shared pointer in case it contains
|
|
|
|
|
// anything and return an empty shared pointer
|
2020-12-23 13:47:52 -08:00
|
|
|
return {};
|
2013-04-24 22:29:28 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
ObjectFileSP ObjectFile::FindPlugin(const lldb::ModuleSP &module_sp,
|
|
|
|
|
const ProcessSP &process_sp,
|
|
|
|
|
lldb::addr_t header_addr,
|
2022-04-05 13:33:55 -07:00
|
|
|
WritableDataBufferSP data_sp) {
|
2013-04-24 22:29:28 +00:00
|
|
|
ObjectFileSP object_file_sp;
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2012-02-24 01:59:29 +00:00
|
|
|
if (module_sp) {
|
2020-12-21 13:41:57 -08:00
|
|
|
LLDB_SCOPED_TIMERF("ObjectFile::FindPlugin (module = "
|
2017-05-15 13:02:37 +00:00
|
|
|
"%s, process = %p, header_addr = "
|
|
|
|
|
"0x%" PRIx64 ")",
|
2013-04-24 22:29:28 +00:00
|
|
|
module_sp->GetFileSpec().GetPath().c_str(),
|
|
|
|
|
static_cast<void *>(process_sp.get()), header_addr);
|
|
|
|
|
uint32_t idx;
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2018-04-30 16:49:04 +00:00
|
|
|
// Check if this is a normal object file by iterating through all object
|
|
|
|
|
// file plugin instances.
|
2013-04-24 22:29:28 +00:00
|
|
|
ObjectFileCreateMemoryInstance create_callback;
|
2014-04-20 13:17:36 +00:00
|
|
|
for (idx = 0;
|
|
|
|
|
(create_callback =
|
|
|
|
|
PluginManager::GetObjectFileCreateMemoryCallbackAtIndex(idx)) !=
|
|
|
|
|
nullptr;
|
|
|
|
|
++idx) {
|
2013-07-12 22:07:46 +00:00
|
|
|
object_file_sp.reset(
|
|
|
|
|
create_callback(module_sp, data_sp, process_sp, header_addr));
|
|
|
|
|
if (object_file_sp.get())
|
2013-04-24 22:29:28 +00:00
|
|
|
return object_file_sp;
|
|
|
|
|
}
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
2013-04-24 22:29:28 +00:00
|
|
|
|
2018-04-30 16:49:04 +00:00
|
|
|
// We didn't find it, so clear our shared pointer in case it contains
|
|
|
|
|
// anything and return an empty shared pointer
|
2014-04-20 13:17:36 +00:00
|
|
|
object_file_sp.reset();
|
2013-04-24 22:29:28 +00:00
|
|
|
return object_file_sp;
|
|
|
|
|
}
|
|
|
|
|
|
[lldb] Improve error message for unrecognized executables (#97490)
Currently, LLDB prints out a rather unhelpful error message when passed
a file that it doesn't recognize as an executable.
> error: '/path/to/file' doesn't contain any 'host' platform
> architectures: arm64, armv7, armv7f, armv7k, armv7s, armv7m, armv7em,
> armv6m, armv6, armv5, armv4, arm, thumbv7, thumbv7k, thumbv7s,
> thumbv7f, thumbv7m, thumbv7em, thumbv6m, thumbv6, thumbv5, thumbv4t,
> thumb, x86_64, x86_64, arm64, arm64e
I did a quick search internally and found at least 24 instances of users
being confused by this. This patch improves the error message when it
doesn't recognize the file as an executable, but keeps the existing
error message otherwise, i.e. when it's an object file we understand,
but the current platform doesn't support.
2024-07-08 09:29:01 -07:00
|
|
|
bool ObjectFile::IsObjectFile(lldb_private::FileSpec file_spec) {
|
2025-12-11 10:08:56 -08:00
|
|
|
DataExtractorSP extractor_sp;
|
[lldb] Improve error message for unrecognized executables (#97490)
Currently, LLDB prints out a rather unhelpful error message when passed
a file that it doesn't recognize as an executable.
> error: '/path/to/file' doesn't contain any 'host' platform
> architectures: arm64, armv7, armv7f, armv7k, armv7s, armv7m, armv7em,
> armv6m, armv6, armv5, armv4, arm, thumbv7, thumbv7k, thumbv7s,
> thumbv7f, thumbv7m, thumbv7em, thumbv6m, thumbv6, thumbv5, thumbv4t,
> thumb, x86_64, x86_64, arm64, arm64e
I did a quick search internally and found at least 24 instances of users
being confused by this. This patch improves the error message when it
doesn't recognize the file as an executable, but keeps the existing
error message otherwise, i.e. when it's an object file we understand,
but the current platform doesn't support.
2024-07-08 09:29:01 -07:00
|
|
|
offset_t data_offset = 0;
|
|
|
|
|
ModuleSP module_sp = std::make_shared<Module>(file_spec);
|
|
|
|
|
return static_cast<bool>(ObjectFile::FindPlugin(
|
|
|
|
|
module_sp, &file_spec, 0, FileSystem::Instance().GetByteSize(file_spec),
|
2025-12-11 10:08:56 -08:00
|
|
|
extractor_sp, data_offset));
|
[lldb] Improve error message for unrecognized executables (#97490)
Currently, LLDB prints out a rather unhelpful error message when passed
a file that it doesn't recognize as an executable.
> error: '/path/to/file' doesn't contain any 'host' platform
> architectures: arm64, armv7, armv7f, armv7k, armv7s, armv7m, armv7em,
> armv6m, armv6, armv5, armv4, arm, thumbv7, thumbv7k, thumbv7s,
> thumbv7f, thumbv7m, thumbv7em, thumbv6m, thumbv6, thumbv5, thumbv4t,
> thumb, x86_64, x86_64, arm64, arm64e
I did a quick search internally and found at least 24 instances of users
being confused by this. This patch improves the error message when it
doesn't recognize the file as an executable, but keeps the existing
error message otherwise, i.e. when it's an object file we understand,
but the current platform doesn't support.
2024-07-08 09:29:01 -07:00
|
|
|
}
|
|
|
|
|
|
2013-04-24 22:29:28 +00:00
|
|
|
size_t ObjectFile::GetModuleSpecifications(const FileSpec &file,
|
2013-02-06 17:22:03 +00:00
|
|
|
lldb::offset_t file_offset,
|
|
|
|
|
lldb::offset_t file_size,
|
2020-07-09 14:14:36 -07:00
|
|
|
ModuleSpecList &specs,
|
|
|
|
|
DataBufferSP data_sp) {
|
|
|
|
|
if (!data_sp)
|
2022-04-01 15:59:18 -07:00
|
|
|
data_sp = FileSystem::Instance().CreateDataBuffer(
|
|
|
|
|
file.GetPath(), g_initial_bytes_to_read, file_offset);
|
2016-02-18 11:12:18 +00:00
|
|
|
if (data_sp) {
|
2011-09-18 18:59:15 +00:00
|
|
|
if (file_size == 0) {
|
2018-11-01 04:45:28 +00:00
|
|
|
const lldb::offset_t actual_file_size =
|
|
|
|
|
FileSystem::Instance().GetByteSize(file);
|
2013-02-06 17:22:03 +00:00
|
|
|
if (actual_file_size > file_offset)
|
2014-04-04 04:06:10 +00:00
|
|
|
file_size = actual_file_size - file_offset;
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
2014-04-04 04:06:10 +00:00
|
|
|
return ObjectFile::GetModuleSpecifications(file, // file spec
|
|
|
|
|
data_sp, // data bytes
|
|
|
|
|
0, // data offset
|
|
|
|
|
file_offset, // file offset
|
|
|
|
|
file_size, // file length
|
|
|
|
|
specs);
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
2013-04-24 22:29:28 +00:00
|
|
|
return 0;
|
2011-09-18 18:59:15 +00:00
|
|
|
}
|
|
|
|
|
|
2012-02-24 01:59:29 +00:00
|
|
|
size_t ObjectFile::GetModuleSpecifications(
|
|
|
|
|
const lldb_private::FileSpec &file, lldb::DataBufferSP &data_sp,
|
2014-07-02 17:24:07 +00:00
|
|
|
lldb::offset_t data_offset, lldb::offset_t file_offset,
|
2012-02-24 01:59:29 +00:00
|
|
|
lldb::offset_t file_size, lldb_private::ModuleSpecList &specs) {
|
2012-02-05 02:38:54 +00:00
|
|
|
const size_t initial_count = specs.GetSize();
|
2012-02-24 01:59:29 +00:00
|
|
|
ObjectFileGetModuleSpecifications callback;
|
2013-04-24 22:29:28 +00:00
|
|
|
uint32_t i;
|
2012-02-05 02:38:54 +00:00
|
|
|
// Try the ObjectFile plug-ins
|
2013-03-04 21:46:16 +00:00
|
|
|
for (i = 0;
|
2014-04-20 13:17:36 +00:00
|
|
|
(callback =
|
2013-07-10 01:23:25 +00:00
|
|
|
PluginManager::GetObjectFileGetModuleSpecificationsCallbackAtIndex(
|
2016-02-18 11:12:18 +00:00
|
|
|
i)) != nullptr;
|
2013-03-04 21:46:16 +00:00
|
|
|
++i) {
|
2012-02-05 02:38:54 +00:00
|
|
|
if (callback(file, data_sp, data_offset, file_offset, file_size, specs) > 0)
|
2013-03-27 23:08:40 +00:00
|
|
|
return specs.GetSize() - initial_count;
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
|
|
|
|
|
2013-04-29 17:25:54 +00:00
|
|
|
// Try the ObjectContainer plug-ins
|
|
|
|
|
for (i = 0;
|
|
|
|
|
(callback = PluginManager::
|
|
|
|
|
GetObjectContainerGetModuleSpecificationsCallbackAtIndex(i)) !=
|
|
|
|
|
nullptr;
|
2016-09-06 20:57:50 +00:00
|
|
|
++i) {
|
2013-04-29 17:25:54 +00:00
|
|
|
if (callback(file, data_sp, data_offset, file_offset, file_size, specs) > 0)
|
2014-04-04 04:06:10 +00:00
|
|
|
return specs.GetSize() - initial_count;
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
2013-04-24 22:29:28 +00:00
|
|
|
return 0;
|
2012-02-05 02:38:54 +00:00
|
|
|
}
|
|
|
|
|
|
2012-02-24 01:59:29 +00:00
|
|
|
ObjectFile::ObjectFile(const lldb::ModuleSP &module_sp,
|
2013-04-24 22:29:28 +00:00
|
|
|
const FileSpec *file_spec_ptr,
|
2014-07-02 17:24:07 +00:00
|
|
|
lldb::offset_t file_offset, lldb::offset_t length,
|
2025-12-11 10:08:56 -08:00
|
|
|
lldb::DataExtractorSP extractor_sp,
|
|
|
|
|
lldb::offset_t data_offset)
|
2012-02-24 01:59:29 +00:00
|
|
|
: ModuleChild(module_sp),
|
2011-09-18 18:59:15 +00:00
|
|
|
m_file(), // This file could be different from the original module's file
|
|
|
|
|
m_type(eTypeInvalid), m_strata(eStrataInvalid),
|
2025-12-01 14:37:55 -08:00
|
|
|
m_file_offset(file_offset), m_length(length),
|
|
|
|
|
m_data_nsp(std::make_shared<DataExtractor>()), m_process_wp(),
|
2019-02-13 06:25:41 +00:00
|
|
|
m_memory_addr(LLDB_INVALID_ADDRESS), m_sections_up(), m_symtab_up(),
|
2021-11-17 21:18:24 -08:00
|
|
|
m_symtab_once_up(new llvm::once_flag()) {
|
2011-09-18 18:59:15 +00:00
|
|
|
if (file_spec_ptr)
|
|
|
|
|
m_file = *file_spec_ptr;
|
2025-12-11 10:08:56 -08:00
|
|
|
if (extractor_sp && extractor_sp->HasData()) {
|
|
|
|
|
m_data_nsp = extractor_sp;
|
|
|
|
|
// The offset & length fields may be specifying a subset of the
|
|
|
|
|
// total data buffer.
|
|
|
|
|
m_data_nsp->SetData(extractor_sp->GetSharedDataBuffer(), data_offset,
|
|
|
|
|
length);
|
|
|
|
|
}
|
2022-01-31 15:57:48 +01:00
|
|
|
Log *log = GetLog(LLDBLog::Object);
|
2019-07-24 17:56:10 +00:00
|
|
|
LLDB_LOGF(log,
|
|
|
|
|
"%p ObjectFile::ObjectFile() module = %p (%s), file = %s, "
|
|
|
|
|
"file_offset = 0x%8.8" PRIx64 ", size = %" PRIu64,
|
|
|
|
|
static_cast<void *>(this), static_cast<void *>(module_sp.get()),
|
|
|
|
|
module_sp->GetSpecificationDescription().c_str(),
|
|
|
|
|
m_file ? m_file.GetPath().c_str() : "<NULL>", m_file_offset,
|
|
|
|
|
m_length);
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
2012-02-05 02:38:54 +00:00
|
|
|
|
2011-09-18 18:59:15 +00:00
|
|
|
ObjectFile::ObjectFile(const lldb::ModuleSP &module_sp,
|
2012-02-05 02:38:54 +00:00
|
|
|
const ProcessSP &process_sp, lldb::addr_t header_addr,
|
2025-12-11 10:08:56 -08:00
|
|
|
DataExtractorSP header_extractor_sp)
|
2011-09-18 18:59:15 +00:00
|
|
|
: ModuleChild(module_sp), m_file(), m_type(eTypeInvalid),
|
2025-12-01 14:37:55 -08:00
|
|
|
m_strata(eStrataInvalid), m_file_offset(0), m_length(0),
|
|
|
|
|
m_data_nsp(std::make_shared<DataExtractor>()), m_process_wp(process_sp),
|
|
|
|
|
m_memory_addr(header_addr), m_sections_up(), m_symtab_up(),
|
|
|
|
|
m_symtab_once_up(new llvm::once_flag()) {
|
2025-12-11 10:08:56 -08:00
|
|
|
if (header_extractor_sp && header_extractor_sp->HasData())
|
|
|
|
|
m_data_nsp = header_extractor_sp;
|
2022-01-31 15:57:48 +01:00
|
|
|
Log *log = GetLog(LLDBLog::Object);
|
2019-07-24 17:56:10 +00:00
|
|
|
LLDB_LOGF(log,
|
|
|
|
|
"%p ObjectFile::ObjectFile() module = %p (%s), process = %p, "
|
|
|
|
|
"header_addr = 0x%" PRIx64,
|
|
|
|
|
static_cast<void *>(this), static_cast<void *>(module_sp.get()),
|
|
|
|
|
module_sp->GetSpecificationDescription().c_str(),
|
|
|
|
|
static_cast<void *>(process_sp.get()), m_memory_addr);
|
2010-06-08 16:52:24 +00:00
|
|
|
}
|
2010-08-09 23:31:02 +00:00
|
|
|
|
|
|
|
|
ObjectFile::~ObjectFile() {
|
2022-01-31 15:57:48 +01:00
|
|
|
Log *log = GetLog(LLDBLog::Object);
|
2019-07-24 17:56:10 +00:00
|
|
|
LLDB_LOGF(log, "%p ObjectFile::~ObjectFile ()\n", static_cast<void *>(this));
|
2010-08-09 23:31:02 +00:00
|
|
|
}
|
|
|
|
|
|
2011-09-18 18:59:15 +00:00
|
|
|
bool ObjectFile::SetModulesArchitecture(const ArchSpec &new_arch) {
|
2015-06-25 21:46:34 +00:00
|
|
|
ModuleSP module_sp(GetModule());
|
2012-02-24 01:59:29 +00:00
|
|
|
if (module_sp)
|
Added support for the new ".apple_objc" accelerator tables. These tables are
in the same hashed format as the ".apple_names", but they map objective C
class names to all of the methods and class functions. We need to do this
because in the DWARF the methods for Objective C are never contained in the
class definition, they are scattered about at the translation unit level and
they don't even have attributes that say the are contained within the class
itself.
Added 3 new formats which can be used to display data:
eFormatAddressInfo
eFormatHexFloat
eFormatInstruction
eFormatAddressInfo describes an address such as function+offset and file+line,
or symbol + offset, or constant data (c string, 2, 4, 8, or 16 byte constants).
The format character for this is "A", the long format is "address".
eFormatHexFloat will print out the hex float format that compilers tend to use.
The format character for this is "X", the long format is "hex float".
eFormatInstruction will print out disassembly with bytes and it will use the
current target's architecture. The format character for this is "i" (which
used to be being used for the integer format, but the integer format also has
"d", so we gave the "i" format to disassembly), the long format is
"instruction".
Mate the lldb::FormatterChoiceCriterion enumeration private as it should have
been from the start. It is very specialized and doesn't belong in the public
API.
llvm-svn: 143114
2011-10-27 17:55:14 +00:00
|
|
|
return module_sp->SetArchitecture(new_arch);
|
2014-04-04 04:06:10 +00:00
|
|
|
return false;
|
2011-03-19 01:12:21 +00:00
|
|
|
}
|
2014-04-04 04:06:10 +00:00
|
|
|
|
2012-02-05 02:38:54 +00:00
|
|
|
AddressClass ObjectFile::GetAddressClass(addr_t file_addr) {
|
2013-07-10 01:23:25 +00:00
|
|
|
Symtab *symtab = GetSymtab();
|
2011-03-19 01:12:21 +00:00
|
|
|
if (symtab) {
|
2011-03-24 21:19:54 +00:00
|
|
|
Symbol *symbol = symtab->FindSymbolContainingFileAddress(file_addr);
|
2011-03-19 01:12:21 +00:00
|
|
|
if (symbol) {
|
2011-03-24 21:19:54 +00:00
|
|
|
if (symbol->ValueIsAddress()) {
|
2015-06-25 21:46:34 +00:00
|
|
|
const SectionSP section_sp(symbol->GetAddressRef().GetSection());
|
2012-02-24 01:59:29 +00:00
|
|
|
if (section_sp) {
|
2011-03-24 21:19:54 +00:00
|
|
|
const SectionType section_type = section_sp->GetType();
|
2011-03-19 01:12:21 +00:00
|
|
|
switch (section_type) {
|
|
|
|
|
case eSectionTypeInvalid:
|
2018-06-26 13:06:54 +00:00
|
|
|
return AddressClass::eUnknown;
|
2011-03-19 01:12:21 +00:00
|
|
|
case eSectionTypeCode:
|
2018-06-26 13:06:54 +00:00
|
|
|
return AddressClass::eCode;
|
2013-02-27 21:16:04 +00:00
|
|
|
case eSectionTypeContainer:
|
2018-06-26 13:06:54 +00:00
|
|
|
return AddressClass::eUnknown;
|
2011-03-19 01:12:21 +00:00
|
|
|
case eSectionTypeData:
|
Added support for the new ".apple_objc" accelerator tables. These tables are
in the same hashed format as the ".apple_names", but they map objective C
class names to all of the methods and class functions. We need to do this
because in the DWARF the methods for Objective C are never contained in the
class definition, they are scattered about at the translation unit level and
they don't even have attributes that say the are contained within the class
itself.
Added 3 new formats which can be used to display data:
eFormatAddressInfo
eFormatHexFloat
eFormatInstruction
eFormatAddressInfo describes an address such as function+offset and file+line,
or symbol + offset, or constant data (c string, 2, 4, 8, or 16 byte constants).
The format character for this is "A", the long format is "address".
eFormatHexFloat will print out the hex float format that compilers tend to use.
The format character for this is "X", the long format is "hex float".
eFormatInstruction will print out disassembly with bytes and it will use the
current target's architecture. The format character for this is "i" (which
used to be being used for the integer format, but the integer format also has
"d", so we gave the "i" format to disassembly), the long format is
"instruction".
Mate the lldb::FormatterChoiceCriterion enumeration private as it should have
been from the start. It is very specialized and doesn't belong in the public
API.
llvm-svn: 143114
2011-10-27 17:55:14 +00:00
|
|
|
case eSectionTypeDataCString:
|
|
|
|
|
case eSectionTypeDataCStringPointers:
|
2011-03-19 01:12:21 +00:00
|
|
|
case eSectionTypeDataSymbolAddress:
|
|
|
|
|
case eSectionTypeData4:
|
Added support for the new ".apple_objc" accelerator tables. These tables are
in the same hashed format as the ".apple_names", but they map objective C
class names to all of the methods and class functions. We need to do this
because in the DWARF the methods for Objective C are never contained in the
class definition, they are scattered about at the translation unit level and
they don't even have attributes that say the are contained within the class
itself.
Added 3 new formats which can be used to display data:
eFormatAddressInfo
eFormatHexFloat
eFormatInstruction
eFormatAddressInfo describes an address such as function+offset and file+line,
or symbol + offset, or constant data (c string, 2, 4, 8, or 16 byte constants).
The format character for this is "A", the long format is "address".
eFormatHexFloat will print out the hex float format that compilers tend to use.
The format character for this is "X", the long format is "hex float".
eFormatInstruction will print out disassembly with bytes and it will use the
current target's architecture. The format character for this is "i" (which
used to be being used for the integer format, but the integer format also has
"d", so we gave the "i" format to disassembly), the long format is
"instruction".
Mate the lldb::FormatterChoiceCriterion enumeration private as it should have
been from the start. It is very specialized and doesn't belong in the public
API.
llvm-svn: 143114
2011-10-27 17:55:14 +00:00
|
|
|
case eSectionTypeData8:
|
|
|
|
|
case eSectionTypeData16:
|
2011-03-19 01:12:21 +00:00
|
|
|
case eSectionTypeDataPointers:
|
|
|
|
|
case eSectionTypeZeroFill:
|
|
|
|
|
case eSectionTypeDataObjCMessageRefs:
|
|
|
|
|
case eSectionTypeDataObjCCFStrings:
|
|
|
|
|
case eSectionTypeGoSymtab:
|
2018-06-26 13:06:54 +00:00
|
|
|
return AddressClass::eData;
|
2011-03-19 01:12:21 +00:00
|
|
|
case eSectionTypeDebug:
|
|
|
|
|
case eSectionTypeDWARFDebugAbbrev:
|
2018-11-14 13:01:15 +00:00
|
|
|
case eSectionTypeDWARFDebugAbbrevDwo:
|
2011-03-19 01:12:21 +00:00
|
|
|
case eSectionTypeDWARFDebugAddr:
|
Added support for the new ".apple_objc" accelerator tables. These tables are
in the same hashed format as the ".apple_names", but they map objective C
class names to all of the methods and class functions. We need to do this
because in the DWARF the methods for Objective C are never contained in the
class definition, they are scattered about at the translation unit level and
they don't even have attributes that say the are contained within the class
itself.
Added 3 new formats which can be used to display data:
eFormatAddressInfo
eFormatHexFloat
eFormatInstruction
eFormatAddressInfo describes an address such as function+offset and file+line,
or symbol + offset, or constant data (c string, 2, 4, 8, or 16 byte constants).
The format character for this is "A", the long format is "address".
eFormatHexFloat will print out the hex float format that compilers tend to use.
The format character for this is "X", the long format is "hex float".
eFormatInstruction will print out disassembly with bytes and it will use the
current target's architecture. The format character for this is "i" (which
used to be being used for the integer format, but the integer format also has
"d", so we gave the "i" format to disassembly), the long format is
"instruction".
Mate the lldb::FormatterChoiceCriterion enumeration private as it should have
been from the start. It is very specialized and doesn't belong in the public
API.
llvm-svn: 143114
2011-10-27 17:55:14 +00:00
|
|
|
case eSectionTypeDWARFDebugAranges:
|
2017-08-25 13:56:14 +00:00
|
|
|
case eSectionTypeDWARFDebugCuIndex:
|
2011-03-19 01:12:21 +00:00
|
|
|
case eSectionTypeDWARFDebugFrame:
|
Added support for the new ".apple_objc" accelerator tables. These tables are
in the same hashed format as the ".apple_names", but they map objective C
class names to all of the methods and class functions. We need to do this
because in the DWARF the methods for Objective C are never contained in the
class definition, they are scattered about at the translation unit level and
they don't even have attributes that say the are contained within the class
itself.
Added 3 new formats which can be used to display data:
eFormatAddressInfo
eFormatHexFloat
eFormatInstruction
eFormatAddressInfo describes an address such as function+offset and file+line,
or symbol + offset, or constant data (c string, 2, 4, 8, or 16 byte constants).
The format character for this is "A", the long format is "address".
eFormatHexFloat will print out the hex float format that compilers tend to use.
The format character for this is "X", the long format is "hex float".
eFormatInstruction will print out disassembly with bytes and it will use the
current target's architecture. The format character for this is "i" (which
used to be being used for the integer format, but the integer format also has
"d", so we gave the "i" format to disassembly), the long format is
"instruction".
Mate the lldb::FormatterChoiceCriterion enumeration private as it should have
been from the start. It is very specialized and doesn't belong in the public
API.
llvm-svn: 143114
2011-10-27 17:55:14 +00:00
|
|
|
case eSectionTypeDWARFDebugInfo:
|
2018-11-14 13:01:15 +00:00
|
|
|
case eSectionTypeDWARFDebugInfoDwo:
|
2011-03-19 01:12:21 +00:00
|
|
|
case eSectionTypeDWARFDebugLine:
|
2018-09-13 17:06:47 +00:00
|
|
|
case eSectionTypeDWARFDebugLineStr:
|
Added support for the new ".apple_objc" accelerator tables. These tables are
in the same hashed format as the ".apple_names", but they map objective C
class names to all of the methods and class functions. We need to do this
because in the DWARF the methods for Objective C are never contained in the
class definition, they are scattered about at the translation unit level and
they don't even have attributes that say the are contained within the class
itself.
Added 3 new formats which can be used to display data:
eFormatAddressInfo
eFormatHexFloat
eFormatInstruction
eFormatAddressInfo describes an address such as function+offset and file+line,
or symbol + offset, or constant data (c string, 2, 4, 8, or 16 byte constants).
The format character for this is "A", the long format is "address".
eFormatHexFloat will print out the hex float format that compilers tend to use.
The format character for this is "X", the long format is "hex float".
eFormatInstruction will print out disassembly with bytes and it will use the
current target's architecture. The format character for this is "i" (which
used to be being used for the integer format, but the integer format also has
"d", so we gave the "i" format to disassembly), the long format is
"instruction".
Mate the lldb::FormatterChoiceCriterion enumeration private as it should have
been from the start. It is very specialized and doesn't belong in the public
API.
llvm-svn: 143114
2011-10-27 17:55:14 +00:00
|
|
|
case eSectionTypeDWARFDebugLoc:
|
2019-12-23 16:31:36 +01:00
|
|
|
case eSectionTypeDWARFDebugLocDwo:
|
2018-10-23 09:46:15 +00:00
|
|
|
case eSectionTypeDWARFDebugLocLists:
|
2019-12-23 16:31:36 +01:00
|
|
|
case eSectionTypeDWARFDebugLocListsDwo:
|
Added support for the new ".apple_objc" accelerator tables. These tables are
in the same hashed format as the ".apple_names", but they map objective C
class names to all of the methods and class functions. We need to do this
because in the DWARF the methods for Objective C are never contained in the
class definition, they are scattered about at the translation unit level and
they don't even have attributes that say the are contained within the class
itself.
Added 3 new formats which can be used to display data:
eFormatAddressInfo
eFormatHexFloat
eFormatInstruction
eFormatAddressInfo describes an address such as function+offset and file+line,
or symbol + offset, or constant data (c string, 2, 4, 8, or 16 byte constants).
The format character for this is "A", the long format is "address".
eFormatHexFloat will print out the hex float format that compilers tend to use.
The format character for this is "X", the long format is "hex float".
eFormatInstruction will print out disassembly with bytes and it will use the
current target's architecture. The format character for this is "i" (which
used to be being used for the integer format, but the integer format also has
"d", so we gave the "i" format to disassembly), the long format is
"instruction".
Mate the lldb::FormatterChoiceCriterion enumeration private as it should have
been from the start. It is very specialized and doesn't belong in the public
API.
llvm-svn: 143114
2011-10-27 17:55:14 +00:00
|
|
|
case eSectionTypeDWARFDebugMacInfo:
|
2015-12-16 00:22:08 +00:00
|
|
|
case eSectionTypeDWARFDebugMacro:
|
2018-06-01 12:06:45 +00:00
|
|
|
case eSectionTypeDWARFDebugNames:
|
Added support for the new ".apple_objc" accelerator tables. These tables are
in the same hashed format as the ".apple_names", but they map objective C
class names to all of the methods and class functions. We need to do this
because in the DWARF the methods for Objective C are never contained in the
class definition, they are scattered about at the translation unit level and
they don't even have attributes that say the are contained within the class
itself.
Added 3 new formats which can be used to display data:
eFormatAddressInfo
eFormatHexFloat
eFormatInstruction
eFormatAddressInfo describes an address such as function+offset and file+line,
or symbol + offset, or constant data (c string, 2, 4, 8, or 16 byte constants).
The format character for this is "A", the long format is "address".
eFormatHexFloat will print out the hex float format that compilers tend to use.
The format character for this is "X", the long format is "hex float".
eFormatInstruction will print out disassembly with bytes and it will use the
current target's architecture. The format character for this is "i" (which
used to be being used for the integer format, but the integer format also has
"d", so we gave the "i" format to disassembly), the long format is
"instruction".
Mate the lldb::FormatterChoiceCriterion enumeration private as it should have
been from the start. It is very specialized and doesn't belong in the public
API.
llvm-svn: 143114
2011-10-27 17:55:14 +00:00
|
|
|
case eSectionTypeDWARFDebugPubNames:
|
2011-03-19 01:12:21 +00:00
|
|
|
case eSectionTypeDWARFDebugPubTypes:
|
|
|
|
|
case eSectionTypeDWARFDebugRanges:
|
2018-10-10 08:11:15 +00:00
|
|
|
case eSectionTypeDWARFDebugRngLists:
|
2019-11-26 11:00:23 +01:00
|
|
|
case eSectionTypeDWARFDebugRngListsDwo:
|
Added support for the new ".apple_objc" accelerator tables. These tables are
in the same hashed format as the ".apple_names", but they map objective C
class names to all of the methods and class functions. We need to do this
because in the DWARF the methods for Objective C are never contained in the
class definition, they are scattered about at the translation unit level and
they don't even have attributes that say the are contained within the class
itself.
Added 3 new formats which can be used to display data:
eFormatAddressInfo
eFormatHexFloat
eFormatInstruction
eFormatAddressInfo describes an address such as function+offset and file+line,
or symbol + offset, or constant data (c string, 2, 4, 8, or 16 byte constants).
The format character for this is "A", the long format is "address".
eFormatHexFloat will print out the hex float format that compilers tend to use.
The format character for this is "X", the long format is "hex float".
eFormatInstruction will print out disassembly with bytes and it will use the
current target's architecture. The format character for this is "i" (which
used to be being used for the integer format, but the integer format also has
"d", so we gave the "i" format to disassembly), the long format is
"instruction".
Mate the lldb::FormatterChoiceCriterion enumeration private as it should have
been from the start. It is very specialized and doesn't belong in the public
API.
llvm-svn: 143114
2011-10-27 17:55:14 +00:00
|
|
|
case eSectionTypeDWARFDebugStr:
|
2018-11-14 13:01:15 +00:00
|
|
|
case eSectionTypeDWARFDebugStrDwo:
|
2011-03-19 01:12:21 +00:00
|
|
|
case eSectionTypeDWARFDebugStrOffsets:
|
2018-11-14 13:01:15 +00:00
|
|
|
case eSectionTypeDWARFDebugStrOffsetsDwo:
|
2020-02-20 13:42:52 +01:00
|
|
|
case eSectionTypeDWARFDebugTuIndex:
|
2018-05-08 17:19:24 +00:00
|
|
|
case eSectionTypeDWARFDebugTypes:
|
2019-06-12 11:42:42 +00:00
|
|
|
case eSectionTypeDWARFDebugTypesDwo:
|
2011-03-19 01:12:21 +00:00
|
|
|
case eSectionTypeDWARFAppleNames:
|
|
|
|
|
case eSectionTypeDWARFAppleTypes:
|
|
|
|
|
case eSectionTypeDWARFAppleNamespaces:
|
|
|
|
|
case eSectionTypeDWARFAppleObjC:
|
2018-04-29 19:47:48 +00:00
|
|
|
case eSectionTypeDWARFGNUDebugAltLink:
|
2023-07-06 16:49:55 -07:00
|
|
|
case eSectionTypeCTF:
|
2024-12-10 16:37:23 -08:00
|
|
|
case eSectionTypeLLDBFormatters:
|
2024-01-24 12:42:45 -08:00
|
|
|
case eSectionTypeLLDBTypeSummaries:
|
2023-08-29 14:11:41 -07:00
|
|
|
case eSectionTypeSwiftModules:
|
2018-06-26 13:06:54 +00:00
|
|
|
return AddressClass::eDebug;
|
2011-03-19 01:12:21 +00:00
|
|
|
case eSectionTypeEHFrame:
|
|
|
|
|
case eSectionTypeARMexidx:
|
|
|
|
|
case eSectionTypeARMextab:
|
|
|
|
|
case eSectionTypeCompactUnwind:
|
2018-06-26 13:06:54 +00:00
|
|
|
return AddressClass::eRuntime;
|
2011-03-19 01:12:21 +00:00
|
|
|
case eSectionTypeELFSymbolTable:
|
|
|
|
|
case eSectionTypeELFDynamicSymbols:
|
|
|
|
|
case eSectionTypeELFRelocationEntries:
|
|
|
|
|
case eSectionTypeELFDynamicLinkInfo:
|
2025-08-12 15:12:30 -05:00
|
|
|
case eSectionTypeWasmName:
|
2014-04-04 04:06:10 +00:00
|
|
|
case eSectionTypeOther:
|
2018-06-26 13:06:54 +00:00
|
|
|
return AddressClass::eUnknown;
|
2011-12-03 02:30:59 +00:00
|
|
|
case eSectionTypeAbsoluteAddress:
|
2013-10-21 18:40:51 +00:00
|
|
|
// In case of absolute sections decide the address class based on
|
2018-04-30 16:49:04 +00:00
|
|
|
// the symbol type because the section type isn't specify if it is
|
|
|
|
|
// a code or a data section.
|
2013-10-21 18:40:51 +00:00
|
|
|
break;
|
2011-03-19 01:12:21 +00:00
|
|
|
}
|
|
|
|
|
}
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
|
|
|
|
|
2012-02-24 01:59:29 +00:00
|
|
|
const SymbolType symbol_type = symbol->GetType();
|
2011-03-19 01:12:21 +00:00
|
|
|
switch (symbol_type) {
|
|
|
|
|
case eSymbolTypeAny:
|
2018-06-26 13:06:54 +00:00
|
|
|
return AddressClass::eUnknown;
|
2011-03-19 01:12:21 +00:00
|
|
|
case eSymbolTypeAbsolute:
|
2018-06-26 13:06:54 +00:00
|
|
|
return AddressClass::eUnknown;
|
2013-07-01 19:45:50 +00:00
|
|
|
case eSymbolTypeCode:
|
2018-06-26 13:06:54 +00:00
|
|
|
return AddressClass::eCode;
|
2011-03-19 01:12:21 +00:00
|
|
|
case eSymbolTypeTrampoline:
|
2018-06-26 13:06:54 +00:00
|
|
|
return AddressClass::eCode;
|
2011-03-19 01:12:21 +00:00
|
|
|
case eSymbolTypeResolver:
|
2018-06-26 13:06:54 +00:00
|
|
|
return AddressClass::eCode;
|
2011-03-19 01:12:21 +00:00
|
|
|
case eSymbolTypeData:
|
2018-06-26 13:06:54 +00:00
|
|
|
return AddressClass::eData;
|
2011-12-03 02:30:59 +00:00
|
|
|
case eSymbolTypeRuntime:
|
2018-06-26 13:06:54 +00:00
|
|
|
return AddressClass::eRuntime;
|
2013-07-01 19:45:50 +00:00
|
|
|
case eSymbolTypeException:
|
2018-06-26 13:06:54 +00:00
|
|
|
return AddressClass::eRuntime;
|
2011-03-19 01:12:21 +00:00
|
|
|
case eSymbolTypeSourceFile:
|
2018-06-26 13:06:54 +00:00
|
|
|
return AddressClass::eDebug;
|
2011-03-19 01:12:21 +00:00
|
|
|
case eSymbolTypeHeaderFile:
|
2018-06-26 13:06:54 +00:00
|
|
|
return AddressClass::eDebug;
|
2011-03-19 01:12:21 +00:00
|
|
|
case eSymbolTypeObjectFile:
|
2018-06-26 13:06:54 +00:00
|
|
|
return AddressClass::eDebug;
|
2011-03-19 01:12:21 +00:00
|
|
|
case eSymbolTypeCommonBlock:
|
2018-06-26 13:06:54 +00:00
|
|
|
return AddressClass::eDebug;
|
2011-03-19 01:12:21 +00:00
|
|
|
case eSymbolTypeBlock:
|
2018-06-26 13:06:54 +00:00
|
|
|
return AddressClass::eDebug;
|
2011-03-19 01:12:21 +00:00
|
|
|
case eSymbolTypeLocal:
|
2018-06-26 13:06:54 +00:00
|
|
|
return AddressClass::eData;
|
2011-03-19 01:12:21 +00:00
|
|
|
case eSymbolTypeParam:
|
2018-06-26 13:06:54 +00:00
|
|
|
return AddressClass::eData;
|
2013-07-01 19:45:50 +00:00
|
|
|
case eSymbolTypeVariable:
|
2018-06-26 13:06:54 +00:00
|
|
|
return AddressClass::eData;
|
2013-07-01 19:45:50 +00:00
|
|
|
case eSymbolTypeVariableType:
|
2018-06-26 13:06:54 +00:00
|
|
|
return AddressClass::eDebug;
|
2011-03-19 01:12:21 +00:00
|
|
|
case eSymbolTypeLineEntry:
|
2018-06-26 13:06:54 +00:00
|
|
|
return AddressClass::eDebug;
|
2011-03-19 01:12:21 +00:00
|
|
|
case eSymbolTypeLineHeader:
|
2018-06-26 13:06:54 +00:00
|
|
|
return AddressClass::eDebug;
|
2011-03-19 01:12:21 +00:00
|
|
|
case eSymbolTypeScopeBegin:
|
2018-06-26 13:06:54 +00:00
|
|
|
return AddressClass::eDebug;
|
2011-12-03 02:30:59 +00:00
|
|
|
case eSymbolTypeScopeEnd:
|
2018-06-26 13:06:54 +00:00
|
|
|
return AddressClass::eDebug;
|
2011-12-03 02:30:59 +00:00
|
|
|
case eSymbolTypeAdditional:
|
2018-06-26 13:06:54 +00:00
|
|
|
return AddressClass::eUnknown;
|
2011-03-19 01:12:21 +00:00
|
|
|
case eSymbolTypeCompiler:
|
2018-06-26 13:06:54 +00:00
|
|
|
return AddressClass::eDebug;
|
2013-07-01 19:45:50 +00:00
|
|
|
case eSymbolTypeInstrumentation:
|
2018-06-26 13:06:54 +00:00
|
|
|
return AddressClass::eDebug;
|
2011-03-19 01:12:21 +00:00
|
|
|
case eSymbolTypeUndefined:
|
2018-06-26 13:06:54 +00:00
|
|
|
return AddressClass::eUnknown;
|
2011-12-03 02:30:59 +00:00
|
|
|
case eSymbolTypeObjCClass:
|
2018-06-26 13:06:54 +00:00
|
|
|
return AddressClass::eRuntime;
|
2011-12-03 02:30:59 +00:00
|
|
|
case eSymbolTypeObjCMetaClass:
|
2018-06-26 13:06:54 +00:00
|
|
|
return AddressClass::eRuntime;
|
2011-12-03 02:30:59 +00:00
|
|
|
case eSymbolTypeObjCIVar:
|
2018-06-26 13:06:54 +00:00
|
|
|
return AddressClass::eRuntime;
|
2011-03-19 01:12:21 +00:00
|
|
|
case eSymbolTypeReExported:
|
2018-06-26 13:06:54 +00:00
|
|
|
return AddressClass::eRuntime;
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
2011-03-19 01:12:21 +00:00
|
|
|
}
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
2018-06-26 13:06:54 +00:00
|
|
|
return AddressClass::eUnknown;
|
2011-03-19 01:12:21 +00:00
|
|
|
}
|
|
|
|
|
|
2024-08-12 10:57:04 -07:00
|
|
|
WritableDataBufferSP ObjectFile::ReadMemory(const ProcessSP &process_sp,
|
|
|
|
|
lldb::addr_t addr,
|
|
|
|
|
size_t byte_size) {
|
|
|
|
|
WritableDataBufferSP data_sp;
|
2012-02-05 02:38:54 +00:00
|
|
|
if (process_sp) {
|
2019-02-13 06:25:41 +00:00
|
|
|
std::unique_ptr<DataBufferHeap> data_up(new DataBufferHeap(byte_size, 0));
|
2017-05-12 04:51:55 +00:00
|
|
|
Status error;
|
2012-02-05 02:38:54 +00:00
|
|
|
const size_t bytes_read = process_sp->ReadMemory(
|
2019-02-13 06:25:41 +00:00
|
|
|
addr, data_up->GetBytes(), data_up->GetByteSize(), error);
|
2012-02-05 02:38:54 +00:00
|
|
|
if (bytes_read == byte_size)
|
2019-02-13 06:25:41 +00:00
|
|
|
data_sp.reset(data_up.release());
|
2012-02-05 02:38:54 +00:00
|
|
|
}
|
|
|
|
|
return data_sp;
|
|
|
|
|
}
|
|
|
|
|
|
2014-07-02 17:24:07 +00:00
|
|
|
size_t ObjectFile::GetData(lldb::offset_t offset, size_t length,
|
|
|
|
|
DataExtractor &data) const {
|
2025-12-01 14:37:55 -08:00
|
|
|
// The entire file has already been mmap'ed into m_data_nsp, so just copy from
|
2018-04-30 16:49:04 +00:00
|
|
|
// there as the back mmap buffer will be shared with shared pointers.
|
2025-12-01 14:37:55 -08:00
|
|
|
return data.SetData(*m_data_nsp.get(), offset, length);
|
2012-01-12 05:25:17 +00:00
|
|
|
}
|
|
|
|
|
|
2014-07-02 17:24:07 +00:00
|
|
|
size_t ObjectFile::CopyData(lldb::offset_t offset, size_t length,
|
|
|
|
|
void *dst) const {
|
2025-12-01 14:37:55 -08:00
|
|
|
// The entire file has already been mmap'ed into m_data_nsp, so just copy from
|
2018-04-30 16:49:04 +00:00
|
|
|
// there Note that the data remains in target byte order.
|
2025-12-01 14:37:55 -08:00
|
|
|
return m_data_nsp->CopyData(offset, length, dst);
|
2012-01-12 05:25:17 +00:00
|
|
|
}
|
2011-03-19 01:12:21 +00:00
|
|
|
|
2017-10-02 14:35:07 +00:00
|
|
|
size_t ObjectFile::ReadSectionData(Section *section,
|
2014-07-02 17:24:07 +00:00
|
|
|
lldb::offset_t section_offset, void *dst,
|
2017-10-02 14:35:07 +00:00
|
|
|
size_t dst_len) {
|
2014-09-29 08:02:24 +00:00
|
|
|
assert(section);
|
|
|
|
|
section_offset *= section->GetTargetByteSize();
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2013-07-01 19:45:50 +00:00
|
|
|
// If some other objectfile owns this data, pass this to them.
|
|
|
|
|
if (section->GetObjectFile() != this)
|
|
|
|
|
return section->GetObjectFile()->ReadSectionData(section, section_offset,
|
|
|
|
|
dst, dst_len);
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2020-11-10 11:36:59 +01:00
|
|
|
if (!section->IsRelocated())
|
|
|
|
|
RelocateSection(section);
|
|
|
|
|
|
2012-02-09 06:16:32 +00:00
|
|
|
if (IsInMemory()) {
|
2012-02-05 02:38:54 +00:00
|
|
|
ProcessSP process_sp(m_process_wp.lock());
|
|
|
|
|
if (process_sp) {
|
2017-05-12 04:51:55 +00:00
|
|
|
Status error;
|
2013-02-01 21:38:35 +00:00
|
|
|
const addr_t base_load_addr =
|
|
|
|
|
section->GetLoadBaseAddress(&process_sp->GetTarget());
|
|
|
|
|
if (base_load_addr != LLDB_INVALID_ADDRESS)
|
|
|
|
|
return process_sp->ReadMemory(base_load_addr + section_offset, dst,
|
|
|
|
|
dst_len, error);
|
2012-02-05 02:38:54 +00:00
|
|
|
}
|
|
|
|
|
} else {
|
2014-07-02 17:24:07 +00:00
|
|
|
const lldb::offset_t section_file_size = section->GetFileSize();
|
|
|
|
|
if (section_offset < section_file_size) {
|
|
|
|
|
const size_t section_bytes_left = section_file_size - section_offset;
|
|
|
|
|
size_t section_dst_len = dst_len;
|
2012-02-21 17:34:25 +00:00
|
|
|
if (section_dst_len > section_bytes_left)
|
|
|
|
|
section_dst_len = section_bytes_left;
|
|
|
|
|
return CopyData(section->GetFileOffset() + section_offset,
|
|
|
|
|
section_dst_len, dst);
|
2013-01-04 23:20:01 +00:00
|
|
|
} else {
|
|
|
|
|
if (section->GetType() == eSectionTypeZeroFill) {
|
|
|
|
|
const uint64_t section_size = section->GetByteSize();
|
|
|
|
|
const uint64_t section_bytes_left = section_size - section_offset;
|
|
|
|
|
uint64_t section_dst_len = dst_len;
|
|
|
|
|
if (section_dst_len > section_bytes_left)
|
|
|
|
|
section_dst_len = section_bytes_left;
|
2013-08-23 12:44:05 +00:00
|
|
|
memset(dst, 0, section_dst_len);
|
2013-01-04 23:20:01 +00:00
|
|
|
return section_dst_len;
|
|
|
|
|
}
|
2012-02-05 02:38:54 +00:00
|
|
|
}
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
2012-02-05 02:38:54 +00:00
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Get the section data the file on disk
|
2017-10-02 14:35:07 +00:00
|
|
|
size_t ObjectFile::ReadSectionData(Section *section,
|
|
|
|
|
DataExtractor §ion_data) {
|
2013-07-01 19:45:50 +00:00
|
|
|
// If some other objectfile owns this data, pass this to them.
|
|
|
|
|
if (section->GetObjectFile() != this)
|
|
|
|
|
return section->GetObjectFile()->ReadSectionData(section, section_data);
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2020-11-10 11:36:59 +01:00
|
|
|
if (!section->IsRelocated())
|
|
|
|
|
RelocateSection(section);
|
|
|
|
|
|
2012-02-09 06:16:32 +00:00
|
|
|
if (IsInMemory()) {
|
2012-02-05 02:38:54 +00:00
|
|
|
ProcessSP process_sp(m_process_wp.lock());
|
|
|
|
|
if (process_sp) {
|
2013-02-01 21:38:35 +00:00
|
|
|
const addr_t base_load_addr =
|
|
|
|
|
section->GetLoadBaseAddress(&process_sp->GetTarget());
|
|
|
|
|
if (base_load_addr != LLDB_INVALID_ADDRESS) {
|
|
|
|
|
DataBufferSP data_sp(
|
|
|
|
|
ReadMemory(process_sp, base_load_addr, section->GetByteSize()));
|
|
|
|
|
if (data_sp) {
|
|
|
|
|
section_data.SetData(data_sp, 0, data_sp->GetByteSize());
|
|
|
|
|
section_data.SetByteOrder(process_sp->GetByteOrder());
|
|
|
|
|
section_data.SetAddressByteSize(process_sp->GetAddressByteSize());
|
|
|
|
|
return section_data.GetByteSize();
|
2012-02-05 02:38:54 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
2020-11-10 11:36:59 +01:00
|
|
|
|
|
|
|
|
// The object file now contains a full mmap'ed copy of the object file
|
|
|
|
|
// data, so just use this
|
2023-08-03 15:57:28 -07:00
|
|
|
return GetData(section->GetFileOffset(), GetSectionDataSize(section),
|
|
|
|
|
section_data);
|
2012-02-05 02:38:54 +00:00
|
|
|
}
|
|
|
|
|
|
2019-10-08 16:29:39 +00:00
|
|
|
bool ObjectFile::SplitArchivePathWithObject(llvm::StringRef path_with_object,
|
2013-02-06 00:38:25 +00:00
|
|
|
FileSpec &archive_file,
|
|
|
|
|
ConstString &archive_object,
|
|
|
|
|
bool must_exist) {
|
2019-10-08 16:29:39 +00:00
|
|
|
size_t len = path_with_object.size();
|
|
|
|
|
if (len < 2 || path_with_object.back() != ')')
|
|
|
|
|
return false;
|
|
|
|
|
llvm::StringRef archive = path_with_object.substr(0, path_with_object.rfind('('));
|
|
|
|
|
if (archive.empty())
|
|
|
|
|
return false;
|
|
|
|
|
llvm::StringRef object = path_with_object.substr(archive.size() + 1).drop_back();
|
|
|
|
|
archive_file.SetFile(archive, FileSpec::Style::native);
|
|
|
|
|
if (must_exist && !FileSystem::Instance().Exists(archive_file))
|
|
|
|
|
return false;
|
|
|
|
|
archive_object.SetString(object);
|
|
|
|
|
return true;
|
<rdar://problem/11757916>
Make breakpoint setting by file and line much more efficient by only looking for inlined breakpoint locations if we are setting a breakpoint in anything but a source implementation file. Implementing this complex for a many reasons. Turns out that parsing compile units lazily had some issues with respect to how we need to do things with DWARF in .o files. So the fixes in the checkin for this makes these changes:
- Add a new setting called "target.inline-breakpoint-strategy" which can be set to "never", "always", or "headers". "never" will never try and set any inlined breakpoints (fastest). "always" always looks for inlined breakpoint locations (slowest, but most accurate). "headers", which is the default setting, will only look for inlined breakpoint locations if the breakpoint is set in what are consudered to be header files, which is realy defined as "not in an implementation source file".
- modify the breakpoint setting by file and line to check the current "target.inline-breakpoint-strategy" setting and act accordingly
- Modify compile units to be able to get their language and other info lazily. This allows us to create compile units from the debug map and not have to fill all of the details in, and then lazily discover this information as we go on debuggging. This is needed to avoid parsing all .o files when setting breakpoints in implementation only files (no inlines). Otherwise we would need to parse the .o file, the object file (mach-o in our case) and the symbol file (DWARF in the object file) just to see what the compile unit was.
- modify the "SymbolFileDWARFDebugMap" to subclass lldb_private::Module so that the virtual "GetObjectFile()" and "GetSymbolVendor()" functions can be intercepted when the .o file contenst are later lazilly needed. Prior to this fix, when we first instantiated the "SymbolFileDWARFDebugMap" class, we would also make modules, object files and symbol files for every .o file in the debug map because we needed to fix up the sections in the .o files with information that is in the executable debug map. Now we lazily do this in the DebugMapModule::GetObjectFile()
Cleaned up header includes a bit as well.
llvm-svn: 162860
2012-08-29 21:13:06 +00:00
|
|
|
}
|
|
|
|
|
|
2013-07-10 01:23:25 +00:00
|
|
|
void ObjectFile::ClearSymtab() {
|
2013-03-04 21:46:16 +00:00
|
|
|
ModuleSP module_sp(GetModule());
|
|
|
|
|
if (module_sp) {
|
2022-01-31 15:57:48 +01:00
|
|
|
Log *log = GetLog(LLDBLog::Object);
|
2019-07-24 17:56:10 +00:00
|
|
|
LLDB_LOGF(log, "%p ObjectFile::ClearSymtab () symtab = %p",
|
|
|
|
|
static_cast<void *>(this),
|
|
|
|
|
static_cast<void *>(m_symtab_up.get()));
|
2021-11-17 21:18:24 -08:00
|
|
|
// Since we need to clear the symbol table, we need a new llvm::once_flag
|
|
|
|
|
// instance so we can safely create another symbol table
|
|
|
|
|
m_symtab_once_up.reset(new llvm::once_flag());
|
2019-02-13 06:25:41 +00:00
|
|
|
m_symtab_up.reset();
|
2013-07-10 01:23:25 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2015-09-09 10:20:48 +00:00
|
|
|
SectionList *ObjectFile::GetSectionList(bool update_module_section_list) {
|
2019-02-13 06:25:41 +00:00
|
|
|
if (m_sections_up == nullptr) {
|
2015-09-09 10:20:48 +00:00
|
|
|
if (update_module_section_list) {
|
|
|
|
|
ModuleSP module_sp(GetModule());
|
|
|
|
|
if (module_sp) {
|
2016-05-18 01:59:10 +00:00
|
|
|
std::lock_guard<std::recursive_mutex> guard(module_sp->GetMutex());
|
2015-09-09 10:20:48 +00:00
|
|
|
CreateSections(*module_sp->GetUnifiedSectionList());
|
|
|
|
|
}
|
|
|
|
|
} else {
|
|
|
|
|
SectionList unified_section_list;
|
|
|
|
|
CreateSections(unified_section_list);
|
2013-03-04 21:46:16 +00:00
|
|
|
}
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
2019-02-13 06:25:41 +00:00
|
|
|
return m_sections_up.get();
|
2013-03-04 21:46:16 +00:00
|
|
|
}
|
2015-11-10 05:21:54 +00:00
|
|
|
|
|
|
|
|
lldb::SymbolType
|
|
|
|
|
ObjectFile::GetSymbolTypeFromName(llvm::StringRef name,
|
|
|
|
|
lldb::SymbolType symbol_type_hint) {
|
|
|
|
|
if (!name.empty()) {
|
2023-12-16 14:39:37 -08:00
|
|
|
if (name.starts_with("_OBJC_")) {
|
2015-11-10 05:21:54 +00:00
|
|
|
// ObjC
|
2023-12-16 14:39:37 -08:00
|
|
|
if (name.starts_with("_OBJC_CLASS_$_"))
|
2015-11-10 05:21:54 +00:00
|
|
|
return lldb::eSymbolTypeObjCClass;
|
2023-12-16 14:39:37 -08:00
|
|
|
if (name.starts_with("_OBJC_METACLASS_$_"))
|
2015-11-10 05:21:54 +00:00
|
|
|
return lldb::eSymbolTypeObjCMetaClass;
|
2023-12-16 14:39:37 -08:00
|
|
|
if (name.starts_with("_OBJC_IVAR_$_"))
|
2015-11-10 05:21:54 +00:00
|
|
|
return lldb::eSymbolTypeObjCIVar;
|
2023-12-16 14:39:37 -08:00
|
|
|
} else if (name.starts_with(".objc_class_name_")) {
|
2015-11-10 05:21:54 +00:00
|
|
|
// ObjC v1
|
|
|
|
|
return lldb::eSymbolTypeObjCClass;
|
|
|
|
|
}
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
2015-11-10 05:21:54 +00:00
|
|
|
return symbol_type_hint;
|
|
|
|
|
}
|
2016-02-18 11:12:18 +00:00
|
|
|
|
2025-06-09 10:46:50 +02:00
|
|
|
lldb::SectionType
|
|
|
|
|
ObjectFile::GetDWARFSectionTypeFromName(llvm::StringRef name) {
|
|
|
|
|
return llvm::StringSwitch<SectionType>(name)
|
|
|
|
|
.Case("abbrev", eSectionTypeDWARFDebugAbbrev)
|
|
|
|
|
.Case("abbrev.dwo", eSectionTypeDWARFDebugAbbrevDwo)
|
|
|
|
|
.Case("addr", eSectionTypeDWARFDebugAddr)
|
|
|
|
|
.Case("aranges", eSectionTypeDWARFDebugAranges)
|
|
|
|
|
.Case("cu_index", eSectionTypeDWARFDebugCuIndex)
|
|
|
|
|
.Case("frame", eSectionTypeDWARFDebugFrame)
|
|
|
|
|
.Case("info", eSectionTypeDWARFDebugInfo)
|
|
|
|
|
.Case("info.dwo", eSectionTypeDWARFDebugInfoDwo)
|
2025-11-01 20:12:33 -04:00
|
|
|
.Cases({"line", "line.dwo"}, eSectionTypeDWARFDebugLine)
|
|
|
|
|
.Cases({"line_str", "line_str.dwo"}, eSectionTypeDWARFDebugLineStr)
|
2025-06-09 10:46:50 +02:00
|
|
|
.Case("loc", eSectionTypeDWARFDebugLoc)
|
|
|
|
|
.Case("loc.dwo", eSectionTypeDWARFDebugLocDwo)
|
|
|
|
|
.Case("loclists", eSectionTypeDWARFDebugLocLists)
|
|
|
|
|
.Case("loclists.dwo", eSectionTypeDWARFDebugLocListsDwo)
|
|
|
|
|
.Case("macinfo", eSectionTypeDWARFDebugMacInfo)
|
2025-11-01 20:12:33 -04:00
|
|
|
.Cases({"macro", "macro.dwo"}, eSectionTypeDWARFDebugMacro)
|
2025-06-09 10:46:50 +02:00
|
|
|
.Case("names", eSectionTypeDWARFDebugNames)
|
|
|
|
|
.Case("pubnames", eSectionTypeDWARFDebugPubNames)
|
|
|
|
|
.Case("pubtypes", eSectionTypeDWARFDebugPubTypes)
|
|
|
|
|
.Case("ranges", eSectionTypeDWARFDebugRanges)
|
|
|
|
|
.Case("rnglists", eSectionTypeDWARFDebugRngLists)
|
|
|
|
|
.Case("rnglists.dwo", eSectionTypeDWARFDebugRngListsDwo)
|
|
|
|
|
.Case("str", eSectionTypeDWARFDebugStr)
|
|
|
|
|
.Case("str.dwo", eSectionTypeDWARFDebugStrDwo)
|
2025-11-01 20:12:33 -04:00
|
|
|
.Cases({"str_offsets", "str_offs"}, eSectionTypeDWARFDebugStrOffsets)
|
2025-06-09 10:46:50 +02:00
|
|
|
.Case("str_offsets.dwo", eSectionTypeDWARFDebugStrOffsetsDwo)
|
|
|
|
|
.Case("tu_index", eSectionTypeDWARFDebugTuIndex)
|
|
|
|
|
.Case("types", eSectionTypeDWARFDebugTypes)
|
|
|
|
|
.Case("types.dwo", eSectionTypeDWARFDebugTypesDwo)
|
|
|
|
|
.Default(eSectionTypeOther);
|
|
|
|
|
}
|
|
|
|
|
|
Re-land: [lldb] Use vFlash commands when writing to target's flash memory regions
The difference between this and the previous patch is that now we use
ELF physical addresses only for loading objects into the target (and the
rest of the module load address logic still uses virtual addresses).
Summary:
When writing an object file over gdb-remote, use the vFlashErase, vFlashWrite, and vFlashDone commands if the write address is in a flash memory region. A bare metal target may have this kind of setup.
- Update ObjectFileELF to set load addresses using physical addresses. A typical case may be a data section with a physical address in ROM and a virtual address in RAM, which should be loaded to the ROM address.
- Add support for querying the target's qXfer:memory-map, which contains information about flash memory regions, leveraging MemoryRegionInfo data structures with minor modifications
- Update ProcessGDBRemote to use vFlash commands in DoWriteMemory when the target address is in a flash region
Original discussion at http://lists.llvm.org/pipermail/lldb-dev/2018-January/013093.html
Reviewers: clayborg, labath
Reviewed By: labath
Subscribers: llvm-commits, arichardson, emaste, mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D42145
Patch by Owen Shaw <llvm@owenpshaw.net>.
llvm-svn: 327970
2018-03-20 11:56:24 +00:00
|
|
|
std::vector<ObjectFile::LoadableData>
|
|
|
|
|
ObjectFile::GetLoadableData(Target &target) {
|
|
|
|
|
std::vector<LoadableData> loadables;
|
2017-01-19 17:32:50 +00:00
|
|
|
SectionList *section_list = GetSectionList();
|
|
|
|
|
if (!section_list)
|
Re-land: [lldb] Use vFlash commands when writing to target's flash memory regions
The difference between this and the previous patch is that now we use
ELF physical addresses only for loading objects into the target (and the
rest of the module load address logic still uses virtual addresses).
Summary:
When writing an object file over gdb-remote, use the vFlashErase, vFlashWrite, and vFlashDone commands if the write address is in a flash memory region. A bare metal target may have this kind of setup.
- Update ObjectFileELF to set load addresses using physical addresses. A typical case may be a data section with a physical address in ROM and a virtual address in RAM, which should be loaded to the ROM address.
- Add support for querying the target's qXfer:memory-map, which contains information about flash memory regions, leveraging MemoryRegionInfo data structures with minor modifications
- Update ProcessGDBRemote to use vFlash commands in DoWriteMemory when the target address is in a flash region
Original discussion at http://lists.llvm.org/pipermail/lldb-dev/2018-January/013093.html
Reviewers: clayborg, labath
Reviewed By: labath
Subscribers: llvm-commits, arichardson, emaste, mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D42145
Patch by Owen Shaw <llvm@owenpshaw.net>.
llvm-svn: 327970
2018-03-20 11:56:24 +00:00
|
|
|
return loadables;
|
|
|
|
|
// Create a list of loadable data from loadable sections
|
2017-01-19 17:32:50 +00:00
|
|
|
size_t section_count = section_list->GetNumSections(0);
|
|
|
|
|
for (size_t i = 0; i < section_count; ++i) {
|
Re-land: [lldb] Use vFlash commands when writing to target's flash memory regions
The difference between this and the previous patch is that now we use
ELF physical addresses only for loading objects into the target (and the
rest of the module load address logic still uses virtual addresses).
Summary:
When writing an object file over gdb-remote, use the vFlashErase, vFlashWrite, and vFlashDone commands if the write address is in a flash memory region. A bare metal target may have this kind of setup.
- Update ObjectFileELF to set load addresses using physical addresses. A typical case may be a data section with a physical address in ROM and a virtual address in RAM, which should be loaded to the ROM address.
- Add support for querying the target's qXfer:memory-map, which contains information about flash memory regions, leveraging MemoryRegionInfo data structures with minor modifications
- Update ProcessGDBRemote to use vFlash commands in DoWriteMemory when the target address is in a flash region
Original discussion at http://lists.llvm.org/pipermail/lldb-dev/2018-January/013093.html
Reviewers: clayborg, labath
Reviewed By: labath
Subscribers: llvm-commits, arichardson, emaste, mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D42145
Patch by Owen Shaw <llvm@owenpshaw.net>.
llvm-svn: 327970
2018-03-20 11:56:24 +00:00
|
|
|
LoadableData loadable;
|
2017-01-19 17:32:50 +00:00
|
|
|
SectionSP section_sp = section_list->GetSectionAtIndex(i);
|
2025-01-14 20:12:46 -08:00
|
|
|
loadable.Dest = target.GetSectionLoadAddress(section_sp);
|
Re-land: [lldb] Use vFlash commands when writing to target's flash memory regions
The difference between this and the previous patch is that now we use
ELF physical addresses only for loading objects into the target (and the
rest of the module load address logic still uses virtual addresses).
Summary:
When writing an object file over gdb-remote, use the vFlashErase, vFlashWrite, and vFlashDone commands if the write address is in a flash memory region. A bare metal target may have this kind of setup.
- Update ObjectFileELF to set load addresses using physical addresses. A typical case may be a data section with a physical address in ROM and a virtual address in RAM, which should be loaded to the ROM address.
- Add support for querying the target's qXfer:memory-map, which contains information about flash memory regions, leveraging MemoryRegionInfo data structures with minor modifications
- Update ProcessGDBRemote to use vFlash commands in DoWriteMemory when the target address is in a flash region
Original discussion at http://lists.llvm.org/pipermail/lldb-dev/2018-January/013093.html
Reviewers: clayborg, labath
Reviewed By: labath
Subscribers: llvm-commits, arichardson, emaste, mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D42145
Patch by Owen Shaw <llvm@owenpshaw.net>.
llvm-svn: 327970
2018-03-20 11:56:24 +00:00
|
|
|
if (loadable.Dest == LLDB_INVALID_ADDRESS)
|
|
|
|
|
continue;
|
|
|
|
|
// We can skip sections like bss
|
|
|
|
|
if (section_sp->GetFileSize() == 0)
|
|
|
|
|
continue;
|
|
|
|
|
DataExtractor section_data;
|
|
|
|
|
section_sp->GetSectionData(section_data);
|
|
|
|
|
loadable.Contents = llvm::ArrayRef<uint8_t>(section_data.GetDataStart(),
|
|
|
|
|
section_data.GetByteSize());
|
|
|
|
|
loadables.push_back(loadable);
|
2017-01-24 23:07:27 +00:00
|
|
|
}
|
Re-land: [lldb] Use vFlash commands when writing to target's flash memory regions
The difference between this and the previous patch is that now we use
ELF physical addresses only for loading objects into the target (and the
rest of the module load address logic still uses virtual addresses).
Summary:
When writing an object file over gdb-remote, use the vFlashErase, vFlashWrite, and vFlashDone commands if the write address is in a flash memory region. A bare metal target may have this kind of setup.
- Update ObjectFileELF to set load addresses using physical addresses. A typical case may be a data section with a physical address in ROM and a virtual address in RAM, which should be loaded to the ROM address.
- Add support for querying the target's qXfer:memory-map, which contains information about flash memory regions, leveraging MemoryRegionInfo data structures with minor modifications
- Update ProcessGDBRemote to use vFlash commands in DoWriteMemory when the target address is in a flash region
Original discussion at http://lists.llvm.org/pipermail/lldb-dev/2018-January/013093.html
Reviewers: clayborg, labath
Reviewed By: labath
Subscribers: llvm-commits, arichardson, emaste, mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D42145
Patch by Owen Shaw <llvm@owenpshaw.net>.
llvm-svn: 327970
2018-03-20 11:56:24 +00:00
|
|
|
return loadables;
|
2017-01-19 17:32:50 +00:00
|
|
|
}
|
2017-10-02 14:35:07 +00:00
|
|
|
|
[Windows] Use information from the PE32 exceptions directory to construct unwind plans
This patch adds an implementation of unwinding using PE EH info. It allows to
get almost ideal call stacks on 64-bit Windows systems (except some epilogue
cases, but I believe that they can be fixed with unwind plan disassembly
augmentation in the future).
To achieve the goal the CallFrameInfo abstraction was made. It is based on the
DWARFCallFrameInfo class interface with a few changes to make it less
DWARF-specific.
To implement the new interface for PECOFF object files the class PECallFrameInfo
was written. It uses the next helper classes:
- UnwindCodesIterator helps to iterate through UnwindCode structures (and
processes chained infos transparently);
- EHProgramBuilder with the use of UnwindCodesIterator constructs EHProgram;
- EHProgram is, by fact, a vector of EHInstructions. It creates an abstraction
over the low-level unwind codes and simplifies work with them. It contains
only the information that is relevant to unwinding in the unified form. Also
the required unwind codes are read from the object file only once with it;
- EHProgramRange allows to take a range of EHProgram and to build an unwind row
for it.
So, PECallFrameInfo builds the EHProgram with EHProgramBuilder, takes the ranges
corresponding to every offset in prologue and builds the rows of the resulted
unwind plan. The resulted plan covers the whole range of the function except the
epilogue.
Reviewers: jasonmolenda, asmith, amccarth, clayborg, JDevlieghere, stella.stamenova, labath, espindola
Reviewed By: jasonmolenda
Subscribers: leonid.mashinskiy, emaste, mgorny, aprantl, arichardson, MaskRay, lldb-commits, llvm-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D67347
llvm-svn: 374528
2019-10-11 09:03:29 +00:00
|
|
|
std::unique_ptr<CallFrameInfo> ObjectFile::CreateCallFrameInfo() {
|
|
|
|
|
return {};
|
|
|
|
|
}
|
|
|
|
|
|
2017-10-02 14:35:07 +00:00
|
|
|
void ObjectFile::RelocateSection(lldb_private::Section *section)
|
|
|
|
|
{
|
|
|
|
|
}
|
Make sure DataBufferLLVM contents are writable
Summary:
We sometimes need to write to the object file we've mapped into memory,
generally to apply relocations to debug info sections. We've had that
ability before, but with the introduction of DataBufferLLVM, we have
lost it, as the underlying llvm class (MemoryBuffer) only supports
read-only mappings.
This switches DataBufferLLVM to use the new llvm::WritableMemoryBuffer
class as a back-end, as this one guarantees to return a writable buffer.
This removes the need for the "Private" flag to the DataBufferLLVM
creation functions, as it was really used to mean "writable". The LLVM
function also does not have the NullTerminate flag, so I've modified our
clients to not require this feature and removed that flag as well.
Reviewers: zturner, clayborg, jingham
Subscribers: emaste, aprantl, arichardson, krytarowski, lldb-commits
Differential Revision: https://reviews.llvm.org/D40079
llvm-svn: 321255
2017-12-21 10:54:30 +00:00
|
|
|
|
|
|
|
|
DataBufferSP ObjectFile::MapFileData(const FileSpec &file, uint64_t Size,
|
|
|
|
|
uint64_t Offset) {
|
2018-11-12 21:24:50 +00:00
|
|
|
return FileSystem::Instance().CreateDataBuffer(file.GetPath(), Size, Offset);
|
Make sure DataBufferLLVM contents are writable
Summary:
We sometimes need to write to the object file we've mapped into memory,
generally to apply relocations to debug info sections. We've had that
ability before, but with the introduction of DataBufferLLVM, we have
lost it, as the underlying llvm class (MemoryBuffer) only supports
read-only mappings.
This switches DataBufferLLVM to use the new llvm::WritableMemoryBuffer
class as a back-end, as this one guarantees to return a writable buffer.
This removes the need for the "Private" flag to the DataBufferLLVM
creation functions, as it was really used to mean "writable". The LLVM
function also does not have the NullTerminate flag, so I've modified our
clients to not require this feature and removed that flag as well.
Reviewers: zturner, clayborg, jingham
Subscribers: emaste, aprantl, arichardson, krytarowski, lldb-commits
Differential Revision: https://reviews.llvm.org/D40079
llvm-svn: 321255
2017-12-21 10:54:30 +00:00
|
|
|
}
|
Re-commit "Introduce ObjectFileBreakpad"
This re-commits r348592, which was reverted due to a failing test on
macos.
The issue was that I was passing a null pointer for the
"CreateMemoryInstance" callback when registering ObjectFileBreakpad,
which caused crashes when attemping to load modules from memory. The
correct thing to do is to pass a callback which always returns a null
pointer (as breakpad files are never loaded in inferior memory).
It turns out that there is only one test which exercises this code path,
and it's mac-only, so I've create a new test which should run everywhere
(except windows, as one cannot delete an executable which is being run).
Unfortunately, this test still fails on linux for other reasons, but at
least it gives us something to aim for.
The original commit message was:
This patch adds the scaffolding necessary for lldb to recognise symbol
files generated by breakpad. These (textual) files contain just enough
information to be able to produce a backtrace from a crash
dump. This information includes:
- UUID, architecture and name of the module
- line tables
- list of symbols
- unwind information
A minimal breakpad file could look like this:
MODULE Linux x86_64 0000000024B5D199F0F766FFFFFF5DC30 a.out
INFO CODE_ID 00000000B52499D1F0F766FFFFFF5DC3
FILE 0 /tmp/a.c
FUNC 1010 10 0 _start
1010 4 4 0
1014 5 5 0
1019 5 6 0
101e 2 7 0
PUBLIC 1010 0 _start
STACK CFI INIT 1010 10 .cfa: $rsp 8 + .ra: .cfa -8 + ^
STACK CFI 1011 $rbp: .cfa -16 + ^ .cfa: $rsp 16 +
STACK CFI 1014 .cfa: $rbp 16 +
Even though this data would normally be considered "symbol" information,
in the current lldb infrastructure it is assumed every SymbolFile object
is backed by an ObjectFile instance. So, in order to better interoperate
with the rest of the code (particularly symbol vendors).
In this patch I just parse the breakpad header, which is enough to
populate the UUID and architecture fields of the ObjectFile interface.
The rough plan for followup patches is to expose the individual parts of
the breakpad file as ObjectFile "sections", which can then be used by
other parts of the codebase (SymbolFileBreakpad ?) to vend the necessary
information.
Reviewers: clayborg, zturner, lemo, amccarth
Subscribers: mgorny, fedor.sergeev, markmentovai, lldb-commits
Differential Revision: https://reviews.llvm.org/D55214
llvm-svn: 348773
2018-12-10 17:16:38 +00:00
|
|
|
|
|
|
|
|
void llvm::format_provider<ObjectFile::Type>::format(
|
|
|
|
|
const ObjectFile::Type &type, raw_ostream &OS, StringRef Style) {
|
|
|
|
|
switch (type) {
|
|
|
|
|
case ObjectFile::eTypeInvalid:
|
|
|
|
|
OS << "invalid";
|
|
|
|
|
break;
|
|
|
|
|
case ObjectFile::eTypeCoreFile:
|
|
|
|
|
OS << "core file";
|
|
|
|
|
break;
|
|
|
|
|
case ObjectFile::eTypeExecutable:
|
|
|
|
|
OS << "executable";
|
|
|
|
|
break;
|
|
|
|
|
case ObjectFile::eTypeDebugInfo:
|
|
|
|
|
OS << "debug info";
|
|
|
|
|
break;
|
|
|
|
|
case ObjectFile::eTypeDynamicLinker:
|
|
|
|
|
OS << "dynamic linker";
|
|
|
|
|
break;
|
|
|
|
|
case ObjectFile::eTypeObjectFile:
|
|
|
|
|
OS << "object file";
|
|
|
|
|
break;
|
|
|
|
|
case ObjectFile::eTypeSharedLibrary:
|
|
|
|
|
OS << "shared library";
|
|
|
|
|
break;
|
|
|
|
|
case ObjectFile::eTypeStubLibrary:
|
|
|
|
|
OS << "stub library";
|
|
|
|
|
break;
|
|
|
|
|
case ObjectFile::eTypeJIT:
|
|
|
|
|
OS << "jit";
|
|
|
|
|
break;
|
|
|
|
|
case ObjectFile::eTypeUnknown:
|
|
|
|
|
OS << "unknown";
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void llvm::format_provider<ObjectFile::Strata>::format(
|
|
|
|
|
const ObjectFile::Strata &strata, raw_ostream &OS, StringRef Style) {
|
|
|
|
|
switch (strata) {
|
|
|
|
|
case ObjectFile::eStrataInvalid:
|
|
|
|
|
OS << "invalid";
|
|
|
|
|
break;
|
|
|
|
|
case ObjectFile::eStrataUnknown:
|
|
|
|
|
OS << "unknown";
|
|
|
|
|
break;
|
|
|
|
|
case ObjectFile::eStrataUser:
|
|
|
|
|
OS << "user";
|
|
|
|
|
break;
|
|
|
|
|
case ObjectFile::eStrataKernel:
|
|
|
|
|
OS << "kernel";
|
|
|
|
|
break;
|
|
|
|
|
case ObjectFile::eStrataRawImage:
|
|
|
|
|
OS << "raw image";
|
|
|
|
|
break;
|
|
|
|
|
case ObjectFile::eStrataJIT:
|
|
|
|
|
OS << "jit";
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
}
|
2021-11-17 21:18:24 -08:00
|
|
|
|
[lldb] Remerge #136236 (Avoid force loading symbols in statistics collection (#136795)
Fix a [test
failure](https://github.com/llvm/llvm-project/pull/136236#issuecomment-2819772879)
in #136236, apply a minor renaming of statistics, and remerge. See
details below.
# Changes in #136236
Currently, `DebuggerStats::ReportStatistics()` calls
`Module::GetSymtab(/*can_create=*/false)`, but then the latter calls
`SymbolFile::GetSymtab()`. This will load symbols if haven't yet. See
stacktrace below.
The problem is that `DebuggerStats::ReportStatistics` should be
read-only. This is especially important because it reports stats for
symtab parsing/indexing time, which could be affected by the reporting
itself if it's not read-only.
This patch fixes this problem by adding an optional parameter
`SymbolFile::GetSymtab(bool can_create = true)` and receiving the
`false` value passed down from `Module::GetSymtab(/*can_create=*/false)`
when the call is initiated from `DebuggerStats::ReportStatistics()`.
---
Notes about the following stacktrace:
1. This can be reproduced. Create a helloworld program on **macOS** with
dSYM, add `settings set target.preload-symbols false` to `~/.lldbinit`,
do `lldb a.out`, then `statistics dump`.
2. `ObjectFile::GetSymtab` has `llvm::call_once`. So the fact that it
called into `ObjectFileMachO::ParseSymtab` means that the symbol table
is actually being parsed.
```
(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = step over
frame #0: 0x0000000124c4d5a0 LLDB`ObjectFileMachO::ParseSymtab(this=0x0000000111504e40, symtab=0x0000600000a05e00) at ObjectFileMachO.cpp:2259:44
* frame #1: 0x0000000124fc50a0 LLDB`lldb_private::ObjectFile::GetSymtab()::$_0::operator()(this=0x000000016d35c858) const at ObjectFile.cpp:761:9
frame #5: 0x0000000124fc4e68 LLDB`void std::__1::__call_once_proxy[abi:v160006]<std::__1::tuple<lldb_private::ObjectFile::GetSymtab()::$_0&&>>(__vp=0x000000016d35c7f0) at mutex:652:5
frame #6: 0x0000000198afb99c libc++.1.dylib`std::__1::__call_once(unsigned long volatile&, void*, void (*)(void*)) + 196
frame #7: 0x0000000124fc4dd0 LLDB`void std::__1::call_once[abi:v160006]<lldb_private::ObjectFile::GetSymtab()::$_0>(__flag=0x0000600003920080, __func=0x000000016d35c858) at mutex:670:9
frame #8: 0x0000000124fc3cb0 LLDB`void llvm::call_once<lldb_private::ObjectFile::GetSymtab()::$_0>(flag=0x0000600003920080, F=0x000000016d35c858) at Threading.h:88:5
frame #9: 0x0000000124fc2bc4 LLDB`lldb_private::ObjectFile::GetSymtab(this=0x0000000111504e40) at ObjectFile.cpp:755:5
frame #10: 0x0000000124fe0a28 LLDB`lldb_private::SymbolFileCommon::GetSymtab(this=0x0000000104865200) at SymbolFile.cpp:158:39
frame #11: 0x0000000124d8fedc LLDB`lldb_private::Module::GetSymtab(this=0x00000001113041a8, can_create=false) at Module.cpp:1027:21
frame #12: 0x0000000125125bdc LLDB`lldb_private::DebuggerStats::ReportStatistics(debugger=0x000000014284d400, target=0x0000000115808200, options=0x000000014195d6d1) at Statistics.cpp:329:30
frame #13: 0x0000000125672978 LLDB`CommandObjectStatsDump::DoExecute(this=0x000000014195d540, command=0x000000016d35d820, result=0x000000016d35e150) at CommandObjectStats.cpp:144:18
frame #14: 0x0000000124f29b40 LLDB`lldb_private::CommandObjectParsed::Execute(this=0x000000014195d540, args_string="", result=0x000000016d35e150) at CommandObject.cpp:832:9
frame #15: 0x0000000124efbd70 LLDB`lldb_private::CommandInterpreter::HandleCommand(this=0x0000000141b22f30, command_line="statistics dump", lazy_add_to_history=eLazyBoolCalculate, result=0x000000016d35e150, force_repeat_command=false) at CommandInterpreter.cpp:2134:14
frame #16: 0x0000000124f007f4 LLDB`lldb_private::CommandInterpreter::IOHandlerInputComplete(this=0x0000000141b22f30, io_handler=0x00000001419b2aa8, line="statistics dump") at CommandInterpreter.cpp:3251:3
frame #17: 0x0000000124d7b5ec LLDB`lldb_private::IOHandlerEditline::Run(this=0x00000001419b2aa8) at IOHandler.cpp:588:22
frame #18: 0x0000000124d1e8fc LLDB`lldb_private::Debugger::RunIOHandlers(this=0x000000014284d400) at Debugger.cpp:1225:16
frame #19: 0x0000000124f01f74 LLDB`lldb_private::CommandInterpreter::RunCommandInterpreter(this=0x0000000141b22f30, options=0x000000016d35e63c) at CommandInterpreter.cpp:3543:16
frame #20: 0x0000000122840294 LLDB`lldb::SBDebugger::RunCommandInterpreter(this=0x000000016d35ebd8, auto_handle_events=true, spawn_thread=false) at SBDebugger.cpp:1212:42
frame #21: 0x0000000102aa6d28 lldb`Driver::MainLoop(this=0x000000016d35ebb8) at Driver.cpp:621:18
frame #22: 0x0000000102aa75b0 lldb`main(argc=1, argv=0x000000016d35f548) at Driver.cpp:829:26
frame #23: 0x0000000198858274 dyld`start + 2840
```
# Changes in this PR top of the above
Fix a [test
failure](https://github.com/llvm/llvm-project/pull/136236#issuecomment-2819772879)
in `TestStats.py`. The original version of the added test checks that
all modules have symbol count zero when `target.preload-symbols ==
false`. The test failed on macOS. Due to various reasons, on macOS,
symbols can be loaded for dylibs even with that setting, but not for the
main module. For now, the fix of the test is to limit the assertion to
only the main module. The test now passes on macOS. In the future, when
we have a way to control a specific list of plug-ins to be loaded, there
may be a configuration that this test can use to assert that all modules
have symbol count zero.
Apply a minor renaming of statistics, per the
[suggestion](https://github.com/llvm/llvm-project/pull/136226#issuecomment-2825080275)
in #136226 after merge.
2025-04-24 17:23:41 -07:00
|
|
|
Symtab *ObjectFile::GetSymtab(bool can_create) {
|
2021-11-17 21:18:24 -08:00
|
|
|
ModuleSP module_sp(GetModule());
|
[lldb] Remerge #136236 (Avoid force loading symbols in statistics collection (#136795)
Fix a [test
failure](https://github.com/llvm/llvm-project/pull/136236#issuecomment-2819772879)
in #136236, apply a minor renaming of statistics, and remerge. See
details below.
# Changes in #136236
Currently, `DebuggerStats::ReportStatistics()` calls
`Module::GetSymtab(/*can_create=*/false)`, but then the latter calls
`SymbolFile::GetSymtab()`. This will load symbols if haven't yet. See
stacktrace below.
The problem is that `DebuggerStats::ReportStatistics` should be
read-only. This is especially important because it reports stats for
symtab parsing/indexing time, which could be affected by the reporting
itself if it's not read-only.
This patch fixes this problem by adding an optional parameter
`SymbolFile::GetSymtab(bool can_create = true)` and receiving the
`false` value passed down from `Module::GetSymtab(/*can_create=*/false)`
when the call is initiated from `DebuggerStats::ReportStatistics()`.
---
Notes about the following stacktrace:
1. This can be reproduced. Create a helloworld program on **macOS** with
dSYM, add `settings set target.preload-symbols false` to `~/.lldbinit`,
do `lldb a.out`, then `statistics dump`.
2. `ObjectFile::GetSymtab` has `llvm::call_once`. So the fact that it
called into `ObjectFileMachO::ParseSymtab` means that the symbol table
is actually being parsed.
```
(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = step over
frame #0: 0x0000000124c4d5a0 LLDB`ObjectFileMachO::ParseSymtab(this=0x0000000111504e40, symtab=0x0000600000a05e00) at ObjectFileMachO.cpp:2259:44
* frame #1: 0x0000000124fc50a0 LLDB`lldb_private::ObjectFile::GetSymtab()::$_0::operator()(this=0x000000016d35c858) const at ObjectFile.cpp:761:9
frame #5: 0x0000000124fc4e68 LLDB`void std::__1::__call_once_proxy[abi:v160006]<std::__1::tuple<lldb_private::ObjectFile::GetSymtab()::$_0&&>>(__vp=0x000000016d35c7f0) at mutex:652:5
frame #6: 0x0000000198afb99c libc++.1.dylib`std::__1::__call_once(unsigned long volatile&, void*, void (*)(void*)) + 196
frame #7: 0x0000000124fc4dd0 LLDB`void std::__1::call_once[abi:v160006]<lldb_private::ObjectFile::GetSymtab()::$_0>(__flag=0x0000600003920080, __func=0x000000016d35c858) at mutex:670:9
frame #8: 0x0000000124fc3cb0 LLDB`void llvm::call_once<lldb_private::ObjectFile::GetSymtab()::$_0>(flag=0x0000600003920080, F=0x000000016d35c858) at Threading.h:88:5
frame #9: 0x0000000124fc2bc4 LLDB`lldb_private::ObjectFile::GetSymtab(this=0x0000000111504e40) at ObjectFile.cpp:755:5
frame #10: 0x0000000124fe0a28 LLDB`lldb_private::SymbolFileCommon::GetSymtab(this=0x0000000104865200) at SymbolFile.cpp:158:39
frame #11: 0x0000000124d8fedc LLDB`lldb_private::Module::GetSymtab(this=0x00000001113041a8, can_create=false) at Module.cpp:1027:21
frame #12: 0x0000000125125bdc LLDB`lldb_private::DebuggerStats::ReportStatistics(debugger=0x000000014284d400, target=0x0000000115808200, options=0x000000014195d6d1) at Statistics.cpp:329:30
frame #13: 0x0000000125672978 LLDB`CommandObjectStatsDump::DoExecute(this=0x000000014195d540, command=0x000000016d35d820, result=0x000000016d35e150) at CommandObjectStats.cpp:144:18
frame #14: 0x0000000124f29b40 LLDB`lldb_private::CommandObjectParsed::Execute(this=0x000000014195d540, args_string="", result=0x000000016d35e150) at CommandObject.cpp:832:9
frame #15: 0x0000000124efbd70 LLDB`lldb_private::CommandInterpreter::HandleCommand(this=0x0000000141b22f30, command_line="statistics dump", lazy_add_to_history=eLazyBoolCalculate, result=0x000000016d35e150, force_repeat_command=false) at CommandInterpreter.cpp:2134:14
frame #16: 0x0000000124f007f4 LLDB`lldb_private::CommandInterpreter::IOHandlerInputComplete(this=0x0000000141b22f30, io_handler=0x00000001419b2aa8, line="statistics dump") at CommandInterpreter.cpp:3251:3
frame #17: 0x0000000124d7b5ec LLDB`lldb_private::IOHandlerEditline::Run(this=0x00000001419b2aa8) at IOHandler.cpp:588:22
frame #18: 0x0000000124d1e8fc LLDB`lldb_private::Debugger::RunIOHandlers(this=0x000000014284d400) at Debugger.cpp:1225:16
frame #19: 0x0000000124f01f74 LLDB`lldb_private::CommandInterpreter::RunCommandInterpreter(this=0x0000000141b22f30, options=0x000000016d35e63c) at CommandInterpreter.cpp:3543:16
frame #20: 0x0000000122840294 LLDB`lldb::SBDebugger::RunCommandInterpreter(this=0x000000016d35ebd8, auto_handle_events=true, spawn_thread=false) at SBDebugger.cpp:1212:42
frame #21: 0x0000000102aa6d28 lldb`Driver::MainLoop(this=0x000000016d35ebb8) at Driver.cpp:621:18
frame #22: 0x0000000102aa75b0 lldb`main(argc=1, argv=0x000000016d35f548) at Driver.cpp:829:26
frame #23: 0x0000000198858274 dyld`start + 2840
```
# Changes in this PR top of the above
Fix a [test
failure](https://github.com/llvm/llvm-project/pull/136236#issuecomment-2819772879)
in `TestStats.py`. The original version of the added test checks that
all modules have symbol count zero when `target.preload-symbols ==
false`. The test failed on macOS. Due to various reasons, on macOS,
symbols can be loaded for dylibs even with that setting, but not for the
main module. For now, the fix of the test is to limit the assertion to
only the main module. The test now passes on macOS. In the future, when
we have a way to control a specific list of plug-ins to be loaded, there
may be a configuration that this test can use to assert that all modules
have symbol count zero.
Apply a minor renaming of statistics, per the
[suggestion](https://github.com/llvm/llvm-project/pull/136226#issuecomment-2825080275)
in #136226 after merge.
2025-04-24 17:23:41 -07:00
|
|
|
if (module_sp && can_create) {
|
2021-11-17 21:18:24 -08:00
|
|
|
// We can't take the module lock in ObjectFile::GetSymtab() or we can
|
|
|
|
|
// deadlock in DWARF indexing when any file asks for the symbol table from
|
|
|
|
|
// an object file. This currently happens in the preloading of symbols in
|
|
|
|
|
// SymbolFileDWARF::PreloadSymbols() because the main thread will take the
|
|
|
|
|
// module lock, and then threads will be spun up to index the DWARF and
|
|
|
|
|
// any of those threads might end up trying to relocate items in the DWARF
|
|
|
|
|
// sections which causes ObjectFile::GetSectionData(...) to relocate section
|
|
|
|
|
// data which requires the symbol table.
|
|
|
|
|
//
|
|
|
|
|
// So to work around this, we create the symbol table one time using
|
|
|
|
|
// llvm::once_flag, lock it, and then set the unique pointer. Any other
|
|
|
|
|
// thread that gets ahold of the symbol table before parsing is done, will
|
|
|
|
|
// not be able to access the symbol table contents since all APIs in Symtab
|
|
|
|
|
// are protected by a mutex in the Symtab object itself.
|
|
|
|
|
llvm::call_once(*m_symtab_once_up, [&]() {
|
Added the ability to cache the finalized symbol tables subsequent debug sessions to start faster.
This is an updated version of the https://reviews.llvm.org/D113789 patch with the following changes:
- We no longer modify modification times of the cache files
- Use LLVM caching and cache pruning instead of making a new cache mechanism (See DataFileCache.h/.cpp)
- Add signature to start of each file since we are not using modification times so we can tell when caches are stale and remove and re-create the cache file as files are changed
- Add settings to control the cache size, disk percentage and expiration in days to keep cache size under control
This patch enables symbol tables to be cached in the LLDB index cache directory. All cache files are in a single directory and the files use unique names to ensure that files from the same path will re-use the same file as files get modified. This means as files change, their cache files will be deleted and updated. The modification time of each of the cache files is not modified so that access based pruning of the cache can be implemented.
The symbol table cache files start with a signature that uniquely identifies a file on disk and contains one or more of the following items:
- object file UUID if available
- object file mod time if available
- object name for BSD archive .o files that are in .a files if available
If none of these signature items are available, then the file will not be cached. This keeps temporary object files from expressions from being cached.
When the cache files are loaded on subsequent debug sessions, the signature is compare and if the file has been modified (uuid changes, mod time changes, or object file mod time changes) then the cache file is deleted and re-created.
Module caching must be enabled by the user before this can be used:
symbols.enable-lldb-index-cache (boolean) = false
(lldb) settings set symbols.enable-lldb-index-cache true
There is also a setting that allows the user to specify a module cache directory that defaults to a directory that defaults to being next to the symbols.clang-modules-cache-path directory in a temp directory:
(lldb) settings show symbols.lldb-index-cache-path
/var/folders/9p/472sr0c55l9b20x2zg36b91h0000gn/C/lldb/IndexCache
If this setting is enabled, the finalized symbol tables will be serialized and saved to disc so they can be quickly loaded next time you debug.
Each module can cache one or more files in the index cache directory. The cache file names must be unique to a file on disk and its architecture and object name for .o files in BSD archives. This allows universal mach-o files to support caching multuple architectures in the same module cache directory. Making the file based on the this info allows this cache file to be deleted and replaced when the file gets updated on disk. This keeps the cache from growing over time during the compile/edit/debug cycle and prevents out of space issues.
If the cache is enabled, the symbol table will be loaded from the cache the next time you debug if the module has not changed.
The cache also has settings to control the size of the cache on disk. Each time LLDB starts up with the index cache enable, the cache will be pruned to ensure it stays within the user defined settings:
(lldb) settings set symbols.lldb-index-cache-expiration-days <days>
A value of zero will disable cache files from expiring when the cache is pruned. The default value is 7 currently.
(lldb) settings set symbols.lldb-index-cache-max-byte-size <size>
A value of zero will disable pruning based on a total byte size. The default value is zero currently.
(lldb) settings set symbols.lldb-index-cache-max-percent <percentage-of-disk-space>
A value of 100 will allow the disc to be filled to the max, a value of zero will disable percentage pruning. The default value is zero.
Reviewed By: labath, wallace
Differential Revision: https://reviews.llvm.org/D115324
2021-12-16 09:59:25 -08:00
|
|
|
Symtab *symtab = new Symtab(this);
|
|
|
|
|
std::lock_guard<std::recursive_mutex> symtab_guard(symtab->GetMutex());
|
|
|
|
|
m_symtab_up.reset(symtab);
|
|
|
|
|
if (!m_symtab_up->LoadFromCache()) {
|
|
|
|
|
ElapsedTime elapsed(module_sp->GetSymtabParseTime());
|
|
|
|
|
ParseSymtab(*m_symtab_up);
|
|
|
|
|
m_symtab_up->Finalize();
|
|
|
|
|
}
|
2021-11-17 21:18:24 -08:00
|
|
|
});
|
|
|
|
|
}
|
|
|
|
|
return m_symtab_up.get();
|
|
|
|
|
}
|
Added the ability to cache the finalized symbol tables subsequent debug sessions to start faster.
This is an updated version of the https://reviews.llvm.org/D113789 patch with the following changes:
- We no longer modify modification times of the cache files
- Use LLVM caching and cache pruning instead of making a new cache mechanism (See DataFileCache.h/.cpp)
- Add signature to start of each file since we are not using modification times so we can tell when caches are stale and remove and re-create the cache file as files are changed
- Add settings to control the cache size, disk percentage and expiration in days to keep cache size under control
This patch enables symbol tables to be cached in the LLDB index cache directory. All cache files are in a single directory and the files use unique names to ensure that files from the same path will re-use the same file as files get modified. This means as files change, their cache files will be deleted and updated. The modification time of each of the cache files is not modified so that access based pruning of the cache can be implemented.
The symbol table cache files start with a signature that uniquely identifies a file on disk and contains one or more of the following items:
- object file UUID if available
- object file mod time if available
- object name for BSD archive .o files that are in .a files if available
If none of these signature items are available, then the file will not be cached. This keeps temporary object files from expressions from being cached.
When the cache files are loaded on subsequent debug sessions, the signature is compare and if the file has been modified (uuid changes, mod time changes, or object file mod time changes) then the cache file is deleted and re-created.
Module caching must be enabled by the user before this can be used:
symbols.enable-lldb-index-cache (boolean) = false
(lldb) settings set symbols.enable-lldb-index-cache true
There is also a setting that allows the user to specify a module cache directory that defaults to a directory that defaults to being next to the symbols.clang-modules-cache-path directory in a temp directory:
(lldb) settings show symbols.lldb-index-cache-path
/var/folders/9p/472sr0c55l9b20x2zg36b91h0000gn/C/lldb/IndexCache
If this setting is enabled, the finalized symbol tables will be serialized and saved to disc so they can be quickly loaded next time you debug.
Each module can cache one or more files in the index cache directory. The cache file names must be unique to a file on disk and its architecture and object name for .o files in BSD archives. This allows universal mach-o files to support caching multuple architectures in the same module cache directory. Making the file based on the this info allows this cache file to be deleted and replaced when the file gets updated on disk. This keeps the cache from growing over time during the compile/edit/debug cycle and prevents out of space issues.
If the cache is enabled, the symbol table will be loaded from the cache the next time you debug if the module has not changed.
The cache also has settings to control the size of the cache on disk. Each time LLDB starts up with the index cache enable, the cache will be pruned to ensure it stays within the user defined settings:
(lldb) settings set symbols.lldb-index-cache-expiration-days <days>
A value of zero will disable cache files from expiring when the cache is pruned. The default value is 7 currently.
(lldb) settings set symbols.lldb-index-cache-max-byte-size <size>
A value of zero will disable pruning based on a total byte size. The default value is zero currently.
(lldb) settings set symbols.lldb-index-cache-max-percent <percentage-of-disk-space>
A value of 100 will allow the disc to be filled to the max, a value of zero will disable percentage pruning. The default value is zero.
Reviewed By: labath, wallace
Differential Revision: https://reviews.llvm.org/D115324
2021-12-16 09:59:25 -08:00
|
|
|
|
|
|
|
|
uint32_t ObjectFile::GetCacheHash() {
|
|
|
|
|
if (m_cache_hash)
|
|
|
|
|
return *m_cache_hash;
|
|
|
|
|
StreamString strm;
|
|
|
|
|
strm.Format("{0}-{1}-{2}", m_file, GetType(), GetStrata());
|
|
|
|
|
m_cache_hash = llvm::djbHash(strm.GetString());
|
|
|
|
|
return *m_cache_hash;
|
|
|
|
|
}
|
2023-04-13 13:02:45 -07:00
|
|
|
|
2025-04-04 16:33:40 -07:00
|
|
|
std::string ObjectFile::GetObjectName() const {
|
|
|
|
|
if (ModuleSP module_sp = GetModule())
|
|
|
|
|
if (ConstString object_name = module_sp->GetObjectName())
|
|
|
|
|
return llvm::formatv("{0}({1})", GetFileSpec().GetFilename().GetString(),
|
|
|
|
|
object_name.GetString())
|
|
|
|
|
.str();
|
|
|
|
|
return GetFileSpec().GetFilename().GetString();
|
|
|
|
|
}
|
|
|
|
|
|
2023-04-13 13:02:45 -07:00
|
|
|
namespace llvm {
|
|
|
|
|
namespace json {
|
|
|
|
|
|
|
|
|
|
bool fromJSON(const llvm::json::Value &value,
|
|
|
|
|
lldb_private::ObjectFile::Type &type, llvm::json::Path path) {
|
|
|
|
|
if (auto str = value.getAsString()) {
|
|
|
|
|
type = llvm::StringSwitch<ObjectFile::Type>(*str)
|
|
|
|
|
.Case("corefile", ObjectFile::eTypeCoreFile)
|
|
|
|
|
.Case("executable", ObjectFile::eTypeExecutable)
|
|
|
|
|
.Case("debuginfo", ObjectFile::eTypeDebugInfo)
|
|
|
|
|
.Case("dynamiclinker", ObjectFile::eTypeDynamicLinker)
|
|
|
|
|
.Case("objectfile", ObjectFile::eTypeObjectFile)
|
|
|
|
|
.Case("sharedlibrary", ObjectFile::eTypeSharedLibrary)
|
|
|
|
|
.Case("stublibrary", ObjectFile::eTypeStubLibrary)
|
|
|
|
|
.Case("jit", ObjectFile::eTypeJIT)
|
|
|
|
|
.Case("unknown", ObjectFile::eTypeUnknown)
|
|
|
|
|
.Default(ObjectFile::eTypeInvalid);
|
|
|
|
|
|
|
|
|
|
if (type == ObjectFile::eTypeInvalid) {
|
|
|
|
|
path.report("invalid object type");
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
path.report("expected string");
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
} // namespace json
|
|
|
|
|
} // namespace llvm
|