maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/lldb/source/Symbol/ObjectFile.cpp

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

746 lines
28 KiB
C++
Raw Normal View History

Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
//===-- ObjectFile.cpp ------------------------------------------*- C++ -*-===//
//
Update the file headers across all of the LLVM projects in the monorepo to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
2019-01-19 16:50:56 +08:00
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
// See https://llvm.org/LICENSE.txt for license information.
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
//
//===----------------------------------------------------------------------===//
#include "lldb/Symbol/ObjectFile.h"
#include "lldb/Core/Module.h"
Added the ability to extract a ModuleSpecList (a new class) from an ObjectFile. This is designed to be used when you have an object file that contains one or more architectures (MacOSX universal (fat) files) and/or one or more objects (BSD archive (.a files)). There is a new static ObjectFile function you can call: size_t ObjectFile::GetModuleSpecifications (const FileSpec &file, lldb::offset_t file_offset, ModuleSpecList &specs) This will fill in "specs" which the details of all the module specs (file + arch + UUID (if there is one) + object name (for BSD archive objects eventually) + file offset to the object in question). This helps us when a user specifies a file that contains a single architecture, and also helps us when we are given a debug symbol file (like a dSYM file on MacOSX) that contains one or more architectures and we need to be able to match it up to an existing Module that has no debug info. llvm-svn: 180224
2013-04-25 06:29:28 +08:00
#include "lldb/Core/ModuleSpec.h"
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08: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-30 05:13:06 +08: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 17:03:29 +08:00
#include "lldb/Symbol/CallFrameInfo.h"
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
#include "lldb/Symbol/ObjectContainer.h"
#include "lldb/Symbol/SymbolFile.h"
Move classes from Core -> Utility. This moves the following classes from Core -> Utility. ConstString Error RegularExpression Stream StreamString The goal here is to get lldbUtility into a state where it has no dependendencies except on itself and LLVM, so it can be the starting point at which to start untangling LLDB's dependencies. These are all low level and very widely used classes, and previously lldbUtility had dependencies up to lldbCore in order to use these classes. So moving then down to lldbUtility makes sense from both the short term and long term perspective in solving this problem. Differential Revision: https://reviews.llvm.org/D29427 llvm-svn: 293941
2017-02-03 05:39:50 +08:00
#include "lldb/Target/Process.h"
Provide a substitute to load command of gdb. For bare-metal targets, lldb was missing a command like 'load' in gdb which can be used to create executable image on the target. This was discussed in http://lists.llvm.org/pipermail/lldb-dev/2016-December/011752.html This commits adds an option to "target module load" command to provide that functionality. It does not set the PC to entry address which will be done separately. Reviewed in https://reviews.llvm.org/D28804 llvm-svn: 292499
2017-01-20 01:32:50 +08:00
#include "lldb/Target/SectionLoadList.h"
Move classes from Core -> Utility. This moves the following classes from Core -> Utility. ConstString Error RegularExpression Stream StreamString The goal here is to get lldbUtility into a state where it has no dependendencies except on itself and LLVM, so it can be the starting point at which to start untangling LLDB's dependencies. These are all low level and very widely used classes, and previously lldbUtility had dependencies up to lldbCore in order to use these classes. So moving then down to lldbUtility makes sense from both the short term and long term perspective in solving this problem. Differential Revision: https://reviews.llvm.org/D29427 llvm-svn: 293941
2017-02-03 05:39:50 +08:00
#include "lldb/Target/Target.h"
Move DataBuffer / DataExtractor and friends from Core -> Utility. llvm-svn: 296943
2017-03-04 09:30:05 +08:00
#include "lldb/Utility/DataBuffer.h"
#include "lldb/Utility/DataBufferHeap.h"
Move Log from Core -> Utility. All references to Host and Core have been removed, so this class can now safely be lowered into Utility. Differential Revision: https://reviews.llvm.org/D30559 llvm-svn: 296909
2017-03-04 04:56:28 +08:00
#include "lldb/Utility/Log.h"
Move Timer and TraceOptions from Core to Utility Summary: The classes have no dependencies, and they are used both by lldb and lldb-server, so it makes sense for them to live in the lowest layers. Reviewers: zturner, jingham Subscribers: emaste, mgorny, lldb-commits Differential Revision: https://reviews.llvm.org/D34746 llvm-svn: 306682
2017-06-29 22:32:17 +08: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-30 05:13:06 +08:00
#include "lldb/lldb-private.h"
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08: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 19:57:34 +08:00
char ObjectFile::ID;
Don't put modules for .o files into the global shared module list. We used to do this because we needed to find the shared pointer for a .o file when the .o file's module was needed in a SymbolContext since the module in a symbol context was a shared pointer. Now that we are using intrusive pointers we don't have this limitation anymore since any instrusive shared pointer can be made from a pointer to an object all on its own. Also switched over to having the Module and SymbolVendor use shared pointers to their object files as had a leak on MacOSX when the SymbolVendor's object file wasn't the same as the Module's (debug info in a stand along file (dSYM file)). Now everything will correctly clean itself up when the module goes away after an executable gets rebuilt. Now we correctly get rid of .o files that are used with the DWARF with debug map executables on subsequent runs since the only shared pointer to the object files in from the DWARF symbol file debug map parser, and when the module gets replaced, it destroys to old one along with all .o files. Also added a small optimization when using BSD archives where we will remove old BSD containers from the shared list when they are outdated. llvm-svn: 140002
2011-09-19 02:59:15 +08:00
ObjectFileSP
<rdar://problem/13159777> lldb was mmap'ing archive files once per .o file it loads, now it correctly shares the archive between modules. LLDB was also always mapping entire contents of universal mach-o files, now it maps just the slice that is required. Added a new logging channel for "lldb" called "mmap" to help track future regressions. Modified the ObjectFile and ObjectContainer plugin interfaces to take a data offset along with the file offset and size so we can implement the correct caching and efficient reading of parts of files without mmap'ing the entire file like we used to. The current implementation still keeps entire .a files mmaped (once) and entire slices from universal files mmaped to ensure that if a client builds their binaries during a debug session we don't lose our data and get corrupt object file info and debug info. llvm-svn: 174524
2013-02-07 01:22:03 +08:00
ObjectFile::FindPlugin(const lldb::ModuleSP &module_sp, const FileSpec *file,
lldb::offset_t file_offset, lldb::offset_t file_size,
DataBufferSP &data_sp, lldb::offset_t &data_offset) {
Don't put modules for .o files into the global shared module list. We used to do this because we needed to find the shared pointer for a .o file when the .o file's module was needed in a SymbolContext since the module in a symbol context was a shared pointer. Now that we are using intrusive pointers we don't have this limitation anymore since any instrusive shared pointer can be made from a pointer to an object all on its own. Also switched over to having the Module and SymbolVendor use shared pointers to their object files as had a leak on MacOSX when the SymbolVendor's object file wasn't the same as the Module's (debug info in a stand along file (dSYM file)). Now everything will correctly clean itself up when the module goes away after an executable gets rebuilt. Now we correctly get rid of .o files that are used with the DWARF with debug map executables on subsequent runs since the only shared pointer to the object files in from the DWARF symbol file debug map parser, and when the module gets replaced, it destroys to old one along with all .o files. Also added a small optimization when using BSD archives where we will remove old BSD containers from the shared list when they are outdated. llvm-svn: 140002
2011-09-19 02:59:15 +08:00
ObjectFileSP object_file_sp;
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
<rdar://problem/10103468> I started work on being able to add symbol files after a debug session had started with a new "target symfile add" command and quickly ran into problems with stale Address objects in breakpoint locations that had lldb_private::Section pointers into modules that had been removed or replaced. This also let to grabbing stale modules from those sections. So I needed to thread harded the Address, Section and related objects. To do this I modified the ModuleChild class to now require a ModuleSP on initialization so that a weak reference can created. I also changed all places that were handing out "Section *" to have them hand out SectionSP. All ObjectFile, SymbolFile and SymbolVendors were inheriting from ModuleChild so all of the find plug-in, static creation function and constructors now require ModuleSP references instead of Module *. Address objects now have weak references to their sections which can safely go stale when a module gets destructed. This checkin doesn't complete the "target symfile add" command, but it does get us a lot clioser to being able to do such things without a high risk of crashing or memory corruption. llvm-svn: 151336
2012-02-24 09:59:29 +08:00
if (module_sp) {
Remove an expensive lock from Timer The Timer destructor would grab a global mutex in order to update execution time. Add a class to define a category once, statically; the class adds itself to an atomic singly linked list, and thus subsequent updates only need to use an atomic rather than grab a lock and perform a hashtable lookup. Differential Revision: https://reviews.llvm.org/D32823 Patch by Scott Smith <scott.smith@purestorage.com>. llvm-svn: 303058
2017-05-15 21:02:37 +08:00
static Timer::Category func_cat(LLVM_PRETTY_FUNCTION);
Delete Host/windows/win32.h It's always hard to remember when to include this file, and when you do include it it's hard to remember what preprocessor check it needs to be behind, and then you further have to remember whether it's windows.h or win32.h which you need to include. This patch changes the name to PosixApi.h, which is more appropriately named, and makes it independent of any preprocessor setting. There's still the issue of people not knowing when to include this, because there's not a well-defined set of things it exposes other than "whatever is missing on Windows", but at least this should make it less painful to fix when problems arise. This patch depends on LLVM revision r278170. llvm-svn: 278177
2016-08-10 07:06:08 +08:00
Timer scoped_timer(
Remove an expensive lock from Timer The Timer destructor would grab a global mutex in order to update execution time. Add a class to define a category once, statically; the class adds itself to an atomic singly linked list, and thus subsequent updates only need to use an atomic rather than grab a lock and perform a hashtable lookup. Differential Revision: https://reviews.llvm.org/D32823 Patch by Scott Smith <scott.smith@purestorage.com>. llvm-svn: 303058
2017-05-15 21:02:37 +08:00
func_cat,
Cleanup logging to use the new "std::string FileSpec::GetPath()" function. Also added a similar function for modules: std::string Module::GetSpecificationDescription () const; This returns the module as "/usr/lib/libfoo.dylib" for normal files (calls "std::string FileSpec::GetPath()" on m_file) but it also might include the object name in case the module is for a .o file in a BSD archive ("/usr/lib/libfoo.a(bar.o)"). Cleaned up necessary logging code to use it. llvm-svn: 180717
2013-04-30 01:25:54 +08:00
"ObjectFile::FindPlugin (module = %s, file = %p, file_offset = "
"0x%8.8" PRIx64 ", file_size = 0x%8.8" PRIx64 ")",
module_sp->GetFileSpec().GetPath().c_str(),
sweep up -Wformat warnings from gcc This is a purely mechanical change explicitly casting any parameters for printf style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux. llvm-svn: 205607
2014-04-04 12:06:10 +08:00
static_cast<const void *>(file), static_cast<uint64_t>(file_offset),
static_cast<uint64_t>(file_size));
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
if (file) {
<rdar://problem/13159777> lldb was mmap'ing archive files once per .o file it loads, now it correctly shares the archive between modules. LLDB was also always mapping entire contents of universal mach-o files, now it maps just the slice that is required. Added a new logging channel for "lldb" called "mmap" to help track future regressions. Modified the ObjectFile and ObjectContainer plugin interfaces to take a data offset along with the file offset and size so we can implement the correct caching and efficient reading of parts of files without mmap'ing the entire file like we used to. The current implementation still keeps entire .a files mmaped (once) and entire slices from universal files mmaped to ensure that if a client builds their binaries during a debug session we don't lose our data and get corrupt object file info and debug info. llvm-svn: 174524
2013-02-07 01:22:03 +08:00
FileSpec archive_file;
ObjectContainerCreateInstance create_object_container_callback;
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
[FileSystem] Remove Exists() from FileSpec This patch removes the Exists method from FileSpec and updates its uses with calls to the FileSystem. Differential revision: https://reviews.llvm.org/D53845 llvm-svn: 345854
2018-11-02 01:09:25 +08:00
const bool file_exists = FileSystem::Instance().Exists(*file);
<rdar://problem/13159777> lldb was mmap'ing archive files once per .o file it loads, now it correctly shares the archive between modules. LLDB was also always mapping entire contents of universal mach-o files, now it maps just the slice that is required. Added a new logging channel for "lldb" called "mmap" to help track future regressions. Modified the ObjectFile and ObjectContainer plugin interfaces to take a data offset along with the file offset and size so we can implement the correct caching and efficient reading of parts of files without mmap'ing the entire file like we used to. The current implementation still keeps entire .a files mmaped (once) and entire slices from universal files mmaped to ensure that if a client builds their binaries during a debug session we don't lose our data and get corrupt object file info and debug info. llvm-svn: 174524
2013-02-07 01:22:03 +08:00
if (!data_sp) {
Reflow paragraphs in comments. This is intended as a clean up after the big clang-format commit (r280751), which unfortunately resulted in many of the comment paragraphs in LLDB being very hard to read. FYI, the script I used was: import textwrap import commands import os import sys import re tmp = "%s.tmp"%sys.argv[1] out = open(tmp, "w+") with open(sys.argv[1], "r") as f: header = "" text = "" comment = re.compile(r'^( *//) ([^ ].*)$') special = re.compile(r'^((([A-Z]+[: ])|([0-9]+ )).*)|(.*;)$') for line in f: match = comment.match(line) if match and not special.match(match.group(2)): # skip intentionally short comments. if not text and len(match.group(2)) < 40: out.write(line) continue if text: text += " " + match.group(2) else: header = match.group(1) text = match.group(2) continue if text: filled = textwrap.wrap(text, width=(78-len(header)), break_long_words=False) for l in filled: out.write(header+" "+l+'\n') text = "" out.write(line) os.rename(tmp, sys.argv[1]) Differential Revision: https://reviews.llvm.org/D46144 llvm-svn: 331197
2018-05-01 00:49:04 +08:00
// 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
<rdar://problem/13159777> lldb was mmap'ing archive files once per .o file it loads, now it correctly shares the archive between modules. LLDB was also always mapping entire contents of universal mach-o files, now it maps just the slice that is required. Added a new logging channel for "lldb" called "mmap" to help track future regressions. Modified the ObjectFile and ObjectContainer plugin interfaces to take a data offset along with the file offset and size so we can implement the correct caching and efficient reading of parts of files without mmap'ing the entire file like we used to. The current implementation still keeps entire .a files mmaped (once) and entire slices from universal files mmaped to ensure that if a client builds their binaries during a debug session we don't lose our data and get corrupt object file info and debug info. llvm-svn: 174524
2013-02-07 01:22:03 +08:00
if (file_exists && module_sp->GetObjectName()) {
Switch NULL to C++11 nullptr in source/Symbol and source/Utility Patch by Robert Matusewicz llvm-svn: 206713
2014-04-20 21:17:36 +08:00
for (uint32_t idx = 0;
(create_object_container_callback =
PluginManager::GetObjectContainerCreateCallbackAtIndex(
idx)) != nullptr;
++idx) {
Replace 'ap' with 'up' suffix in variable names. (NFC) The `ap` suffix is a remnant of lldb's former use of auto pointers, before they got deprecated. Although all their uses were replaced by unique pointers, some variables still carried the suffix. In r353795 I removed another auto_ptr remnant, namely redundant calls to ::get for unique_pointers. Jim justly noted that this is a good opportunity to clean up the variable names as well. I went over all the changes to ensure my find-and-replace didn't have any undesired side-effects. I hope I didn't miss any, but if you end up at this commit doing a git blame on a weirdly named variable, please know that the change was unintentional. llvm-svn: 353912
2019-02-13 14:25:41 +08:00
std::unique_ptr<ObjectContainer> object_container_up(
<rdar://problem/13159777> lldb was mmap'ing archive files once per .o file it loads, now it correctly shares the archive between modules. LLDB was also always mapping entire contents of universal mach-o files, now it maps just the slice that is required. Added a new logging channel for "lldb" called "mmap" to help track future regressions. Modified the ObjectFile and ObjectContainer plugin interfaces to take a data offset along with the file offset and size so we can implement the correct caching and efficient reading of parts of files without mmap'ing the entire file like we used to. The current implementation still keeps entire .a files mmaped (once) and entire slices from universal files mmaped to ensure that if a client builds their binaries during a debug session we don't lose our data and get corrupt object file info and debug info. llvm-svn: 174524
2013-02-07 01:22:03 +08:00
create_object_container_callback(module_sp, data_sp,
data_offset, file, file_offset,
file_size));
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
Replace 'ap' with 'up' suffix in variable names. (NFC) The `ap` suffix is a remnant of lldb's former use of auto pointers, before they got deprecated. Although all their uses were replaced by unique pointers, some variables still carried the suffix. In r353795 I removed another auto_ptr remnant, namely redundant calls to ::get for unique_pointers. Jim justly noted that this is a good opportunity to clean up the variable names as well. I went over all the changes to ensure my find-and-replace didn't have any undesired side-effects. I hope I didn't miss any, but if you end up at this commit doing a git blame on a weirdly named variable, please know that the change was unintentional. llvm-svn: 353912
2019-02-13 14:25:41 +08:00
if (object_container_up)
object_file_sp = object_container_up->GetObjectFile(file);
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
<rdar://problem/11109570> The first part of the fix for having LLDB handle LTO debugging when the DWARF is in the .o files. This part separates the object file's modules into a separate cache map that maps unique C strings for the N_OSO path to the ModuleSP since one object file might be mentioned more than once in LTO binaries. llvm-svn: 174476
2013-02-06 08:38:25 +08:00
if (object_file_sp.get())
return object_file_sp;
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
}
}
Reflow paragraphs in comments. This is intended as a clean up after the big clang-format commit (r280751), which unfortunately resulted in many of the comment paragraphs in LLDB being very hard to read. FYI, the script I used was: import textwrap import commands import os import sys import re tmp = "%s.tmp"%sys.argv[1] out = open(tmp, "w+") with open(sys.argv[1], "r") as f: header = "" text = "" comment = re.compile(r'^( *//) ([^ ].*)$') special = re.compile(r'^((([A-Z]+[: ])|([0-9]+ )).*)|(.*;)$') for line in f: match = comment.match(line) if match and not special.match(match.group(2)): # skip intentionally short comments. if not text and len(match.group(2)) < 40: out.write(line) continue if text: text += " " + match.group(2) else: header = match.group(1) text = match.group(2) continue if text: filled = textwrap.wrap(text, width=(78-len(header)), break_long_words=False) for l in filled: out.write(header+" "+l+'\n') text = "" out.write(line) os.rename(tmp, sys.argv[1]) Differential Revision: https://reviews.llvm.org/D46144 llvm-svn: 331197
2018-05-01 00:49:04 +08:00
// 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.
<rdar://problem/13159777> lldb was mmap'ing archive files once per .o file it loads, now it correctly shares the archive between modules. LLDB was also always mapping entire contents of universal mach-o files, now it maps just the slice that is required. Added a new logging channel for "lldb" called "mmap" to help track future regressions. Modified the ObjectFile and ObjectContainer plugin interfaces to take a data offset along with the file offset and size so we can implement the correct caching and efficient reading of parts of files without mmap'ing the entire file like we used to. The current implementation still keeps entire .a files mmaped (once) and entire slices from universal files mmaped to ensure that if a client builds their binaries during a debug session we don't lose our data and get corrupt object file info and debug info. llvm-svn: 174524
2013-02-07 01:22:03 +08:00
if (file_size > 0) {
Re-land "Extract construction of DataBufferLLVM into FileSystem" This fixes some UB in isLocal detected by the sanitized bot. llvm-svn: 346707
2018-11-13 05:24:50 +08:00
data_sp = FileSystem::Instance().CreateDataBuffer(file->GetPath(),
512, file_offset);
<rdar://problem/13159777> lldb was mmap'ing archive files once per .o file it loads, now it correctly shares the archive between modules. LLDB was also always mapping entire contents of universal mach-o files, now it maps just the slice that is required. Added a new logging channel for "lldb" called "mmap" to help track future regressions. Modified the ObjectFile and ObjectContainer plugin interfaces to take a data offset along with the file offset and size so we can implement the correct caching and efficient reading of parts of files without mmap'ing the entire file like we used to. The current implementation still keeps entire .a files mmaped (once) and entire slices from universal files mmaped to ensure that if a client builds their binaries during a debug session we don't lose our data and get corrupt object file info and debug info. llvm-svn: 174524
2013-02-07 01:22:03 +08:00
data_offset = 0;
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
}
}
<rdar://problem/13159777> lldb was mmap'ing archive files once per .o file it loads, now it correctly shares the archive between modules. LLDB was also always mapping entire contents of universal mach-o files, now it maps just the slice that is required. Added a new logging channel for "lldb" called "mmap" to help track future regressions. Modified the ObjectFile and ObjectContainer plugin interfaces to take a data offset along with the file offset and size so we can implement the correct caching and efficient reading of parts of files without mmap'ing the entire file like we used to. The current implementation still keeps entire .a files mmaped (once) and entire slices from universal files mmaped to ensure that if a client builds their binaries during a debug session we don't lose our data and get corrupt object file info and debug info. llvm-svn: 174524
2013-02-07 01:22:03 +08:00
if (!data_sp || data_sp->GetByteSize() == 0) {
// Check for archive file with format "/path/to/archive.a(object.o)"
Replace regex match with rfind (NFCish) This change is mostly performance-neutral since our regex engine is fast, but it's IMHO slightly more readable. Also, matching matching parenthesis is not a great match for regular expressions. Differential Revision: https://reviews.llvm.org/D68609 llvm-svn: 374082
2019-10-09 00:29:39 +08:00
llvm::SmallString<256> path_with_object;
module_sp->GetFileSpec().GetPath(path_with_object);
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
After discussing with Chris Lattner, we require C++11, so lets get rid of the macros and just use C++11. llvm-svn: 179805
2013-04-19 06:45:39 +08:00
ConstString archive_object;
const bool must_exist = true;
if (ObjectFile::SplitArchivePathWithObject(
path_with_object, archive_file, archive_object, must_exist)) {
[FileSystem] Remove GetByteSize() from FileSpec This patch removes the GetByteSize method from FileSpec and updates its uses with calls to the FileSystem. Differential revision: https://reviews.llvm.org/D53788 llvm-svn: 345812
2018-11-01 12:45:28 +08:00
file_size = FileSystem::Instance().GetByteSize(archive_file);
<rdar://problem/13159777> lldb was mmap'ing archive files once per .o file it loads, now it correctly shares the archive between modules. LLDB was also always mapping entire contents of universal mach-o files, now it maps just the slice that is required. Added a new logging channel for "lldb" called "mmap" to help track future regressions. Modified the ObjectFile and ObjectContainer plugin interfaces to take a data offset along with the file offset and size so we can implement the correct caching and efficient reading of parts of files without mmap'ing the entire file like we used to. The current implementation still keeps entire .a files mmaped (once) and entire slices from universal files mmaped to ensure that if a client builds their binaries during a debug session we don't lose our data and get corrupt object file info and debug info. llvm-svn: 174524
2013-02-07 01:22:03 +08:00
if (file_size > 0) {
file = &archive_file;
module_sp->SetFileSpecAndObjectName(archive_file, archive_object);
Big change in the way ObjectFile file contents are managed. We now mmap() the entire object file contents into memory with MAP_PRIVATE. We do this because object file contents can change on us and currently this helps alleviate this situation. It also make the code for accessing object file data much easier to manage and we don't end up opening the file, reading some data and closing the file over and over. llvm-svn: 148017
2012-01-12 13:25:17 +08:00
// Check if this is a object container by iterating through all
Reflow paragraphs in comments. This is intended as a clean up after the big clang-format commit (r280751), which unfortunately resulted in many of the comment paragraphs in LLDB being very hard to read. FYI, the script I used was: import textwrap import commands import os import sys import re tmp = "%s.tmp"%sys.argv[1] out = open(tmp, "w+") with open(sys.argv[1], "r") as f: header = "" text = "" comment = re.compile(r'^( *//) ([^ ].*)$') special = re.compile(r'^((([A-Z]+[: ])|([0-9]+ )).*)|(.*;)$') for line in f: match = comment.match(line) if match and not special.match(match.group(2)): # skip intentionally short comments. if not text and len(match.group(2)) < 40: out.write(line) continue if text: text += " " + match.group(2) else: header = match.group(1) text = match.group(2) continue if text: filled = textwrap.wrap(text, width=(78-len(header)), break_long_words=False) for l in filled: out.write(header+" "+l+'\n') text = "" out.write(line) os.rename(tmp, sys.argv[1]) Differential Revision: https://reviews.llvm.org/D46144 llvm-svn: 331197
2018-05-01 00:49:04 +08:00
// 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
Big change in the way ObjectFile file contents are managed. We now mmap() the entire object file contents into memory with MAP_PRIVATE. We do this because object file contents can change on us and currently this helps alleviate this situation. It also make the code for accessing object file data much easier to manage and we don't end up opening the file, reading some data and closing the file over and over. llvm-svn: 148017
2012-01-12 13:25:17 +08:00
// ANY data in case there is data cached in the container plug-ins
Reflow paragraphs in comments. This is intended as a clean up after the big clang-format commit (r280751), which unfortunately resulted in many of the comment paragraphs in LLDB being very hard to read. FYI, the script I used was: import textwrap import commands import os import sys import re tmp = "%s.tmp"%sys.argv[1] out = open(tmp, "w+") with open(sys.argv[1], "r") as f: header = "" text = "" comment = re.compile(r'^( *//) ([^ ].*)$') special = re.compile(r'^((([A-Z]+[: ])|([0-9]+ )).*)|(.*;)$') for line in f: match = comment.match(line) if match and not special.match(match.group(2)): # skip intentionally short comments. if not text and len(match.group(2)) < 40: out.write(line) continue if text: text += " " + match.group(2) else: header = match.group(1) text = match.group(2) continue if text: filled = textwrap.wrap(text, width=(78-len(header)), break_long_words=False) for l in filled: out.write(header+" "+l+'\n') text = "" out.write(line) os.rename(tmp, sys.argv[1]) Differential Revision: https://reviews.llvm.org/D46144 llvm-svn: 331197
2018-05-01 00:49:04 +08:00
// (like BSD archives caching the contained objects within an
// file).
Switch NULL to C++11 nullptr in source/Symbol and source/Utility Patch by Robert Matusewicz llvm-svn: 206713
2014-04-20 21:17:36 +08:00
for (uint32_t idx = 0;
(create_object_container_callback =
PluginManager::GetObjectContainerCreateCallbackAtIndex(
idx)) != nullptr;
++idx) {
Replace 'ap' with 'up' suffix in variable names. (NFC) The `ap` suffix is a remnant of lldb's former use of auto pointers, before they got deprecated. Although all their uses were replaced by unique pointers, some variables still carried the suffix. In r353795 I removed another auto_ptr remnant, namely redundant calls to ::get for unique_pointers. Jim justly noted that this is a good opportunity to clean up the variable names as well. I went over all the changes to ensure my find-and-replace didn't have any undesired side-effects. I hope I didn't miss any, but if you end up at this commit doing a git blame on a weirdly named variable, please know that the change was unintentional. llvm-svn: 353912
2019-02-13 14:25:41 +08:00
std::unique_ptr<ObjectContainer> object_container_up(
After discussing with Chris Lattner, we require C++11, so lets get rid of the macros and just use C++11. llvm-svn: 179805
2013-04-19 06:45:39 +08:00
create_object_container_callback(module_sp, data_sp,
data_offset, file,
file_offset, file_size));
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
Replace 'ap' with 'up' suffix in variable names. (NFC) The `ap` suffix is a remnant of lldb's former use of auto pointers, before they got deprecated. Although all their uses were replaced by unique pointers, some variables still carried the suffix. In r353795 I removed another auto_ptr remnant, namely redundant calls to ::get for unique_pointers. Jim justly noted that this is a good opportunity to clean up the variable names as well. I went over all the changes to ensure my find-and-replace didn't have any undesired side-effects. I hope I didn't miss any, but if you end up at this commit doing a git blame on a weirdly named variable, please know that the change was unintentional. llvm-svn: 353912
2019-02-13 14:25:41 +08:00
if (object_container_up)
object_file_sp = object_container_up->GetObjectFile(file);
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
Big change in the way ObjectFile file contents are managed. We now mmap() the entire object file contents into memory with MAP_PRIVATE. We do this because object file contents can change on us and currently this helps alleviate this situation. It also make the code for accessing object file data much easier to manage and we don't end up opening the file, reading some data and closing the file over and over. llvm-svn: 148017
2012-01-12 13:25:17 +08:00
if (object_file_sp.get())
return object_file_sp;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
Reflow paragraphs in comments. This is intended as a clean up after the big clang-format commit (r280751), which unfortunately resulted in many of the comment paragraphs in LLDB being very hard to read. FYI, the script I used was: import textwrap import commands import os import sys import re tmp = "%s.tmp"%sys.argv[1] out = open(tmp, "w+") with open(sys.argv[1], "r") as f: header = "" text = "" comment = re.compile(r'^( *//) ([^ ].*)$') special = re.compile(r'^((([A-Z]+[: ])|([0-9]+ )).*)|(.*;)$') for line in f: match = comment.match(line) if match and not special.match(match.group(2)): # skip intentionally short comments. if not text and len(match.group(2)) < 40: out.write(line) continue if text: text += " " + match.group(2) else: header = match.group(1) text = match.group(2) continue if text: filled = textwrap.wrap(text, width=(78-len(header)), break_long_words=False) for l in filled: out.write(header+" "+l+'\n') text = "" out.write(line) os.rename(tmp, sys.argv[1]) Differential Revision: https://reviews.llvm.org/D46144 llvm-svn: 331197
2018-05-01 00:49:04 +08:00
// We failed to find any cached object files in the container plug-
// ins, so lets read the first 512 bytes and try again below...
Re-land "Extract construction of DataBufferLLVM into FileSystem" This fixes some UB in isLocal detected by the sanitized bot. llvm-svn: 346707
2018-11-13 05:24:50 +08:00
data_sp = FileSystem::Instance().CreateDataBuffer(
archive_file.GetPath(), 512, file_offset);
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
Don't put modules for .o files into the global shared module list. We used to do this because we needed to find the shared pointer for a .o file when the .o file's module was needed in a SymbolContext since the module in a symbol context was a shared pointer. Now that we are using intrusive pointers we don't have this limitation anymore since any instrusive shared pointer can be made from a pointer to an object all on its own. Also switched over to having the Module and SymbolVendor use shared pointers to their object files as had a leak on MacOSX when the SymbolVendor's object file wasn't the same as the Module's (debug info in a stand along file (dSYM file)). Now everything will correctly clean itself up when the module goes away after an executable gets rebuilt. Now we correctly get rid of .o files that are used with the DWARF with debug map executables on subsequent runs since the only shared pointer to the object files in from the DWARF symbol file debug map parser, and when the module gets replaced, it destroys to old one along with all .o files. Also added a small optimization when using BSD archives where we will remove old BSD containers from the shared list when they are outdated. llvm-svn: 140002
2011-09-19 02:59:15 +08:00
}
sweep up -Wformat warnings from gcc This is a purely mechanical change explicitly casting any parameters for printf style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux. llvm-svn: 205607
2014-04-04 12:06:10 +08:00
<rdar://problem/13159777> lldb was mmap'ing archive files once per .o file it loads, now it correctly shares the archive between modules. LLDB was also always mapping entire contents of universal mach-o files, now it maps just the slice that is required. Added a new logging channel for "lldb" called "mmap" to help track future regressions. Modified the ObjectFile and ObjectContainer plugin interfaces to take a data offset along with the file offset and size so we can implement the correct caching and efficient reading of parts of files without mmap'ing the entire file like we used to. The current implementation still keeps entire .a files mmaped (once) and entire slices from universal files mmaped to ensure that if a client builds their binaries during a debug session we don't lose our data and get corrupt object file info and debug info. llvm-svn: 174524
2013-02-07 01:22:03 +08:00
if (data_sp && data_sp->GetByteSize() > 0) {
Reflow paragraphs in comments. This is intended as a clean up after the big clang-format commit (r280751), which unfortunately resulted in many of the comment paragraphs in LLDB being very hard to read. FYI, the script I used was: import textwrap import commands import os import sys import re tmp = "%s.tmp"%sys.argv[1] out = open(tmp, "w+") with open(sys.argv[1], "r") as f: header = "" text = "" comment = re.compile(r'^( *//) ([^ ].*)$') special = re.compile(r'^((([A-Z]+[: ])|([0-9]+ )).*)|(.*;)$') for line in f: match = comment.match(line) if match and not special.match(match.group(2)): # skip intentionally short comments. if not text and len(match.group(2)) < 40: out.write(line) continue if text: text += " " + match.group(2) else: header = match.group(1) text = match.group(2) continue if text: filled = textwrap.wrap(text, width=(78-len(header)), break_long_words=False) for l in filled: out.write(header+" "+l+'\n') text = "" out.write(line) os.rename(tmp, sys.argv[1]) Differential Revision: https://reviews.llvm.org/D46144 llvm-svn: 331197
2018-05-01 00:49:04 +08:00
// Check if this is a normal object file by iterating through all
// object file plugin instances.
<rdar://problem/10560053> Fixed "target modules list" (aliased to "image list") to output more information by default. Modified the "target modules list" to have a few new options: "--header" or "-h" => show the image header address "--offset" or "-o" => show the image header address offset from the address in the file (the slide applied to the shared library) Removed the "--symfile-basename" or "-S" option, and repurposed it to "--symfile-unique" "-S" which will show the symbol file if it differs from the executable file. ObjectFile's can now be loaded from memory for cases where we don't have the files cached locally in an SDK or net mounted root. ObjectFileMachO can now read mach files from memory. Moved the section data reading code into the ObjectFile so that the object file can get the section data from Process memory if the file is only in memory. lldb_private::Module can now load its object file in a target with a rigid slide (very common operation for most dynamic linkers) by using: bool Module::SetLoadAddress (Target &target, lldb::addr_t offset, bool &changed) lldb::SBModule() now has a new constructor in the public interface: SBModule::SBModule (lldb::SBProcess &process, lldb::addr_t header_addr); This will find an appropriate ObjectFile plug-in to load an image from memory where the object file header is at "header_addr". llvm-svn: 149804
2012-02-05 10:38:54 +08:00
ObjectFileCreateInstance create_object_file_callback;
Switch NULL to C++11 nullptr in source/Symbol and source/Utility Patch by Robert Matusewicz llvm-svn: 206713
2014-04-20 21:17:36 +08:00
for (uint32_t idx = 0;
(create_object_file_callback =
PluginManager::GetObjectFileCreateCallbackAtIndex(idx)) !=
nullptr;
++idx) {
<rdar://problem/13159777> lldb was mmap'ing archive files once per .o file it loads, now it correctly shares the archive between modules. LLDB was also always mapping entire contents of universal mach-o files, now it maps just the slice that is required. Added a new logging channel for "lldb" called "mmap" to help track future regressions. Modified the ObjectFile and ObjectContainer plugin interfaces to take a data offset along with the file offset and size so we can implement the correct caching and efficient reading of parts of files without mmap'ing the entire file like we used to. The current implementation still keeps entire .a files mmaped (once) and entire slices from universal files mmaped to ensure that if a client builds their binaries during a debug session we don't lose our data and get corrupt object file info and debug info. llvm-svn: 174524
2013-02-07 01:22:03 +08:00
object_file_sp.reset(create_object_file_callback(
module_sp, data_sp, data_offset, file, file_offset, file_size));
<rdar://problem/10560053> Fixed "target modules list" (aliased to "image list") to output more information by default. Modified the "target modules list" to have a few new options: "--header" or "-h" => show the image header address "--offset" or "-o" => show the image header address offset from the address in the file (the slide applied to the shared library) Removed the "--symfile-basename" or "-S" option, and repurposed it to "--symfile-unique" "-S" which will show the symbol file if it differs from the executable file. ObjectFile's can now be loaded from memory for cases where we don't have the files cached locally in an SDK or net mounted root. ObjectFileMachO can now read mach files from memory. Moved the section data reading code into the ObjectFile so that the object file can get the section data from Process memory if the file is only in memory. lldb_private::Module can now load its object file in a target with a rigid slide (very common operation for most dynamic linkers) by using: bool Module::SetLoadAddress (Target &target, lldb::addr_t offset, bool &changed) lldb::SBModule() now has a new constructor in the public interface: SBModule::SBModule (lldb::SBProcess &process, lldb::addr_t header_addr); This will find an appropriate ObjectFile plug-in to load an image from memory where the object file header is at "header_addr". llvm-svn: 149804
2012-02-05 10:38:54 +08:00
if (object_file_sp.get())
return object_file_sp;
}
Reflow paragraphs in comments. This is intended as a clean up after the big clang-format commit (r280751), which unfortunately resulted in many of the comment paragraphs in LLDB being very hard to read. FYI, the script I used was: import textwrap import commands import os import sys import re tmp = "%s.tmp"%sys.argv[1] out = open(tmp, "w+") with open(sys.argv[1], "r") as f: header = "" text = "" comment = re.compile(r'^( *//) ([^ ].*)$') special = re.compile(r'^((([A-Z]+[: ])|([0-9]+ )).*)|(.*;)$') for line in f: match = comment.match(line) if match and not special.match(match.group(2)): # skip intentionally short comments. if not text and len(match.group(2)) < 40: out.write(line) continue if text: text += " " + match.group(2) else: header = match.group(1) text = match.group(2) continue if text: filled = textwrap.wrap(text, width=(78-len(header)), break_long_words=False) for l in filled: out.write(header+" "+l+'\n') text = "" out.write(line) os.rename(tmp, sys.argv[1]) Differential Revision: https://reviews.llvm.org/D46144 llvm-svn: 331197
2018-05-01 00:49:04 +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.
Switch NULL to C++11 nullptr in source/Symbol and source/Utility Patch by Robert Matusewicz llvm-svn: 206713
2014-04-20 21:17:36 +08:00
for (uint32_t idx = 0;
Added the ability to extract a ModuleSpecList (a new class) from an ObjectFile. This is designed to be used when you have an object file that contains one or more architectures (MacOSX universal (fat) files) and/or one or more objects (BSD archive (.a files)). There is a new static ObjectFile function you can call: size_t ObjectFile::GetModuleSpecifications (const FileSpec &file, lldb::offset_t file_offset, ModuleSpecList &specs) This will fill in "specs" which the details of all the module specs (file + arch + UUID (if there is one) + object name (for BSD archive objects eventually) + file offset to the object in question). This helps us when a user specifies a file that contains a single architecture, and also helps us when we are given a debug symbol file (like a dSYM file on MacOSX) that contains one or more architectures and we need to be able to match it up to an existing Module that has no debug info. llvm-svn: 180224
2013-04-25 06:29:28 +08:00
(create_object_container_callback =
PluginManager::GetObjectContainerCreateCallbackAtIndex(
idx)) != nullptr;
++idx) {
Replace 'ap' with 'up' suffix in variable names. (NFC) The `ap` suffix is a remnant of lldb's former use of auto pointers, before they got deprecated. Although all their uses were replaced by unique pointers, some variables still carried the suffix. In r353795 I removed another auto_ptr remnant, namely redundant calls to ::get for unique_pointers. Jim justly noted that this is a good opportunity to clean up the variable names as well. I went over all the changes to ensure my find-and-replace didn't have any undesired side-effects. I hope I didn't miss any, but if you end up at this commit doing a git blame on a weirdly named variable, please know that the change was unintentional. llvm-svn: 353912
2019-02-13 14:25:41 +08:00
std::unique_ptr<ObjectContainer> object_container_up(
Added the ability to extract a ModuleSpecList (a new class) from an ObjectFile. This is designed to be used when you have an object file that contains one or more architectures (MacOSX universal (fat) files) and/or one or more objects (BSD archive (.a files)). There is a new static ObjectFile function you can call: size_t ObjectFile::GetModuleSpecifications (const FileSpec &file, lldb::offset_t file_offset, ModuleSpecList &specs) This will fill in "specs" which the details of all the module specs (file + arch + UUID (if there is one) + object name (for BSD archive objects eventually) + file offset to the object in question). This helps us when a user specifies a file that contains a single architecture, and also helps us when we are given a debug symbol file (like a dSYM file on MacOSX) that contains one or more architectures and we need to be able to match it up to an existing Module that has no debug info. llvm-svn: 180224
2013-04-25 06:29:28 +08:00
create_object_container_callback(module_sp, data_sp, data_offset,
Fixed GetModuleSpecifications() to work better overall: - MachO files now correctly extract the UUID all the time - More file size and offset verification done for universal mach-o files to watch for truncated files - ObjectContainerBSDArchive now supports enumerating all objects in BSD archives (.a files) - lldb_private::Module() can not be properly constructed using a ModuleSpec for a .o file in a .a file - The BSD archive plug-in shares its cache for GetModuleSpecifications() and the create callback - Improved printing for ModuleSpec objects llvm-svn: 186211
2013-07-13 06:07:46 +08:00
file, file_offset, file_size));
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
Replace 'ap' with 'up' suffix in variable names. (NFC) The `ap` suffix is a remnant of lldb's former use of auto pointers, before they got deprecated. Although all their uses were replaced by unique pointers, some variables still carried the suffix. In r353795 I removed another auto_ptr remnant, namely redundant calls to ::get for unique_pointers. Jim justly noted that this is a good opportunity to clean up the variable names as well. I went over all the changes to ensure my find-and-replace didn't have any undesired side-effects. I hope I didn't miss any, but if you end up at this commit doing a git blame on a weirdly named variable, please know that the change was unintentional. llvm-svn: 353912
2019-02-13 14:25:41 +08:00
if (object_container_up)
object_file_sp = object_container_up->GetObjectFile(file);
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
Big change in the way ObjectFile file contents are managed. We now mmap() the entire object file contents into memory with MAP_PRIVATE. We do this because object file contents can change on us and currently this helps alleviate this situation. It also make the code for accessing object file data much easier to manage and we don't end up opening the file, reading some data and closing the file over and over. llvm-svn: 148017
2012-01-12 13:25:17 +08:00
if (object_file_sp.get())
Fixed GetModuleSpecifications() to work better overall: - MachO files now correctly extract the UUID all the time - More file size and offset verification done for universal mach-o files to watch for truncated files - ObjectContainerBSDArchive now supports enumerating all objects in BSD archives (.a files) - lldb_private::Module() can not be properly constructed using a ModuleSpec for a .o file in a .a file - The BSD archive plug-in shares its cache for GetModuleSpecifications() and the create callback - Improved printing for ModuleSpec objects llvm-svn: 186211
2013-07-13 06:07:46 +08:00
return object_file_sp;
}
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
}
Fixed GetModuleSpecifications() to work better overall: - MachO files now correctly extract the UUID all the time - More file size and offset verification done for universal mach-o files to watch for truncated files - ObjectContainerBSDArchive now supports enumerating all objects in BSD archives (.a files) - lldb_private::Module() can not be properly constructed using a ModuleSpec for a .o file in a .a file - The BSD archive plug-in shares its cache for GetModuleSpecifications() and the create callback - Improved printing for ModuleSpec objects llvm-svn: 186211
2013-07-13 06:07:46 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
}
Reflow paragraphs in comments. This is intended as a clean up after the big clang-format commit (r280751), which unfortunately resulted in many of the comment paragraphs in LLDB being very hard to read. FYI, the script I used was: import textwrap import commands import os import sys import re tmp = "%s.tmp"%sys.argv[1] out = open(tmp, "w+") with open(sys.argv[1], "r") as f: header = "" text = "" comment = re.compile(r'^( *//) ([^ ].*)$') special = re.compile(r'^((([A-Z]+[: ])|([0-9]+ )).*)|(.*;)$') for line in f: match = comment.match(line) if match and not special.match(match.group(2)): # skip intentionally short comments. if not text and len(match.group(2)) < 40: out.write(line) continue if text: text += " " + match.group(2) else: header = match.group(1) text = match.group(2) continue if text: filled = textwrap.wrap(text, width=(78-len(header)), break_long_words=False) for l in filled: out.write(header+" "+l+'\n') text = "" out.write(line) os.rename(tmp, sys.argv[1]) Differential Revision: https://reviews.llvm.org/D46144 llvm-svn: 331197
2018-05-01 00:49:04 +08:00
// We didn't find it, so clear our shared pointer in case it contains
// anything and return an empty shared pointer
Don't put modules for .o files into the global shared module list. We used to do this because we needed to find the shared pointer for a .o file when the .o file's module was needed in a SymbolContext since the module in a symbol context was a shared pointer. Now that we are using intrusive pointers we don't have this limitation anymore since any instrusive shared pointer can be made from a pointer to an object all on its own. Also switched over to having the Module and SymbolVendor use shared pointers to their object files as had a leak on MacOSX when the SymbolVendor's object file wasn't the same as the Module's (debug info in a stand along file (dSYM file)). Now everything will correctly clean itself up when the module goes away after an executable gets rebuilt. Now we correctly get rid of .o files that are used with the DWARF with debug map executables on subsequent runs since the only shared pointer to the object files in from the DWARF symbol file debug map parser, and when the module gets replaced, it destroys to old one along with all .o files. Also added a small optimization when using BSD archives where we will remove old BSD containers from the shared list when they are outdated. llvm-svn: 140002
2011-09-19 02:59:15 +08:00
object_file_sp.reset();
Added the ability to extract a ModuleSpecList (a new class) from an ObjectFile. This is designed to be used when you have an object file that contains one or more architectures (MacOSX universal (fat) files) and/or one or more objects (BSD archive (.a files)). There is a new static ObjectFile function you can call: size_t ObjectFile::GetModuleSpecifications (const FileSpec &file, lldb::offset_t file_offset, ModuleSpecList &specs) This will fill in "specs" which the details of all the module specs (file + arch + UUID (if there is one) + object name (for BSD archive objects eventually) + file offset to the object in question). This helps us when a user specifies a file that contains a single architecture, and also helps us when we are given a debug symbol file (like a dSYM file on MacOSX) that contains one or more architectures and we need to be able to match it up to an existing Module that has no debug info. llvm-svn: 180224
2013-04-25 06:29:28 +08:00
return object_file_sp;
}
ObjectFileSP ObjectFile::FindPlugin(const lldb::ModuleSP &module_sp,
const ProcessSP &process_sp,
lldb::addr_t header_addr,
DataBufferSP &data_sp) {
ObjectFileSP object_file_sp;
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
<rdar://problem/10103468> I started work on being able to add symbol files after a debug session had started with a new "target symfile add" command and quickly ran into problems with stale Address objects in breakpoint locations that had lldb_private::Section pointers into modules that had been removed or replaced. This also let to grabbing stale modules from those sections. So I needed to thread harded the Address, Section and related objects. To do this I modified the ModuleChild class to now require a ModuleSP on initialization so that a weak reference can created. I also changed all places that were handing out "Section *" to have them hand out SectionSP. All ObjectFile, SymbolFile and SymbolVendors were inheriting from ModuleChild so all of the find plug-in, static creation function and constructors now require ModuleSP references instead of Module *. Address objects now have weak references to their sections which can safely go stale when a module gets destructed. This checkin doesn't complete the "target symfile add" command, but it does get us a lot clioser to being able to do such things without a high risk of crashing or memory corruption. llvm-svn: 151336
2012-02-24 09:59:29 +08:00
if (module_sp) {
Remove an expensive lock from Timer The Timer destructor would grab a global mutex in order to update execution time. Add a class to define a category once, statically; the class adds itself to an atomic singly linked list, and thus subsequent updates only need to use an atomic rather than grab a lock and perform a hashtable lookup. Differential Revision: https://reviews.llvm.org/D32823 Patch by Scott Smith <scott.smith@purestorage.com>. llvm-svn: 303058
2017-05-15 21:02:37 +08:00
static Timer::Category func_cat(LLVM_PRETTY_FUNCTION);
Timer scoped_timer(func_cat,
"ObjectFile::FindPlugin (module = "
"%s, process = %p, header_addr = "
"0x%" PRIx64 ")",
Added the ability to extract a ModuleSpecList (a new class) from an ObjectFile. This is designed to be used when you have an object file that contains one or more architectures (MacOSX universal (fat) files) and/or one or more objects (BSD archive (.a files)). There is a new static ObjectFile function you can call: size_t ObjectFile::GetModuleSpecifications (const FileSpec &file, lldb::offset_t file_offset, ModuleSpecList &specs) This will fill in "specs" which the details of all the module specs (file + arch + UUID (if there is one) + object name (for BSD archive objects eventually) + file offset to the object in question). This helps us when a user specifies a file that contains a single architecture, and also helps us when we are given a debug symbol file (like a dSYM file on MacOSX) that contains one or more architectures and we need to be able to match it up to an existing Module that has no debug info. llvm-svn: 180224
2013-04-25 06:29:28 +08:00
module_sp->GetFileSpec().GetPath().c_str(),
static_cast<void *>(process_sp.get()), header_addr);
uint32_t idx;
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
Reflow paragraphs in comments. This is intended as a clean up after the big clang-format commit (r280751), which unfortunately resulted in many of the comment paragraphs in LLDB being very hard to read. FYI, the script I used was: import textwrap import commands import os import sys import re tmp = "%s.tmp"%sys.argv[1] out = open(tmp, "w+") with open(sys.argv[1], "r") as f: header = "" text = "" comment = re.compile(r'^( *//) ([^ ].*)$') special = re.compile(r'^((([A-Z]+[: ])|([0-9]+ )).*)|(.*;)$') for line in f: match = comment.match(line) if match and not special.match(match.group(2)): # skip intentionally short comments. if not text and len(match.group(2)) < 40: out.write(line) continue if text: text += " " + match.group(2) else: header = match.group(1) text = match.group(2) continue if text: filled = textwrap.wrap(text, width=(78-len(header)), break_long_words=False) for l in filled: out.write(header+" "+l+'\n') text = "" out.write(line) os.rename(tmp, sys.argv[1]) Differential Revision: https://reviews.llvm.org/D46144 llvm-svn: 331197
2018-05-01 00:49:04 +08:00
// Check if this is a normal object file by iterating through all object
// file plugin instances.
Added the ability to extract a ModuleSpecList (a new class) from an ObjectFile. This is designed to be used when you have an object file that contains one or more architectures (MacOSX universal (fat) files) and/or one or more objects (BSD archive (.a files)). There is a new static ObjectFile function you can call: size_t ObjectFile::GetModuleSpecifications (const FileSpec &file, lldb::offset_t file_offset, ModuleSpecList &specs) This will fill in "specs" which the details of all the module specs (file + arch + UUID (if there is one) + object name (for BSD archive objects eventually) + file offset to the object in question). This helps us when a user specifies a file that contains a single architecture, and also helps us when we are given a debug symbol file (like a dSYM file on MacOSX) that contains one or more architectures and we need to be able to match it up to an existing Module that has no debug info. llvm-svn: 180224
2013-04-25 06:29:28 +08:00
ObjectFileCreateMemoryInstance create_callback;
Switch NULL to C++11 nullptr in source/Symbol and source/Utility Patch by Robert Matusewicz llvm-svn: 206713
2014-04-20 21:17:36 +08:00
for (idx = 0;
(create_callback =
PluginManager::GetObjectFileCreateMemoryCallbackAtIndex(idx)) !=
nullptr;
++idx) {
Fixed GetModuleSpecifications() to work better overall: - MachO files now correctly extract the UUID all the time - More file size and offset verification done for universal mach-o files to watch for truncated files - ObjectContainerBSDArchive now supports enumerating all objects in BSD archives (.a files) - lldb_private::Module() can not be properly constructed using a ModuleSpec for a .o file in a .a file - The BSD archive plug-in shares its cache for GetModuleSpecifications() and the create callback - Improved printing for ModuleSpec objects llvm-svn: 186211
2013-07-13 06:07:46 +08:00
object_file_sp.reset(
create_callback(module_sp, data_sp, process_sp, header_addr));
if (object_file_sp.get())
Added the ability to extract a ModuleSpecList (a new class) from an ObjectFile. This is designed to be used when you have an object file that contains one or more architectures (MacOSX universal (fat) files) and/or one or more objects (BSD archive (.a files)). There is a new static ObjectFile function you can call: size_t ObjectFile::GetModuleSpecifications (const FileSpec &file, lldb::offset_t file_offset, ModuleSpecList &specs) This will fill in "specs" which the details of all the module specs (file + arch + UUID (if there is one) + object name (for BSD archive objects eventually) + file offset to the object in question). This helps us when a user specifies a file that contains a single architecture, and also helps us when we are given a debug symbol file (like a dSYM file on MacOSX) that contains one or more architectures and we need to be able to match it up to an existing Module that has no debug info. llvm-svn: 180224
2013-04-25 06:29:28 +08:00
return object_file_sp;
}
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
}
Added the ability to extract a ModuleSpecList (a new class) from an ObjectFile. This is designed to be used when you have an object file that contains one or more architectures (MacOSX universal (fat) files) and/or one or more objects (BSD archive (.a files)). There is a new static ObjectFile function you can call: size_t ObjectFile::GetModuleSpecifications (const FileSpec &file, lldb::offset_t file_offset, ModuleSpecList &specs) This will fill in "specs" which the details of all the module specs (file + arch + UUID (if there is one) + object name (for BSD archive objects eventually) + file offset to the object in question). This helps us when a user specifies a file that contains a single architecture, and also helps us when we are given a debug symbol file (like a dSYM file on MacOSX) that contains one or more architectures and we need to be able to match it up to an existing Module that has no debug info. llvm-svn: 180224
2013-04-25 06:29:28 +08:00
Reflow paragraphs in comments. This is intended as a clean up after the big clang-format commit (r280751), which unfortunately resulted in many of the comment paragraphs in LLDB being very hard to read. FYI, the script I used was: import textwrap import commands import os import sys import re tmp = "%s.tmp"%sys.argv[1] out = open(tmp, "w+") with open(sys.argv[1], "r") as f: header = "" text = "" comment = re.compile(r'^( *//) ([^ ].*)$') special = re.compile(r'^((([A-Z]+[: ])|([0-9]+ )).*)|(.*;)$') for line in f: match = comment.match(line) if match and not special.match(match.group(2)): # skip intentionally short comments. if not text and len(match.group(2)) < 40: out.write(line) continue if text: text += " " + match.group(2) else: header = match.group(1) text = match.group(2) continue if text: filled = textwrap.wrap(text, width=(78-len(header)), break_long_words=False) for l in filled: out.write(header+" "+l+'\n') text = "" out.write(line) os.rename(tmp, sys.argv[1]) Differential Revision: https://reviews.llvm.org/D46144 llvm-svn: 331197
2018-05-01 00:49:04 +08:00
// We didn't find it, so clear our shared pointer in case it contains
// anything and return an empty shared pointer
Switch NULL to C++11 nullptr in source/Symbol and source/Utility Patch by Robert Matusewicz llvm-svn: 206713
2014-04-20 21:17:36 +08:00
object_file_sp.reset();
Added the ability to extract a ModuleSpecList (a new class) from an ObjectFile. This is designed to be used when you have an object file that contains one or more architectures (MacOSX universal (fat) files) and/or one or more objects (BSD archive (.a files)). There is a new static ObjectFile function you can call: size_t ObjectFile::GetModuleSpecifications (const FileSpec &file, lldb::offset_t file_offset, ModuleSpecList &specs) This will fill in "specs" which the details of all the module specs (file + arch + UUID (if there is one) + object name (for BSD archive objects eventually) + file offset to the object in question). This helps us when a user specifies a file that contains a single architecture, and also helps us when we are given a debug symbol file (like a dSYM file on MacOSX) that contains one or more architectures and we need to be able to match it up to an existing Module that has no debug info. llvm-svn: 180224
2013-04-25 06:29:28 +08:00
return object_file_sp;
}
size_t ObjectFile::GetModuleSpecifications(const FileSpec &file,
<rdar://problem/13159777> lldb was mmap'ing archive files once per .o file it loads, now it correctly shares the archive between modules. LLDB was also always mapping entire contents of universal mach-o files, now it maps just the slice that is required. Added a new logging channel for "lldb" called "mmap" to help track future regressions. Modified the ObjectFile and ObjectContainer plugin interfaces to take a data offset along with the file offset and size so we can implement the correct caching and efficient reading of parts of files without mmap'ing the entire file like we used to. The current implementation still keeps entire .a files mmaped (once) and entire slices from universal files mmaped to ensure that if a client builds their binaries during a debug session we don't lose our data and get corrupt object file info and debug info. llvm-svn: 174524
2013-02-07 01:22:03 +08:00
lldb::offset_t file_offset,
lldb::offset_t file_size,
JITed functions can now have debug info and be debugged with debug and source info: (lldb) b puts (lldb) expr -g -i0 -- (int)puts("hello") First we will stop at the entry point of the expression before it runs, then we can step over a few times and hit the breakpoint in "puts", then we can continue and finishing stepping and fininsh the expression. Main features: - New ObjectFileJIT class that can be easily created for JIT functions - debug info can now be enabled when parsing expressions - source for any function that is run throught the JIT is now saved in LLDB process specific temp directory and cleaned up on exit - "expr -g --" allows you to single step through your expression function with source code <rdar://problem/16382881> llvm-svn: 204682
2014-03-25 07:10:19 +08:00
ModuleSpecList &specs) {
Re-land "Extract construction of DataBufferLLVM into FileSystem" This fixes some UB in isLocal detected by the sanitized bot. llvm-svn: 346707
2018-11-13 05:24:50 +08:00
DataBufferSP data_sp =
FileSystem::Instance().CreateDataBuffer(file.GetPath(), 512, file_offset);
Improve the handling of missing elf symtab and missing symbol sizes * Generate artificial symbol names from eh_fame during symbol parsing so these symbols are already present when we calcualte the size of the symbols where 0 is specified. * Fix symbol size calculation for the last symbol in the file where it have to last until the end of the parent section. This is the re-commit of the original change after fixing some test failures on OSX. Differential revision: http://reviews.llvm.org/D16996 llvm-svn: 261205
2016-02-18 19:12:18 +08:00
if (data_sp) {
Don't put modules for .o files into the global shared module list. We used to do this because we needed to find the shared pointer for a .o file when the .o file's module was needed in a SymbolContext since the module in a symbol context was a shared pointer. Now that we are using intrusive pointers we don't have this limitation anymore since any instrusive shared pointer can be made from a pointer to an object all on its own. Also switched over to having the Module and SymbolVendor use shared pointers to their object files as had a leak on MacOSX when the SymbolVendor's object file wasn't the same as the Module's (debug info in a stand along file (dSYM file)). Now everything will correctly clean itself up when the module goes away after an executable gets rebuilt. Now we correctly get rid of .o files that are used with the DWARF with debug map executables on subsequent runs since the only shared pointer to the object files in from the DWARF symbol file debug map parser, and when the module gets replaced, it destroys to old one along with all .o files. Also added a small optimization when using BSD archives where we will remove old BSD containers from the shared list when they are outdated. llvm-svn: 140002
2011-09-19 02:59:15 +08:00
if (file_size == 0) {
[FileSystem] Remove GetByteSize() from FileSpec This patch removes the GetByteSize method from FileSpec and updates its uses with calls to the FileSystem. Differential revision: https://reviews.llvm.org/D53788 llvm-svn: 345812
2018-11-01 12:45:28 +08:00
const lldb::offset_t actual_file_size =
FileSystem::Instance().GetByteSize(file);
<rdar://problem/13159777> lldb was mmap'ing archive files once per .o file it loads, now it correctly shares the archive between modules. LLDB was also always mapping entire contents of universal mach-o files, now it maps just the slice that is required. Added a new logging channel for "lldb" called "mmap" to help track future regressions. Modified the ObjectFile and ObjectContainer plugin interfaces to take a data offset along with the file offset and size so we can implement the correct caching and efficient reading of parts of files without mmap'ing the entire file like we used to. The current implementation still keeps entire .a files mmaped (once) and entire slices from universal files mmaped to ensure that if a client builds their binaries during a debug session we don't lose our data and get corrupt object file info and debug info. llvm-svn: 174524
2013-02-07 01:22:03 +08:00
if (actual_file_size > file_offset)
sweep up -Wformat warnings from gcc This is a purely mechanical change explicitly casting any parameters for printf style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux. llvm-svn: 205607
2014-04-04 12:06:10 +08:00
file_size = actual_file_size - file_offset;
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
}
sweep up -Wformat warnings from gcc This is a purely mechanical change explicitly casting any parameters for printf style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux. llvm-svn: 205607
2014-04-04 12:06:10 +08:00
return ObjectFile::GetModuleSpecifications(file, // file spec
data_sp, // data bytes
0, // data offset
file_offset, // file offset
file_size, // file length
specs);
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
}
Added the ability to extract a ModuleSpecList (a new class) from an ObjectFile. This is designed to be used when you have an object file that contains one or more architectures (MacOSX universal (fat) files) and/or one or more objects (BSD archive (.a files)). There is a new static ObjectFile function you can call: size_t ObjectFile::GetModuleSpecifications (const FileSpec &file, lldb::offset_t file_offset, ModuleSpecList &specs) This will fill in "specs" which the details of all the module specs (file + arch + UUID (if there is one) + object name (for BSD archive objects eventually) + file offset to the object in question). This helps us when a user specifies a file that contains a single architecture, and also helps us when we are given a debug symbol file (like a dSYM file on MacOSX) that contains one or more architectures and we need to be able to match it up to an existing Module that has no debug info. llvm-svn: 180224
2013-04-25 06:29:28 +08:00
return 0;
Don't put modules for .o files into the global shared module list. We used to do this because we needed to find the shared pointer for a .o file when the .o file's module was needed in a SymbolContext since the module in a symbol context was a shared pointer. Now that we are using intrusive pointers we don't have this limitation anymore since any instrusive shared pointer can be made from a pointer to an object all on its own. Also switched over to having the Module and SymbolVendor use shared pointers to their object files as had a leak on MacOSX when the SymbolVendor's object file wasn't the same as the Module's (debug info in a stand along file (dSYM file)). Now everything will correctly clean itself up when the module goes away after an executable gets rebuilt. Now we correctly get rid of .o files that are used with the DWARF with debug map executables on subsequent runs since the only shared pointer to the object files in from the DWARF symbol file debug map parser, and when the module gets replaced, it destroys to old one along with all .o files. Also added a small optimization when using BSD archives where we will remove old BSD containers from the shared list when they are outdated. llvm-svn: 140002
2011-09-19 02:59:15 +08:00
}
<rdar://problem/10103468> I started work on being able to add symbol files after a debug session had started with a new "target symfile add" command and quickly ran into problems with stale Address objects in breakpoint locations that had lldb_private::Section pointers into modules that had been removed or replaced. This also let to grabbing stale modules from those sections. So I needed to thread harded the Address, Section and related objects. To do this I modified the ModuleChild class to now require a ModuleSP on initialization so that a weak reference can created. I also changed all places that were handing out "Section *" to have them hand out SectionSP. All ObjectFile, SymbolFile and SymbolVendors were inheriting from ModuleChild so all of the find plug-in, static creation function and constructors now require ModuleSP references instead of Module *. Address objects now have weak references to their sections which can safely go stale when a module gets destructed. This checkin doesn't complete the "target symfile add" command, but it does get us a lot clioser to being able to do such things without a high risk of crashing or memory corruption. llvm-svn: 151336
2012-02-24 09:59:29 +08:00
size_t ObjectFile::GetModuleSpecifications(
const lldb_private::FileSpec &file, lldb::DataBufferSP &data_sp,
Start converting usages of off_t to other types. off_t is a type which is used for file offsets. Even more specifically, it is only used by a limited number of C APIs that deal with files. Any usage of off_t where the variable is not intended to be used with one of these APIs is a bug, by definition. This patch corrects some easy mis-uses of off_t, generally by converting them to lldb::offset_t, but sometimes by using other types such as size_t, when appropriate. The use of off_t to represent these offsets has worked fine in practice on linux-y platforms, since we used _FILE_OFFSET_64 to guarantee that off_t was a uint64. On Windows, however, _FILE_OFFSET_64 is unrecognized, and off_t will always be 32-bit. So the usage of off_t on Windows actually leads to legitimate bugs. Reviewed by: Greg Clayton Differential Revision: http://reviews.llvm.org/D4358 llvm-svn: 212192
2014-07-03 01:24:07 +08:00
lldb::offset_t data_offset, lldb::offset_t file_offset,
<rdar://problem/10103468> I started work on being able to add symbol files after a debug session had started with a new "target symfile add" command and quickly ran into problems with stale Address objects in breakpoint locations that had lldb_private::Section pointers into modules that had been removed or replaced. This also let to grabbing stale modules from those sections. So I needed to thread harded the Address, Section and related objects. To do this I modified the ModuleChild class to now require a ModuleSP on initialization so that a weak reference can created. I also changed all places that were handing out "Section *" to have them hand out SectionSP. All ObjectFile, SymbolFile and SymbolVendors were inheriting from ModuleChild so all of the find plug-in, static creation function and constructors now require ModuleSP references instead of Module *. Address objects now have weak references to their sections which can safely go stale when a module gets destructed. This checkin doesn't complete the "target symfile add" command, but it does get us a lot clioser to being able to do such things without a high risk of crashing or memory corruption. llvm-svn: 151336
2012-02-24 09:59:29 +08:00
lldb::offset_t file_size, lldb_private::ModuleSpecList &specs) {
<rdar://problem/10560053> Fixed "target modules list" (aliased to "image list") to output more information by default. Modified the "target modules list" to have a few new options: "--header" or "-h" => show the image header address "--offset" or "-o" => show the image header address offset from the address in the file (the slide applied to the shared library) Removed the "--symfile-basename" or "-S" option, and repurposed it to "--symfile-unique" "-S" which will show the symbol file if it differs from the executable file. ObjectFile's can now be loaded from memory for cases where we don't have the files cached locally in an SDK or net mounted root. ObjectFileMachO can now read mach files from memory. Moved the section data reading code into the ObjectFile so that the object file can get the section data from Process memory if the file is only in memory. lldb_private::Module can now load its object file in a target with a rigid slide (very common operation for most dynamic linkers) by using: bool Module::SetLoadAddress (Target &target, lldb::addr_t offset, bool &changed) lldb::SBModule() now has a new constructor in the public interface: SBModule::SBModule (lldb::SBProcess &process, lldb::addr_t header_addr); This will find an appropriate ObjectFile plug-in to load an image from memory where the object file header is at "header_addr". llvm-svn: 149804
2012-02-05 10:38:54 +08:00
const size_t initial_count = specs.GetSize();
<rdar://problem/10103468> I started work on being able to add symbol files after a debug session had started with a new "target symfile add" command and quickly ran into problems with stale Address objects in breakpoint locations that had lldb_private::Section pointers into modules that had been removed or replaced. This also let to grabbing stale modules from those sections. So I needed to thread harded the Address, Section and related objects. To do this I modified the ModuleChild class to now require a ModuleSP on initialization so that a weak reference can created. I also changed all places that were handing out "Section *" to have them hand out SectionSP. All ObjectFile, SymbolFile and SymbolVendors were inheriting from ModuleChild so all of the find plug-in, static creation function and constructors now require ModuleSP references instead of Module *. Address objects now have weak references to their sections which can safely go stale when a module gets destructed. This checkin doesn't complete the "target symfile add" command, but it does get us a lot clioser to being able to do such things without a high risk of crashing or memory corruption. llvm-svn: 151336
2012-02-24 09:59:29 +08:00
ObjectFileGetModuleSpecifications callback;
Added the ability to extract a ModuleSpecList (a new class) from an ObjectFile. This is designed to be used when you have an object file that contains one or more architectures (MacOSX universal (fat) files) and/or one or more objects (BSD archive (.a files)). There is a new static ObjectFile function you can call: size_t ObjectFile::GetModuleSpecifications (const FileSpec &file, lldb::offset_t file_offset, ModuleSpecList &specs) This will fill in "specs" which the details of all the module specs (file + arch + UUID (if there is one) + object name (for BSD archive objects eventually) + file offset to the object in question). This helps us when a user specifies a file that contains a single architecture, and also helps us when we are given a debug symbol file (like a dSYM file on MacOSX) that contains one or more architectures and we need to be able to match it up to an existing Module that has no debug info. llvm-svn: 180224
2013-04-25 06:29:28 +08:00
uint32_t i;
<rdar://problem/10560053> Fixed "target modules list" (aliased to "image list") to output more information by default. Modified the "target modules list" to have a few new options: "--header" or "-h" => show the image header address "--offset" or "-o" => show the image header address offset from the address in the file (the slide applied to the shared library) Removed the "--symfile-basename" or "-S" option, and repurposed it to "--symfile-unique" "-S" which will show the symbol file if it differs from the executable file. ObjectFile's can now be loaded from memory for cases where we don't have the files cached locally in an SDK or net mounted root. ObjectFileMachO can now read mach files from memory. Moved the section data reading code into the ObjectFile so that the object file can get the section data from Process memory if the file is only in memory. lldb_private::Module can now load its object file in a target with a rigid slide (very common operation for most dynamic linkers) by using: bool Module::SetLoadAddress (Target &target, lldb::addr_t offset, bool &changed) lldb::SBModule() now has a new constructor in the public interface: SBModule::SBModule (lldb::SBProcess &process, lldb::addr_t header_addr); This will find an appropriate ObjectFile plug-in to load an image from memory where the object file header is at "header_addr". llvm-svn: 149804
2012-02-05 10:38:54 +08:00
// Try the ObjectFile plug-ins
<rdar://problem/13338643> DWARF with .o files now uses 40-60% less memory! Big fixes include: - Change line table internal representation to contain "file addresses". Since each line table is owned by a compile unit that is owned by a module, it makes address translation into lldb_private::Address easy to do when needed. - Removed linked address members/methods from lldb_private::Section and lldb_private::Address - lldb_private::LineTable can now relink itself using a FileRangeMap to make it easier to re-link line tables in the future - Added ObjectFile::ClearSymtab() so that we can get rid of the object file symbol tables after we parse them once since they are not needed and kept memory allocated for no reason - Moved the m_sections_ap (std::auto_ptr to section list) and m_symtab_ap (std::auto_ptr to the lldb_private::Symtab) out of each of the ObjectFile subclasses and put it into lldb_private::ObjectFile. - Changed how the debug map is parsed and stored to be able to: - Lazily parse the debug map for each object file - not require the address map for a .o file until debug information is linked for a .o file llvm-svn: 176454
2013-03-05 05:46:16 +08:00
for (i = 0;
Switch NULL to C++11 nullptr in source/Symbol and source/Utility Patch by Robert Matusewicz llvm-svn: 206713
2014-04-20 21:17:36 +08:00
(callback =
Cleanup on the unified section list changes. Main changes are: - ObjectFile::GetSymtab() and ObjectFile::ClearSymtab() no longer takes any flags - Module coordinates with the object files and contain a unified section list so that object file and symbol file can share sections when they need to, yet contain their own sections. Other cleanups: - Fixed Symbol::GetByteSize() to not have the symbol table compute the byte sizes on the fly - Modified the ObjectFileMachO class to compute symbol sizes all at once efficiently - Modified the Symtab class to store a file address lookup table for more efficient lookups - Removed Section::Finalize() and SectionList::Finalize() as they did nothing - Improved performance of the detection of symbol files that have debug maps by excluding stripped files and core files, debug files, object files and stubs - Added the ability to tell if an ObjectFile has been stripped with ObjectFile::IsStripped() (used this for the above performance improvement) llvm-svn: 185990
2013-07-10 09:23:25 +08:00
PluginManager::GetObjectFileGetModuleSpecificationsCallbackAtIndex(
Improve the handling of missing elf symtab and missing symbol sizes * Generate artificial symbol names from eh_fame during symbol parsing so these symbols are already present when we calcualte the size of the symbols where 0 is specified. * Fix symbol size calculation for the last symbol in the file where it have to last until the end of the parent section. This is the re-commit of the original change after fixing some test failures on OSX. Differential revision: http://reviews.llvm.org/D16996 llvm-svn: 261205
2016-02-18 19:12:18 +08:00
i)) != nullptr;
<rdar://problem/13338643> DWARF with .o files now uses 40-60% less memory! Big fixes include: - Change line table internal representation to contain "file addresses". Since each line table is owned by a compile unit that is owned by a module, it makes address translation into lldb_private::Address easy to do when needed. - Removed linked address members/methods from lldb_private::Section and lldb_private::Address - lldb_private::LineTable can now relink itself using a FileRangeMap to make it easier to re-link line tables in the future - Added ObjectFile::ClearSymtab() so that we can get rid of the object file symbol tables after we parse them once since they are not needed and kept memory allocated for no reason - Moved the m_sections_ap (std::auto_ptr to section list) and m_symtab_ap (std::auto_ptr to the lldb_private::Symtab) out of each of the ObjectFile subclasses and put it into lldb_private::ObjectFile. - Changed how the debug map is parsed and stored to be able to: - Lazily parse the debug map for each object file - not require the address map for a .o file until debug information is linked for a .o file llvm-svn: 176454
2013-03-05 05:46:16 +08:00
++i) {
<rdar://problem/10560053> Fixed "target modules list" (aliased to "image list") to output more information by default. Modified the "target modules list" to have a few new options: "--header" or "-h" => show the image header address "--offset" or "-o" => show the image header address offset from the address in the file (the slide applied to the shared library) Removed the "--symfile-basename" or "-S" option, and repurposed it to "--symfile-unique" "-S" which will show the symbol file if it differs from the executable file. ObjectFile's can now be loaded from memory for cases where we don't have the files cached locally in an SDK or net mounted root. ObjectFileMachO can now read mach files from memory. Moved the section data reading code into the ObjectFile so that the object file can get the section data from Process memory if the file is only in memory. lldb_private::Module can now load its object file in a target with a rigid slide (very common operation for most dynamic linkers) by using: bool Module::SetLoadAddress (Target &target, lldb::addr_t offset, bool &changed) lldb::SBModule() now has a new constructor in the public interface: SBModule::SBModule (lldb::SBProcess &process, lldb::addr_t header_addr); This will find an appropriate ObjectFile plug-in to load an image from memory where the object file header is at "header_addr". llvm-svn: 149804
2012-02-05 10:38:54 +08:00
if (callback(file, data_sp, data_offset, file_offset, file_size, specs) > 0)
<rdar://problem/13521159> LLDB is crashing when logging is enabled from lldb-perf-clang. This has to do with the global destructor chain as the process and its threads are being torn down. All logging channels now make one and only one instance that is kept in a global pointer which is never freed. This guarantees that logging can correctly continue as the process tears itself down. llvm-svn: 178191
2013-03-28 07:08:40 +08:00
return specs.GetSize() - initial_count;
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
}
Cleanup logging to use the new "std::string FileSpec::GetPath()" function. Also added a similar function for modules: std::string Module::GetSpecificationDescription () const; This returns the module as "/usr/lib/libfoo.dylib" for normal files (calls "std::string FileSpec::GetPath()" on m_file) but it also might include the object name in case the module is for a .o file in a BSD archive ("/usr/lib/libfoo.a(bar.o)"). Cleaned up necessary logging code to use it. llvm-svn: 180717
2013-04-30 01:25:54 +08:00
// Try the ObjectContainer plug-ins
for (i = 0;
(callback = PluginManager::
GetObjectContainerGetModuleSpecificationsCallbackAtIndex(i)) !=
nullptr;
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
++i) {
Cleanup logging to use the new "std::string FileSpec::GetPath()" function. Also added a similar function for modules: std::string Module::GetSpecificationDescription () const; This returns the module as "/usr/lib/libfoo.dylib" for normal files (calls "std::string FileSpec::GetPath()" on m_file) but it also might include the object name in case the module is for a .o file in a BSD archive ("/usr/lib/libfoo.a(bar.o)"). Cleaned up necessary logging code to use it. llvm-svn: 180717
2013-04-30 01:25:54 +08:00
if (callback(file, data_sp, data_offset, file_offset, file_size, specs) > 0)
sweep up -Wformat warnings from gcc This is a purely mechanical change explicitly casting any parameters for printf style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux. llvm-svn: 205607
2014-04-04 12:06:10 +08:00
return specs.GetSize() - initial_count;
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
}
Added the ability to extract a ModuleSpecList (a new class) from an ObjectFile. This is designed to be used when you have an object file that contains one or more architectures (MacOSX universal (fat) files) and/or one or more objects (BSD archive (.a files)). There is a new static ObjectFile function you can call: size_t ObjectFile::GetModuleSpecifications (const FileSpec &file, lldb::offset_t file_offset, ModuleSpecList &specs) This will fill in "specs" which the details of all the module specs (file + arch + UUID (if there is one) + object name (for BSD archive objects eventually) + file offset to the object in question). This helps us when a user specifies a file that contains a single architecture, and also helps us when we are given a debug symbol file (like a dSYM file on MacOSX) that contains one or more architectures and we need to be able to match it up to an existing Module that has no debug info. llvm-svn: 180224
2013-04-25 06:29:28 +08:00
return 0;
<rdar://problem/10560053> Fixed "target modules list" (aliased to "image list") to output more information by default. Modified the "target modules list" to have a few new options: "--header" or "-h" => show the image header address "--offset" or "-o" => show the image header address offset from the address in the file (the slide applied to the shared library) Removed the "--symfile-basename" or "-S" option, and repurposed it to "--symfile-unique" "-S" which will show the symbol file if it differs from the executable file. ObjectFile's can now be loaded from memory for cases where we don't have the files cached locally in an SDK or net mounted root. ObjectFileMachO can now read mach files from memory. Moved the section data reading code into the ObjectFile so that the object file can get the section data from Process memory if the file is only in memory. lldb_private::Module can now load its object file in a target with a rigid slide (very common operation for most dynamic linkers) by using: bool Module::SetLoadAddress (Target &target, lldb::addr_t offset, bool &changed) lldb::SBModule() now has a new constructor in the public interface: SBModule::SBModule (lldb::SBProcess &process, lldb::addr_t header_addr); This will find an appropriate ObjectFile plug-in to load an image from memory where the object file header is at "header_addr". llvm-svn: 149804
2012-02-05 10:38:54 +08:00
}
<rdar://problem/10103468> I started work on being able to add symbol files after a debug session had started with a new "target symfile add" command and quickly ran into problems with stale Address objects in breakpoint locations that had lldb_private::Section pointers into modules that had been removed or replaced. This also let to grabbing stale modules from those sections. So I needed to thread harded the Address, Section and related objects. To do this I modified the ModuleChild class to now require a ModuleSP on initialization so that a weak reference can created. I also changed all places that were handing out "Section *" to have them hand out SectionSP. All ObjectFile, SymbolFile and SymbolVendors were inheriting from ModuleChild so all of the find plug-in, static creation function and constructors now require ModuleSP references instead of Module *. Address objects now have weak references to their sections which can safely go stale when a module gets destructed. This checkin doesn't complete the "target symfile add" command, but it does get us a lot clioser to being able to do such things without a high risk of crashing or memory corruption. llvm-svn: 151336
2012-02-24 09:59:29 +08:00
ObjectFile::ObjectFile(const lldb::ModuleSP &module_sp,
Added the ability to extract a ModuleSpecList (a new class) from an ObjectFile. This is designed to be used when you have an object file that contains one or more architectures (MacOSX universal (fat) files) and/or one or more objects (BSD archive (.a files)). There is a new static ObjectFile function you can call: size_t ObjectFile::GetModuleSpecifications (const FileSpec &file, lldb::offset_t file_offset, ModuleSpecList &specs) This will fill in "specs" which the details of all the module specs (file + arch + UUID (if there is one) + object name (for BSD archive objects eventually) + file offset to the object in question). This helps us when a user specifies a file that contains a single architecture, and also helps us when we are given a debug symbol file (like a dSYM file on MacOSX) that contains one or more architectures and we need to be able to match it up to an existing Module that has no debug info. llvm-svn: 180224
2013-04-25 06:29:28 +08:00
const FileSpec *file_spec_ptr,
Start converting usages of off_t to other types. off_t is a type which is used for file offsets. Even more specifically, it is only used by a limited number of C APIs that deal with files. Any usage of off_t where the variable is not intended to be used with one of these APIs is a bug, by definition. This patch corrects some easy mis-uses of off_t, generally by converting them to lldb::offset_t, but sometimes by using other types such as size_t, when appropriate. The use of off_t to represent these offsets has worked fine in practice on linux-y platforms, since we used _FILE_OFFSET_64 to guarantee that off_t was a uint64. On Windows, however, _FILE_OFFSET_64 is unrecognized, and off_t will always be 32-bit. So the usage of off_t on Windows actually leads to legitimate bugs. Reviewed by: Greg Clayton Differential Revision: http://reviews.llvm.org/D4358 llvm-svn: 212192
2014-07-03 01:24:07 +08:00
lldb::offset_t file_offset, lldb::offset_t length,
const lldb::DataBufferSP &data_sp,
Added the ability to extract a ModuleSpecList (a new class) from an ObjectFile. This is designed to be used when you have an object file that contains one or more architectures (MacOSX universal (fat) files) and/or one or more objects (BSD archive (.a files)). There is a new static ObjectFile function you can call: size_t ObjectFile::GetModuleSpecifications (const FileSpec &file, lldb::offset_t file_offset, ModuleSpecList &specs) This will fill in "specs" which the details of all the module specs (file + arch + UUID (if there is one) + object name (for BSD archive objects eventually) + file offset to the object in question). This helps us when a user specifies a file that contains a single architecture, and also helps us when we are given a debug symbol file (like a dSYM file on MacOSX) that contains one or more architectures and we need to be able to match it up to an existing Module that has no debug info. llvm-svn: 180224
2013-04-25 06:29:28 +08:00
lldb::offset_t data_offset)
<rdar://problem/10103468> I started work on being able to add symbol files after a debug session had started with a new "target symfile add" command and quickly ran into problems with stale Address objects in breakpoint locations that had lldb_private::Section pointers into modules that had been removed or replaced. This also let to grabbing stale modules from those sections. So I needed to thread harded the Address, Section and related objects. To do this I modified the ModuleChild class to now require a ModuleSP on initialization so that a weak reference can created. I also changed all places that were handing out "Section *" to have them hand out SectionSP. All ObjectFile, SymbolFile and SymbolVendors were inheriting from ModuleChild so all of the find plug-in, static creation function and constructors now require ModuleSP references instead of Module *. Address objects now have weak references to their sections which can safely go stale when a module gets destructed. This checkin doesn't complete the "target symfile add" command, but it does get us a lot clioser to being able to do such things without a high risk of crashing or memory corruption. llvm-svn: 151336
2012-02-24 09:59:29 +08:00
: ModuleChild(module_sp),
Don't put modules for .o files into the global shared module list. We used to do this because we needed to find the shared pointer for a .o file when the .o file's module was needed in a SymbolContext since the module in a symbol context was a shared pointer. Now that we are using intrusive pointers we don't have this limitation anymore since any instrusive shared pointer can be made from a pointer to an object all on its own. Also switched over to having the Module and SymbolVendor use shared pointers to their object files as had a leak on MacOSX when the SymbolVendor's object file wasn't the same as the Module's (debug info in a stand along file (dSYM file)). Now everything will correctly clean itself up when the module goes away after an executable gets rebuilt. Now we correctly get rid of .o files that are used with the DWARF with debug map executables on subsequent runs since the only shared pointer to the object files in from the DWARF symbol file debug map parser, and when the module gets replaced, it destroys to old one along with all .o files. Also added a small optimization when using BSD archives where we will remove old BSD containers from the shared list when they are outdated. llvm-svn: 140002
2011-09-19 02:59:15 +08:00
m_file(), // This file could be different from the original module's file
m_type(eTypeInvalid), m_strata(eStrataInvalid),
Move UnwindTable from ObjectFile to Module Summary: This is a preparatory step to enable adding extra unwind strategies by symbol file plugins. This has been discussed on the lldb-dev mailing list: <http://lists.llvm.org/pipermail/lldb-dev/2019-February/014703.html>. Reviewers: jasonmolenda, clayborg, espindola Subscribers: lemo, emaste, lldb-commits, arichardson Differential Revision: https://reviews.llvm.org/D58129 llvm-svn: 354033
2019-02-14 22:40:10 +08:00
m_file_offset(file_offset), m_length(length), m_data(), m_process_wp(),
Replace 'ap' with 'up' suffix in variable names. (NFC) The `ap` suffix is a remnant of lldb's former use of auto pointers, before they got deprecated. Although all their uses were replaced by unique pointers, some variables still carried the suffix. In r353795 I removed another auto_ptr remnant, namely redundant calls to ::get for unique_pointers. Jim justly noted that this is a good opportunity to clean up the variable names as well. I went over all the changes to ensure my find-and-replace didn't have any undesired side-effects. I hope I didn't miss any, but if you end up at this commit doing a git blame on a weirdly named variable, please know that the change was unintentional. llvm-svn: 353912
2019-02-13 14:25:41 +08:00
m_memory_addr(LLDB_INVALID_ADDRESS), m_sections_up(), m_symtab_up(),
Improve the handling of missing elf symtab and missing symbol sizes * Generate artificial symbol names from eh_fame during symbol parsing so these symbols are already present when we calcualte the size of the symbols where 0 is specified. * Fix symbol size calculation for the last symbol in the file where it have to last until the end of the parent section. This is the re-commit of the original change after fixing some test failures on OSX. Differential revision: http://reviews.llvm.org/D16996 llvm-svn: 261205
2016-02-18 19:12:18 +08:00
m_synthetic_symbol_idx(0) {
Don't put modules for .o files into the global shared module list. We used to do this because we needed to find the shared pointer for a .o file when the .o file's module was needed in a SymbolContext since the module in a symbol context was a shared pointer. Now that we are using intrusive pointers we don't have this limitation anymore since any instrusive shared pointer can be made from a pointer to an object all on its own. Also switched over to having the Module and SymbolVendor use shared pointers to their object files as had a leak on MacOSX when the SymbolVendor's object file wasn't the same as the Module's (debug info in a stand along file (dSYM file)). Now everything will correctly clean itself up when the module goes away after an executable gets rebuilt. Now we correctly get rid of .o files that are used with the DWARF with debug map executables on subsequent runs since the only shared pointer to the object files in from the DWARF symbol file debug map parser, and when the module gets replaced, it destroys to old one along with all .o files. Also added a small optimization when using BSD archives where we will remove old BSD containers from the shared list when they are outdated. llvm-svn: 140002
2011-09-19 02:59:15 +08:00
if (file_spec_ptr)
m_file = *file_spec_ptr;
<rdar://problem/13159777> lldb was mmap'ing archive files once per .o file it loads, now it correctly shares the archive between modules. LLDB was also always mapping entire contents of universal mach-o files, now it maps just the slice that is required. Added a new logging channel for "lldb" called "mmap" to help track future regressions. Modified the ObjectFile and ObjectContainer plugin interfaces to take a data offset along with the file offset and size so we can implement the correct caching and efficient reading of parts of files without mmap'ing the entire file like we used to. The current implementation still keeps entire .a files mmaped (once) and entire slices from universal files mmaped to ensure that if a client builds their binaries during a debug session we don't lose our data and get corrupt object file info and debug info. llvm-svn: 174524
2013-02-07 01:22:03 +08:00
if (data_sp)
m_data.SetData(data_sp, data_offset, length);
<rdar://problem/13521159> LLDB is crashing when logging is enabled from lldb-perf-clang. This has to do with the global destructor chain as the process and its threads are being torn down. All logging channels now make one and only one instance that is kept in a global pointer which is never freed. This guarantees that logging can correctly continue as the process tears itself down. llvm-svn: 178191
2013-03-28 07:08:40 +08:00
Log *log(lldb_private::GetLogIfAllCategoriesSet(LIBLLDB_LOG_OBJECT));
[Logging] Replace Log::Printf with LLDB_LOG macro (NFC) This patch replaces explicit calls to log::Printf with the new LLDB_LOGF macro. The macro is similar to LLDB_LOG but supports printf-style format strings, instead of formatv-style format strings. So instead of writing: if (log) log->Printf("%s\n", str); You'd write: LLDB_LOG(log, "%s\n", str); This change was done mechanically with the command below. I replaced the spurious if-checks with vim, since I know how to do multi-line replacements with it. find . -type f -name '*.cpp' -exec \ sed -i '' -E 's/log->Printf\(/LLDB_LOGF\(log, /g' "{}" + Differential revision: https://reviews.llvm.org/D65128 llvm-svn: 366936
2019-07-25 01:56:10 +08: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);
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
}
<rdar://problem/10560053> Fixed "target modules list" (aliased to "image list") to output more information by default. Modified the "target modules list" to have a few new options: "--header" or "-h" => show the image header address "--offset" or "-o" => show the image header address offset from the address in the file (the slide applied to the shared library) Removed the "--symfile-basename" or "-S" option, and repurposed it to "--symfile-unique" "-S" which will show the symbol file if it differs from the executable file. ObjectFile's can now be loaded from memory for cases where we don't have the files cached locally in an SDK or net mounted root. ObjectFileMachO can now read mach files from memory. Moved the section data reading code into the ObjectFile so that the object file can get the section data from Process memory if the file is only in memory. lldb_private::Module can now load its object file in a target with a rigid slide (very common operation for most dynamic linkers) by using: bool Module::SetLoadAddress (Target &target, lldb::addr_t offset, bool &changed) lldb::SBModule() now has a new constructor in the public interface: SBModule::SBModule (lldb::SBProcess &process, lldb::addr_t header_addr); This will find an appropriate ObjectFile plug-in to load an image from memory where the object file header is at "header_addr". llvm-svn: 149804
2012-02-05 10:38:54 +08:00
Don't put modules for .o files into the global shared module list. We used to do this because we needed to find the shared pointer for a .o file when the .o file's module was needed in a SymbolContext since the module in a symbol context was a shared pointer. Now that we are using intrusive pointers we don't have this limitation anymore since any instrusive shared pointer can be made from a pointer to an object all on its own. Also switched over to having the Module and SymbolVendor use shared pointers to their object files as had a leak on MacOSX when the SymbolVendor's object file wasn't the same as the Module's (debug info in a stand along file (dSYM file)). Now everything will correctly clean itself up when the module goes away after an executable gets rebuilt. Now we correctly get rid of .o files that are used with the DWARF with debug map executables on subsequent runs since the only shared pointer to the object files in from the DWARF symbol file debug map parser, and when the module gets replaced, it destroys to old one along with all .o files. Also added a small optimization when using BSD archives where we will remove old BSD containers from the shared list when they are outdated. llvm-svn: 140002
2011-09-19 02:59:15 +08:00
ObjectFile::ObjectFile(const lldb::ModuleSP &module_sp,
<rdar://problem/10560053> Fixed "target modules list" (aliased to "image list") to output more information by default. Modified the "target modules list" to have a few new options: "--header" or "-h" => show the image header address "--offset" or "-o" => show the image header address offset from the address in the file (the slide applied to the shared library) Removed the "--symfile-basename" or "-S" option, and repurposed it to "--symfile-unique" "-S" which will show the symbol file if it differs from the executable file. ObjectFile's can now be loaded from memory for cases where we don't have the files cached locally in an SDK or net mounted root. ObjectFileMachO can now read mach files from memory. Moved the section data reading code into the ObjectFile so that the object file can get the section data from Process memory if the file is only in memory. lldb_private::Module can now load its object file in a target with a rigid slide (very common operation for most dynamic linkers) by using: bool Module::SetLoadAddress (Target &target, lldb::addr_t offset, bool &changed) lldb::SBModule() now has a new constructor in the public interface: SBModule::SBModule (lldb::SBProcess &process, lldb::addr_t header_addr); This will find an appropriate ObjectFile plug-in to load an image from memory where the object file header is at "header_addr". llvm-svn: 149804
2012-02-05 10:38:54 +08:00
const ProcessSP &process_sp, lldb::addr_t header_addr,
Don't put modules for .o files into the global shared module list. We used to do this because we needed to find the shared pointer for a .o file when the .o file's module was needed in a SymbolContext since the module in a symbol context was a shared pointer. Now that we are using intrusive pointers we don't have this limitation anymore since any instrusive shared pointer can be made from a pointer to an object all on its own. Also switched over to having the Module and SymbolVendor use shared pointers to their object files as had a leak on MacOSX when the SymbolVendor's object file wasn't the same as the Module's (debug info in a stand along file (dSYM file)). Now everything will correctly clean itself up when the module goes away after an executable gets rebuilt. Now we correctly get rid of .o files that are used with the DWARF with debug map executables on subsequent runs since the only shared pointer to the object files in from the DWARF symbol file debug map parser, and when the module gets replaced, it destroys to old one along with all .o files. Also added a small optimization when using BSD archives where we will remove old BSD containers from the shared list when they are outdated. llvm-svn: 140002
2011-09-19 02:59:15 +08:00
DataBufferSP &header_data_sp)
: ModuleChild(module_sp), m_file(), m_type(eTypeInvalid),
Start converting usages of off_t to other types. off_t is a type which is used for file offsets. Even more specifically, it is only used by a limited number of C APIs that deal with files. Any usage of off_t where the variable is not intended to be used with one of these APIs is a bug, by definition. This patch corrects some easy mis-uses of off_t, generally by converting them to lldb::offset_t, but sometimes by using other types such as size_t, when appropriate. The use of off_t to represent these offsets has worked fine in practice on linux-y platforms, since we used _FILE_OFFSET_64 to guarantee that off_t was a uint64. On Windows, however, _FILE_OFFSET_64 is unrecognized, and off_t will always be 32-bit. So the usage of off_t on Windows actually leads to legitimate bugs. Reviewed by: Greg Clayton Differential Revision: http://reviews.llvm.org/D4358 llvm-svn: 212192
2014-07-03 01:24:07 +08:00
m_strata(eStrataInvalid), m_file_offset(0), m_length(0), m_data(),
Move UnwindTable from ObjectFile to Module Summary: This is a preparatory step to enable adding extra unwind strategies by symbol file plugins. This has been discussed on the lldb-dev mailing list: <http://lists.llvm.org/pipermail/lldb-dev/2019-February/014703.html>. Reviewers: jasonmolenda, clayborg, espindola Subscribers: lemo, emaste, lldb-commits, arichardson Differential Revision: https://reviews.llvm.org/D58129 llvm-svn: 354033
2019-02-14 22:40:10 +08:00
m_process_wp(process_sp), m_memory_addr(header_addr), m_sections_up(),
m_symtab_up(), m_synthetic_symbol_idx(0) {
<rdar://problem/13521159> LLDB is crashing when logging is enabled from lldb-perf-clang. This has to do with the global destructor chain as the process and its threads are being torn down. All logging channels now make one and only one instance that is kept in a global pointer which is never freed. This guarantees that logging can correctly continue as the process tears itself down. llvm-svn: 178191
2013-03-28 07:08:40 +08:00
if (header_data_sp)
<rdar://problem/13092722> Fix in loading mach files from memory when using DynamicLoaderMacOSXDYLD. Removed the uuid mismatch warning that could be spit out and any time during debugging and removed the test case that was looking for that. Currently the "add-dsym" or "target symbols add" command will report an error when the UUID's don't match. Be more careful when checking and resolving section + offset addresses to make sure none of the base addresses are invalid. llvm-svn: 174222
2013-02-02 05:38:35 +08:00
m_data.SetData(header_data_sp, 0, header_data_sp->GetByteSize());
<rdar://problem/13521159> LLDB is crashing when logging is enabled from lldb-perf-clang. This has to do with the global destructor chain as the process and its threads are being torn down. All logging channels now make one and only one instance that is kept in a global pointer which is never freed. This guarantees that logging can correctly continue as the process tears itself down. llvm-svn: 178191
2013-03-28 07:08:40 +08:00
Log *log(lldb_private::GetLogIfAllCategoriesSet(LIBLLDB_LOG_OBJECT));
[Logging] Replace Log::Printf with LLDB_LOG macro (NFC) This patch replaces explicit calls to log::Printf with the new LLDB_LOGF macro. The macro is similar to LLDB_LOG but supports printf-style format strings, instead of formatv-style format strings. So instead of writing: if (log) log->Printf("%s\n", str); You'd write: LLDB_LOG(log, "%s\n", str); This change was done mechanically with the command below. I replaced the spurious if-checks with vim, since I know how to do multi-line replacements with it. find . -type f -name '*.cpp' -exec \ sed -i '' -E 's/log->Printf\(/LLDB_LOGF\(log, /g' "{}" + Differential revision: https://reviews.llvm.org/D65128 llvm-svn: 366936
2019-07-25 01:56:10 +08: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);
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
Change Target & Process so they can really be initialized with an invalid architecture. Arrange that this then gets properly set on attach, or when a "file" is set. Add a completer for "process attach -n". Caveats: there isn't currently a way to handle multiple processes with the same name. That will have to wait on a way to pass annotations along with the completion strings. llvm-svn: 110624
2010-08-10 07:31:02 +08:00
ObjectFile::~ObjectFile() {
<rdar://problem/10103468> I started work on being able to add symbol files after a debug session had started with a new "target symfile add" command and quickly ran into problems with stale Address objects in breakpoint locations that had lldb_private::Section pointers into modules that had been removed or replaced. This also let to grabbing stale modules from those sections. So I needed to thread harded the Address, Section and related objects. To do this I modified the ModuleChild class to now require a ModuleSP on initialization so that a weak reference can created. I also changed all places that were handing out "Section *" to have them hand out SectionSP. All ObjectFile, SymbolFile and SymbolVendors were inheriting from ModuleChild so all of the find plug-in, static creation function and constructors now require ModuleSP references instead of Module *. Address objects now have weak references to their sections which can safely go stale when a module gets destructed. This checkin doesn't complete the "target symfile add" command, but it does get us a lot clioser to being able to do such things without a high risk of crashing or memory corruption. llvm-svn: 151336
2012-02-24 09:59:29 +08:00
Log *log(lldb_private::GetLogIfAllCategoriesSet(LIBLLDB_LOG_OBJECT));
[Logging] Replace Log::Printf with LLDB_LOG macro (NFC) This patch replaces explicit calls to log::Printf with the new LLDB_LOGF macro. The macro is similar to LLDB_LOG but supports printf-style format strings, instead of formatv-style format strings. So instead of writing: if (log) log->Printf("%s\n", str); You'd write: LLDB_LOG(log, "%s\n", str); This change was done mechanically with the command below. I replaced the spurious if-checks with vim, since I know how to do multi-line replacements with it. find . -type f -name '*.cpp' -exec \ sed -i '' -E 's/log->Printf\(/LLDB_LOGF\(log, /g' "{}" + Differential revision: https://reviews.llvm.org/D65128 llvm-svn: 366936
2019-07-25 01:56:10 +08:00
LLDB_LOGF(log, "%p ObjectFile::~ObjectFile ()\n", static_cast<void *>(this));
Change Target & Process so they can really be initialized with an invalid architecture. Arrange that this then gets properly set on attach, or when a "file" is set. Add a completer for "process attach -n". Caveats: there isn't currently a way to handle multiple processes with the same name. That will have to wait on a way to pass annotations along with the completion strings. llvm-svn: 110624
2010-08-10 07:31:02 +08:00
}
Don't put modules for .o files into the global shared module list. We used to do this because we needed to find the shared pointer for a .o file when the .o file's module was needed in a SymbolContext since the module in a symbol context was a shared pointer. Now that we are using intrusive pointers we don't have this limitation anymore since any instrusive shared pointer can be made from a pointer to an object all on its own. Also switched over to having the Module and SymbolVendor use shared pointers to their object files as had a leak on MacOSX when the SymbolVendor's object file wasn't the same as the Module's (debug info in a stand along file (dSYM file)). Now everything will correctly clean itself up when the module goes away after an executable gets rebuilt. Now we correctly get rid of .o files that are used with the DWARF with debug map executables on subsequent runs since the only shared pointer to the object files in from the DWARF symbol file debug map parser, and when the module gets replaced, it destroys to old one along with all .o files. Also added a small optimization when using BSD archives where we will remove old BSD containers from the shared list when they are outdated. llvm-svn: 140002
2011-09-19 02:59:15 +08:00
bool ObjectFile::SetModulesArchitecture(const ArchSpec &new_arch) {
Resubmitting 240466 after fixing the linux test suite failures. A few extras were fixed - Symbol::GetAddress() now returns an Address object, not a reference. There were places where people were accessing the address of a symbol when the symbol's value wasn't an address symbol. On MacOSX, undefined symbols have a value zero and some places where using the symbol's address and getting an absolute address of zero (since an Address object with no section and an m_offset whose value isn't LLDB_INVALID_ADDRESS is considered an absolute address). So fixing this required some changes to make sure people were getting what they expected. - Since some places want to access the address as a reference, I added a few new functions to symbol: Address &Symbol::GetAddressRef(); const Address &Symbol::GetAddressRef() const; Linux test suite passes just fine now. <rdar://problem/21494354> llvm-svn: 240702
2015-06-26 05:46:34 +08:00
ModuleSP module_sp(GetModule());
<rdar://problem/10103468> I started work on being able to add symbol files after a debug session had started with a new "target symfile add" command and quickly ran into problems with stale Address objects in breakpoint locations that had lldb_private::Section pointers into modules that had been removed or replaced. This also let to grabbing stale modules from those sections. So I needed to thread harded the Address, Section and related objects. To do this I modified the ModuleChild class to now require a ModuleSP on initialization so that a weak reference can created. I also changed all places that were handing out "Section *" to have them hand out SectionSP. All ObjectFile, SymbolFile and SymbolVendors were inheriting from ModuleChild so all of the find plug-in, static creation function and constructors now require ModuleSP references instead of Module *. Address objects now have weak references to their sections which can safely go stale when a module gets destructed. This checkin doesn't complete the "target symfile add" command, but it does get us a lot clioser to being able to do such things without a high risk of crashing or memory corruption. llvm-svn: 151336
2012-02-24 09:59:29 +08: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-28 01:55:14 +08:00
return module_sp->SetArchitecture(new_arch);
sweep up -Wformat warnings from gcc This is a purely mechanical change explicitly casting any parameters for printf style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux. llvm-svn: 205607
2014-04-04 12:06:10 +08:00
return false;
Added more platform support. There are now some new commands: platform status -- gets status information for the selected platform platform create <platform-name> -- creates a new instance of a remote platform platform list -- list all available platforms platform select -- select a platform instance as the current platform (not working yet) When using "platform create" it will create a remote platform and make it the selected platform. For instances for iPhone OS debugging on Mac OS X one can do: (lldb) platform create remote-ios --sdk-version=4.0 Remote platform: iOS platform SDK version: 4.0 SDK path: "/Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0" Not connected to a remote device. (lldb) file ~/Documents/a.out Current executable set to '~/Documents/a.out' (armv6). (lldb) image list [ 0] /Volumes/work/gclayton/Documents/devb/attach/a.out [ 1] /Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0/Symbols/usr/lib/dyld [ 2] /Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0/Symbols/usr/lib/libSystem.B.dylib Note that this is all happening prior to running _or_ connecting to a remote platform. Once connected to a remote platform the OS version might change which means we will need to update our dependecies. Also once we run, we will need to match up the actualy binaries with the actualy UUID's to files in the SDK, or download and cache them locally. This is just the start of the remote platforms, but this modification is the first iteration in getting the platforms really doing something. llvm-svn: 127934
2011-03-19 09:12:21 +08:00
}
sweep up -Wformat warnings from gcc This is a purely mechanical change explicitly casting any parameters for printf style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux. llvm-svn: 205607
2014-04-04 12:06:10 +08:00
<rdar://problem/10560053> Fixed "target modules list" (aliased to "image list") to output more information by default. Modified the "target modules list" to have a few new options: "--header" or "-h" => show the image header address "--offset" or "-o" => show the image header address offset from the address in the file (the slide applied to the shared library) Removed the "--symfile-basename" or "-S" option, and repurposed it to "--symfile-unique" "-S" which will show the symbol file if it differs from the executable file. ObjectFile's can now be loaded from memory for cases where we don't have the files cached locally in an SDK or net mounted root. ObjectFileMachO can now read mach files from memory. Moved the section data reading code into the ObjectFile so that the object file can get the section data from Process memory if the file is only in memory. lldb_private::Module can now load its object file in a target with a rigid slide (very common operation for most dynamic linkers) by using: bool Module::SetLoadAddress (Target &target, lldb::addr_t offset, bool &changed) lldb::SBModule() now has a new constructor in the public interface: SBModule::SBModule (lldb::SBProcess &process, lldb::addr_t header_addr); This will find an appropriate ObjectFile plug-in to load an image from memory where the object file header is at "header_addr". llvm-svn: 149804
2012-02-05 10:38:54 +08:00
AddressClass ObjectFile::GetAddressClass(addr_t file_addr) {
Cleanup on the unified section list changes. Main changes are: - ObjectFile::GetSymtab() and ObjectFile::ClearSymtab() no longer takes any flags - Module coordinates with the object files and contain a unified section list so that object file and symbol file can share sections when they need to, yet contain their own sections. Other cleanups: - Fixed Symbol::GetByteSize() to not have the symbol table compute the byte sizes on the fly - Modified the ObjectFileMachO class to compute symbol sizes all at once efficiently - Modified the Symtab class to store a file address lookup table for more efficient lookups - Removed Section::Finalize() and SectionList::Finalize() as they did nothing - Improved performance of the detection of symbol files that have debug maps by excluding stripped files and core files, debug files, object files and stubs - Added the ability to tell if an ObjectFile has been stripped with ObjectFile::IsStripped() (used this for the above performance improvement) llvm-svn: 185990
2013-07-10 09:23:25 +08:00
Symtab *symtab = GetSymtab();
Added more platform support. There are now some new commands: platform status -- gets status information for the selected platform platform create <platform-name> -- creates a new instance of a remote platform platform list -- list all available platforms platform select -- select a platform instance as the current platform (not working yet) When using "platform create" it will create a remote platform and make it the selected platform. For instances for iPhone OS debugging on Mac OS X one can do: (lldb) platform create remote-ios --sdk-version=4.0 Remote platform: iOS platform SDK version: 4.0 SDK path: "/Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0" Not connected to a remote device. (lldb) file ~/Documents/a.out Current executable set to '~/Documents/a.out' (armv6). (lldb) image list [ 0] /Volumes/work/gclayton/Documents/devb/attach/a.out [ 1] /Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0/Symbols/usr/lib/dyld [ 2] /Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0/Symbols/usr/lib/libSystem.B.dylib Note that this is all happening prior to running _or_ connecting to a remote platform. Once connected to a remote platform the OS version might change which means we will need to update our dependecies. Also once we run, we will need to match up the actualy binaries with the actualy UUID's to files in the SDK, or download and cache them locally. This is just the start of the remote platforms, but this modification is the first iteration in getting the platforms really doing something. llvm-svn: 127934
2011-03-19 09:12:21 +08:00
if (symtab) {
Fixed the LLDB build so that we can have private types, private enums and public types and public enums. This was done to keep the SWIG stuff from parsing all sorts of enums and types that weren't needed, and allows us to abstract our API better. llvm-svn: 128239
2011-03-25 05:19:54 +08:00
Symbol *symbol = symtab->FindSymbolContainingFileAddress(file_addr);
Added more platform support. There are now some new commands: platform status -- gets status information for the selected platform platform create <platform-name> -- creates a new instance of a remote platform platform list -- list all available platforms platform select -- select a platform instance as the current platform (not working yet) When using "platform create" it will create a remote platform and make it the selected platform. For instances for iPhone OS debugging on Mac OS X one can do: (lldb) platform create remote-ios --sdk-version=4.0 Remote platform: iOS platform SDK version: 4.0 SDK path: "/Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0" Not connected to a remote device. (lldb) file ~/Documents/a.out Current executable set to '~/Documents/a.out' (armv6). (lldb) image list [ 0] /Volumes/work/gclayton/Documents/devb/attach/a.out [ 1] /Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0/Symbols/usr/lib/dyld [ 2] /Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0/Symbols/usr/lib/libSystem.B.dylib Note that this is all happening prior to running _or_ connecting to a remote platform. Once connected to a remote platform the OS version might change which means we will need to update our dependecies. Also once we run, we will need to match up the actualy binaries with the actualy UUID's to files in the SDK, or download and cache them locally. This is just the start of the remote platforms, but this modification is the first iteration in getting the platforms really doing something. llvm-svn: 127934
2011-03-19 09:12:21 +08:00
if (symbol) {
Fixed the LLDB build so that we can have private types, private enums and public types and public enums. This was done to keep the SWIG stuff from parsing all sorts of enums and types that weren't needed, and allows us to abstract our API better. llvm-svn: 128239
2011-03-25 05:19:54 +08:00
if (symbol->ValueIsAddress()) {
Resubmitting 240466 after fixing the linux test suite failures. A few extras were fixed - Symbol::GetAddress() now returns an Address object, not a reference. There were places where people were accessing the address of a symbol when the symbol's value wasn't an address symbol. On MacOSX, undefined symbols have a value zero and some places where using the symbol's address and getting an absolute address of zero (since an Address object with no section and an m_offset whose value isn't LLDB_INVALID_ADDRESS is considered an absolute address). So fixing this required some changes to make sure people were getting what they expected. - Since some places want to access the address as a reference, I added a few new functions to symbol: Address &Symbol::GetAddressRef(); const Address &Symbol::GetAddressRef() const; Linux test suite passes just fine now. <rdar://problem/21494354> llvm-svn: 240702
2015-06-26 05:46:34 +08:00
const SectionSP section_sp(symbol->GetAddressRef().GetSection());
<rdar://problem/10103468> I started work on being able to add symbol files after a debug session had started with a new "target symfile add" command and quickly ran into problems with stale Address objects in breakpoint locations that had lldb_private::Section pointers into modules that had been removed or replaced. This also let to grabbing stale modules from those sections. So I needed to thread harded the Address, Section and related objects. To do this I modified the ModuleChild class to now require a ModuleSP on initialization so that a weak reference can created. I also changed all places that were handing out "Section *" to have them hand out SectionSP. All ObjectFile, SymbolFile and SymbolVendors were inheriting from ModuleChild so all of the find plug-in, static creation function and constructors now require ModuleSP references instead of Module *. Address objects now have weak references to their sections which can safely go stale when a module gets destructed. This checkin doesn't complete the "target symfile add" command, but it does get us a lot clioser to being able to do such things without a high risk of crashing or memory corruption. llvm-svn: 151336
2012-02-24 09:59:29 +08:00
if (section_sp) {
Fixed the LLDB build so that we can have private types, private enums and public types and public enums. This was done to keep the SWIG stuff from parsing all sorts of enums and types that weren't needed, and allows us to abstract our API better. llvm-svn: 128239
2011-03-25 05:19:54 +08:00
const SectionType section_type = section_sp->GetType();
Added more platform support. There are now some new commands: platform status -- gets status information for the selected platform platform create <platform-name> -- creates a new instance of a remote platform platform list -- list all available platforms platform select -- select a platform instance as the current platform (not working yet) When using "platform create" it will create a remote platform and make it the selected platform. For instances for iPhone OS debugging on Mac OS X one can do: (lldb) platform create remote-ios --sdk-version=4.0 Remote platform: iOS platform SDK version: 4.0 SDK path: "/Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0" Not connected to a remote device. (lldb) file ~/Documents/a.out Current executable set to '~/Documents/a.out' (armv6). (lldb) image list [ 0] /Volumes/work/gclayton/Documents/devb/attach/a.out [ 1] /Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0/Symbols/usr/lib/dyld [ 2] /Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0/Symbols/usr/lib/libSystem.B.dylib Note that this is all happening prior to running _or_ connecting to a remote platform. Once connected to a remote platform the OS version might change which means we will need to update our dependecies. Also once we run, we will need to match up the actualy binaries with the actualy UUID's to files in the SDK, or download and cache them locally. This is just the start of the remote platforms, but this modification is the first iteration in getting the platforms really doing something. llvm-svn: 127934
2011-03-19 09:12:21 +08:00
switch (section_type) {
case eSectionTypeInvalid:
Change AddressClass type from 'enum' to 'enum class'. If we have a function with signature f(addr_t, AddressClass), it is easy to muddle up the order of arguments without any warnings from compiler. 'enum class' prevents passing integer in place of AddressClass and vice versa. llvm-svn: 335599
2018-06-26 21:06:54 +08:00
return AddressClass::eUnknown;
Added more platform support. There are now some new commands: platform status -- gets status information for the selected platform platform create <platform-name> -- creates a new instance of a remote platform platform list -- list all available platforms platform select -- select a platform instance as the current platform (not working yet) When using "platform create" it will create a remote platform and make it the selected platform. For instances for iPhone OS debugging on Mac OS X one can do: (lldb) platform create remote-ios --sdk-version=4.0 Remote platform: iOS platform SDK version: 4.0 SDK path: "/Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0" Not connected to a remote device. (lldb) file ~/Documents/a.out Current executable set to '~/Documents/a.out' (armv6). (lldb) image list [ 0] /Volumes/work/gclayton/Documents/devb/attach/a.out [ 1] /Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0/Symbols/usr/lib/dyld [ 2] /Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0/Symbols/usr/lib/libSystem.B.dylib Note that this is all happening prior to running _or_ connecting to a remote platform. Once connected to a remote platform the OS version might change which means we will need to update our dependecies. Also once we run, we will need to match up the actualy binaries with the actualy UUID's to files in the SDK, or download and cache them locally. This is just the start of the remote platforms, but this modification is the first iteration in getting the platforms really doing something. llvm-svn: 127934
2011-03-19 09:12:21 +08:00
case eSectionTypeCode:
Change AddressClass type from 'enum' to 'enum class'. If we have a function with signature f(addr_t, AddressClass), it is easy to muddle up the order of arguments without any warnings from compiler. 'enum class' prevents passing integer in place of AddressClass and vice versa. llvm-svn: 335599
2018-06-26 21:06:54 +08:00
return AddressClass::eCode;
Added eSymbolTypeResolver to a few switch statements that needed it. llvm-svn: 176210
2013-02-28 05:16:04 +08:00
case eSectionTypeContainer:
Change AddressClass type from 'enum' to 'enum class'. If we have a function with signature f(addr_t, AddressClass), it is easy to muddle up the order of arguments without any warnings from compiler. 'enum class' prevents passing integer in place of AddressClass and vice versa. llvm-svn: 335599
2018-06-26 21:06:54 +08:00
return AddressClass::eUnknown;
Added more platform support. There are now some new commands: platform status -- gets status information for the selected platform platform create <platform-name> -- creates a new instance of a remote platform platform list -- list all available platforms platform select -- select a platform instance as the current platform (not working yet) When using "platform create" it will create a remote platform and make it the selected platform. For instances for iPhone OS debugging on Mac OS X one can do: (lldb) platform create remote-ios --sdk-version=4.0 Remote platform: iOS platform SDK version: 4.0 SDK path: "/Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0" Not connected to a remote device. (lldb) file ~/Documents/a.out Current executable set to '~/Documents/a.out' (armv6). (lldb) image list [ 0] /Volumes/work/gclayton/Documents/devb/attach/a.out [ 1] /Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0/Symbols/usr/lib/dyld [ 2] /Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0/Symbols/usr/lib/libSystem.B.dylib Note that this is all happening prior to running _or_ connecting to a remote platform. Once connected to a remote platform the OS version might change which means we will need to update our dependecies. Also once we run, we will need to match up the actualy binaries with the actualy UUID's to files in the SDK, or download and cache them locally. This is just the start of the remote platforms, but this modification is the first iteration in getting the platforms really doing something. llvm-svn: 127934
2011-03-19 09:12:21 +08: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-28 01:55:14 +08:00
case eSectionTypeDataCString:
case eSectionTypeDataCStringPointers:
Added more platform support. There are now some new commands: platform status -- gets status information for the selected platform platform create <platform-name> -- creates a new instance of a remote platform platform list -- list all available platforms platform select -- select a platform instance as the current platform (not working yet) When using "platform create" it will create a remote platform and make it the selected platform. For instances for iPhone OS debugging on Mac OS X one can do: (lldb) platform create remote-ios --sdk-version=4.0 Remote platform: iOS platform SDK version: 4.0 SDK path: "/Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0" Not connected to a remote device. (lldb) file ~/Documents/a.out Current executable set to '~/Documents/a.out' (armv6). (lldb) image list [ 0] /Volumes/work/gclayton/Documents/devb/attach/a.out [ 1] /Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0/Symbols/usr/lib/dyld [ 2] /Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0/Symbols/usr/lib/libSystem.B.dylib Note that this is all happening prior to running _or_ connecting to a remote platform. Once connected to a remote platform the OS version might change which means we will need to update our dependecies. Also once we run, we will need to match up the actualy binaries with the actualy UUID's to files in the SDK, or download and cache them locally. This is just the start of the remote platforms, but this modification is the first iteration in getting the platforms really doing something. llvm-svn: 127934
2011-03-19 09:12:21 +08: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-28 01:55:14 +08:00
case eSectionTypeData8:
case eSectionTypeData16:
Added more platform support. There are now some new commands: platform status -- gets status information for the selected platform platform create <platform-name> -- creates a new instance of a remote platform platform list -- list all available platforms platform select -- select a platform instance as the current platform (not working yet) When using "platform create" it will create a remote platform and make it the selected platform. For instances for iPhone OS debugging on Mac OS X one can do: (lldb) platform create remote-ios --sdk-version=4.0 Remote platform: iOS platform SDK version: 4.0 SDK path: "/Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0" Not connected to a remote device. (lldb) file ~/Documents/a.out Current executable set to '~/Documents/a.out' (armv6). (lldb) image list [ 0] /Volumes/work/gclayton/Documents/devb/attach/a.out [ 1] /Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0/Symbols/usr/lib/dyld [ 2] /Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0/Symbols/usr/lib/libSystem.B.dylib Note that this is all happening prior to running _or_ connecting to a remote platform. Once connected to a remote platform the OS version might change which means we will need to update our dependecies. Also once we run, we will need to match up the actualy binaries with the actualy UUID's to files in the SDK, or download and cache them locally. This is just the start of the remote platforms, but this modification is the first iteration in getting the platforms really doing something. llvm-svn: 127934
2011-03-19 09:12:21 +08:00
case eSectionTypeDataPointers:
case eSectionTypeZeroFill:
case eSectionTypeDataObjCMessageRefs:
case eSectionTypeDataObjCCFStrings:
case eSectionTypeGoSymtab:
Change AddressClass type from 'enum' to 'enum class'. If we have a function with signature f(addr_t, AddressClass), it is easy to muddle up the order of arguments without any warnings from compiler. 'enum class' prevents passing integer in place of AddressClass and vice versa. llvm-svn: 335599
2018-06-26 21:06:54 +08:00
return AddressClass::eData;
Added more platform support. There are now some new commands: platform status -- gets status information for the selected platform platform create <platform-name> -- creates a new instance of a remote platform platform list -- list all available platforms platform select -- select a platform instance as the current platform (not working yet) When using "platform create" it will create a remote platform and make it the selected platform. For instances for iPhone OS debugging on Mac OS X one can do: (lldb) platform create remote-ios --sdk-version=4.0 Remote platform: iOS platform SDK version: 4.0 SDK path: "/Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0" Not connected to a remote device. (lldb) file ~/Documents/a.out Current executable set to '~/Documents/a.out' (armv6). (lldb) image list [ 0] /Volumes/work/gclayton/Documents/devb/attach/a.out [ 1] /Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0/Symbols/usr/lib/dyld [ 2] /Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0/Symbols/usr/lib/libSystem.B.dylib Note that this is all happening prior to running _or_ connecting to a remote platform. Once connected to a remote platform the OS version might change which means we will need to update our dependecies. Also once we run, we will need to match up the actualy binaries with the actualy UUID's to files in the SDK, or download and cache them locally. This is just the start of the remote platforms, but this modification is the first iteration in getting the platforms really doing something. llvm-svn: 127934
2011-03-19 09:12:21 +08:00
case eSectionTypeDebug:
case eSectionTypeDWARFDebugAbbrev:
[LLDB] - Recommit r346848 "[LLDB] - Support the single file split DWARF.". Test cases were updated to not use the local compilation dir which is different between development pc and build bots. Original commit message: [LLDB] - Support the single file split DWARF. DWARF5 spec describes a single file split dwarf case (when .dwo sections are in the .o files). Problem is that LLDB does not work correctly in that case. The issue is that, for example, both .debug_info and .debug_info.dwo has the same type: eSectionTypeDWARFDebugInfo. And when code searches section by type it might find the regular debug section and not the .dwo one. The patch fixes that. With it, LLDB is able to work with output compiled with -gsplit-dwarf=single flag correctly. Differential revision: https://reviews.llvm.org/D52403 llvm-svn: 346855
2018-11-14 21:01:15 +08:00
case eSectionTypeDWARFDebugAbbrevDwo:
Added more platform support. There are now some new commands: platform status -- gets status information for the selected platform platform create <platform-name> -- creates a new instance of a remote platform platform list -- list all available platforms platform select -- select a platform instance as the current platform (not working yet) When using "platform create" it will create a remote platform and make it the selected platform. For instances for iPhone OS debugging on Mac OS X one can do: (lldb) platform create remote-ios --sdk-version=4.0 Remote platform: iOS platform SDK version: 4.0 SDK path: "/Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0" Not connected to a remote device. (lldb) file ~/Documents/a.out Current executable set to '~/Documents/a.out' (armv6). (lldb) image list [ 0] /Volumes/work/gclayton/Documents/devb/attach/a.out [ 1] /Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0/Symbols/usr/lib/dyld [ 2] /Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0/Symbols/usr/lib/libSystem.B.dylib Note that this is all happening prior to running _or_ connecting to a remote platform. Once connected to a remote platform the OS version might change which means we will need to update our dependecies. Also once we run, we will need to match up the actualy binaries with the actualy UUID's to files in the SDK, or download and cache them locally. This is just the start of the remote platforms, but this modification is the first iteration in getting the platforms really doing something. llvm-svn: 127934
2011-03-19 09:12:21 +08: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-28 01:55:14 +08:00
case eSectionTypeDWARFDebugAranges:
Add support for the DWP debug info format Summary: The DWP (DWARF package) format is used to pack multiple dwo files generated by split-dwarf into a single ELF file to make distributing them easier. It is part of the DWARFv5 spec and can be generated by dwp or llvm-dwp from a set of dwo files. Caviats: * Only the new version of the dwp format is supported (v2 in GNU numbering schema and v5 in the DWARF spec). The old version (v1) is already deprecated but binutils 2.24 still generates that one. * Combining DWP files with module debugging is not yet supported. Subscribers: emaste, mgorny, aprantl Differential Revision: https://reviews.llvm.org/D36062 llvm-svn: 311775
2017-08-25 21:56:14 +08:00
case eSectionTypeDWARFDebugCuIndex:
Added more platform support. There are now some new commands: platform status -- gets status information for the selected platform platform create <platform-name> -- creates a new instance of a remote platform platform list -- list all available platforms platform select -- select a platform instance as the current platform (not working yet) When using "platform create" it will create a remote platform and make it the selected platform. For instances for iPhone OS debugging on Mac OS X one can do: (lldb) platform create remote-ios --sdk-version=4.0 Remote platform: iOS platform SDK version: 4.0 SDK path: "/Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0" Not connected to a remote device. (lldb) file ~/Documents/a.out Current executable set to '~/Documents/a.out' (armv6). (lldb) image list [ 0] /Volumes/work/gclayton/Documents/devb/attach/a.out [ 1] /Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0/Symbols/usr/lib/dyld [ 2] /Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0/Symbols/usr/lib/libSystem.B.dylib Note that this is all happening prior to running _or_ connecting to a remote platform. Once connected to a remote platform the OS version might change which means we will need to update our dependecies. Also once we run, we will need to match up the actualy binaries with the actualy UUID's to files in the SDK, or download and cache them locally. This is just the start of the remote platforms, but this modification is the first iteration in getting the platforms really doing something. llvm-svn: 127934
2011-03-19 09:12:21 +08: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-28 01:55:14 +08:00
case eSectionTypeDWARFDebugInfo:
[LLDB] - Recommit r346848 "[LLDB] - Support the single file split DWARF.". Test cases were updated to not use the local compilation dir which is different between development pc and build bots. Original commit message: [LLDB] - Support the single file split DWARF. DWARF5 spec describes a single file split dwarf case (when .dwo sections are in the .o files). Problem is that LLDB does not work correctly in that case. The issue is that, for example, both .debug_info and .debug_info.dwo has the same type: eSectionTypeDWARFDebugInfo. And when code searches section by type it might find the regular debug section and not the .dwo one. The patch fixes that. With it, LLDB is able to work with output compiled with -gsplit-dwarf=single flag correctly. Differential revision: https://reviews.llvm.org/D52403 llvm-svn: 346855
2018-11-14 21:01:15 +08:00
case eSectionTypeDWARFDebugInfoDwo:
Added more platform support. There are now some new commands: platform status -- gets status information for the selected platform platform create <platform-name> -- creates a new instance of a remote platform platform list -- list all available platforms platform select -- select a platform instance as the current platform (not working yet) When using "platform create" it will create a remote platform and make it the selected platform. For instances for iPhone OS debugging on Mac OS X one can do: (lldb) platform create remote-ios --sdk-version=4.0 Remote platform: iOS platform SDK version: 4.0 SDK path: "/Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0" Not connected to a remote device. (lldb) file ~/Documents/a.out Current executable set to '~/Documents/a.out' (armv6). (lldb) image list [ 0] /Volumes/work/gclayton/Documents/devb/attach/a.out [ 1] /Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0/Symbols/usr/lib/dyld [ 2] /Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0/Symbols/usr/lib/libSystem.B.dylib Note that this is all happening prior to running _or_ connecting to a remote platform. Once connected to a remote platform the OS version might change which means we will need to update our dependecies. Also once we run, we will need to match up the actualy binaries with the actualy UUID's to files in the SDK, or download and cache them locally. This is just the start of the remote platforms, but this modification is the first iteration in getting the platforms really doing something. llvm-svn: 127934
2011-03-19 09:12:21 +08:00
case eSectionTypeDWARFDebugLine:
[LLDB] - Improved DWARF5 support. This patch improves the support of DWARF5. Particularly the reporting of source code locations. Differential revision: https://reviews.llvm.org/D51935 llvm-svn: 342153
2018-09-14 01:06:47 +08: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-28 01:55:14 +08:00
case eSectionTypeDWARFDebugLoc:
[LLDB] - Implement the support for the .debug_loclists section. This implements the support for .debug_loclists section, which is DWARF 5 version of .debug_loc. Currently, clang is able to emit it with the use of D53365. Differential revision: https://reviews.llvm.org/D53436 llvm-svn: 345016
2018-10-23 17:46:15 +08:00
case eSectionTypeDWARFDebugLocLists:
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-28 01:55:14 +08:00
case eSectionTypeDWARFDebugMacInfo:
Read macro info from .debug_macro section and use it for expression evaluation. Summary: DWARF 5 proposes a reinvented .debug_macro section. This change follows that spec. Currently, only GCC produces the .debug_macro section and hence the added test is annottated with expectedFailureClang. Reviewers: spyffe, clayborg, tberghammer Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D15437 llvm-svn: 255729
2015-12-16 08:22:08 +08:00
case eSectionTypeDWARFDebugMacro:
Add .debug_names section glue code llvm-svn: 333743
2018-06-01 20:06:45 +08: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-28 01:55:14 +08:00
case eSectionTypeDWARFDebugPubNames:
Added more platform support. There are now some new commands: platform status -- gets status information for the selected platform platform create <platform-name> -- creates a new instance of a remote platform platform list -- list all available platforms platform select -- select a platform instance as the current platform (not working yet) When using "platform create" it will create a remote platform and make it the selected platform. For instances for iPhone OS debugging on Mac OS X one can do: (lldb) platform create remote-ios --sdk-version=4.0 Remote platform: iOS platform SDK version: 4.0 SDK path: "/Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0" Not connected to a remote device. (lldb) file ~/Documents/a.out Current executable set to '~/Documents/a.out' (armv6). (lldb) image list [ 0] /Volumes/work/gclayton/Documents/devb/attach/a.out [ 1] /Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0/Symbols/usr/lib/dyld [ 2] /Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0/Symbols/usr/lib/libSystem.B.dylib Note that this is all happening prior to running _or_ connecting to a remote platform. Once connected to a remote platform the OS version might change which means we will need to update our dependecies. Also once we run, we will need to match up the actualy binaries with the actualy UUID's to files in the SDK, or download and cache them locally. This is just the start of the remote platforms, but this modification is the first iteration in getting the platforms really doing something. llvm-svn: 127934
2011-03-19 09:12:21 +08:00
case eSectionTypeDWARFDebugPubTypes:
case eSectionTypeDWARFDebugRanges:
[LLDB] - Add basic support for .debug_rnglists section (DWARF5) This adds a basic support of the .debug_rnglists section. Only the DW_RLE_start_length and DW_RLE_end_of_list entries are supported. Differential revision: https://reviews.llvm.org/D52981 llvm-svn: 344119
2018-10-10 16:11:15 +08:00
case eSectionTypeDWARFDebugRngLists:
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-28 01:55:14 +08:00
case eSectionTypeDWARFDebugStr:
[LLDB] - Recommit r346848 "[LLDB] - Support the single file split DWARF.". Test cases were updated to not use the local compilation dir which is different between development pc and build bots. Original commit message: [LLDB] - Support the single file split DWARF. DWARF5 spec describes a single file split dwarf case (when .dwo sections are in the .o files). Problem is that LLDB does not work correctly in that case. The issue is that, for example, both .debug_info and .debug_info.dwo has the same type: eSectionTypeDWARFDebugInfo. And when code searches section by type it might find the regular debug section and not the .dwo one. The patch fixes that. With it, LLDB is able to work with output compiled with -gsplit-dwarf=single flag correctly. Differential revision: https://reviews.llvm.org/D52403 llvm-svn: 346855
2018-11-14 21:01:15 +08:00
case eSectionTypeDWARFDebugStrDwo:
Added more platform support. There are now some new commands: platform status -- gets status information for the selected platform platform create <platform-name> -- creates a new instance of a remote platform platform list -- list all available platforms platform select -- select a platform instance as the current platform (not working yet) When using "platform create" it will create a remote platform and make it the selected platform. For instances for iPhone OS debugging on Mac OS X one can do: (lldb) platform create remote-ios --sdk-version=4.0 Remote platform: iOS platform SDK version: 4.0 SDK path: "/Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0" Not connected to a remote device. (lldb) file ~/Documents/a.out Current executable set to '~/Documents/a.out' (armv6). (lldb) image list [ 0] /Volumes/work/gclayton/Documents/devb/attach/a.out [ 1] /Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0/Symbols/usr/lib/dyld [ 2] /Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0/Symbols/usr/lib/libSystem.B.dylib Note that this is all happening prior to running _or_ connecting to a remote platform. Once connected to a remote platform the OS version might change which means we will need to update our dependecies. Also once we run, we will need to match up the actualy binaries with the actualy UUID's to files in the SDK, or download and cache them locally. This is just the start of the remote platforms, but this modification is the first iteration in getting the platforms really doing something. llvm-svn: 127934
2011-03-19 09:12:21 +08:00
case eSectionTypeDWARFDebugStrOffsets:
[LLDB] - Recommit r346848 "[LLDB] - Support the single file split DWARF.". Test cases were updated to not use the local compilation dir which is different between development pc and build bots. Original commit message: [LLDB] - Support the single file split DWARF. DWARF5 spec describes a single file split dwarf case (when .dwo sections are in the .o files). Problem is that LLDB does not work correctly in that case. The issue is that, for example, both .debug_info and .debug_info.dwo has the same type: eSectionTypeDWARFDebugInfo. And when code searches section by type it might find the regular debug section and not the .dwo one. The patch fixes that. With it, LLDB is able to work with output compiled with -gsplit-dwarf=single flag correctly. Differential revision: https://reviews.llvm.org/D52403 llvm-svn: 346855
2018-11-14 21:01:15 +08:00
case eSectionTypeDWARFDebugStrOffsetsDwo:
Add support to object files for accessing the .debug_types section In an effort to make the .debug_types patch smaller, breaking out the part that reads the .debug_types from object files into a separate patch Differential Revision: https://reviews.llvm.org/D46529 llvm-svn: 331777
2018-05-09 01:19:24 +08:00
case eSectionTypeDWARFDebugTypes:
Recognise debug_types.dwo as a debug info section This is a preparatory patch to allow reading type units from dwo files. llvm-svn: 363146
2019-06-12 19:42:42 +08:00
case eSectionTypeDWARFDebugTypesDwo:
Added more platform support. There are now some new commands: platform status -- gets status information for the selected platform platform create <platform-name> -- creates a new instance of a remote platform platform list -- list all available platforms platform select -- select a platform instance as the current platform (not working yet) When using "platform create" it will create a remote platform and make it the selected platform. For instances for iPhone OS debugging on Mac OS X one can do: (lldb) platform create remote-ios --sdk-version=4.0 Remote platform: iOS platform SDK version: 4.0 SDK path: "/Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0" Not connected to a remote device. (lldb) file ~/Documents/a.out Current executable set to '~/Documents/a.out' (armv6). (lldb) image list [ 0] /Volumes/work/gclayton/Documents/devb/attach/a.out [ 1] /Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0/Symbols/usr/lib/dyld [ 2] /Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0/Symbols/usr/lib/libSystem.B.dylib Note that this is all happening prior to running _or_ connecting to a remote platform. Once connected to a remote platform the OS version might change which means we will need to update our dependecies. Also once we run, we will need to match up the actualy binaries with the actualy UUID's to files in the SDK, or download and cache them locally. This is just the start of the remote platforms, but this modification is the first iteration in getting the platforms really doing something. llvm-svn: 127934
2011-03-19 09:12:21 +08:00
case eSectionTypeDWARFAppleNames:
case eSectionTypeDWARFAppleTypes:
case eSectionTypeDWARFAppleNamespaces:
case eSectionTypeDWARFAppleObjC:
Support reading section ".gnu_debugaltlink" Differential revision: https://reviews.llvm.org/D40468 llvm-svn: 331148
2018-04-30 03:47:48 +08:00
case eSectionTypeDWARFGNUDebugAltLink:
Change AddressClass type from 'enum' to 'enum class'. If we have a function with signature f(addr_t, AddressClass), it is easy to muddle up the order of arguments without any warnings from compiler. 'enum class' prevents passing integer in place of AddressClass and vice versa. llvm-svn: 335599
2018-06-26 21:06:54 +08:00
return AddressClass::eDebug;
Added more platform support. There are now some new commands: platform status -- gets status information for the selected platform platform create <platform-name> -- creates a new instance of a remote platform platform list -- list all available platforms platform select -- select a platform instance as the current platform (not working yet) When using "platform create" it will create a remote platform and make it the selected platform. For instances for iPhone OS debugging on Mac OS X one can do: (lldb) platform create remote-ios --sdk-version=4.0 Remote platform: iOS platform SDK version: 4.0 SDK path: "/Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0" Not connected to a remote device. (lldb) file ~/Documents/a.out Current executable set to '~/Documents/a.out' (armv6). (lldb) image list [ 0] /Volumes/work/gclayton/Documents/devb/attach/a.out [ 1] /Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0/Symbols/usr/lib/dyld [ 2] /Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0/Symbols/usr/lib/libSystem.B.dylib Note that this is all happening prior to running _or_ connecting to a remote platform. Once connected to a remote platform the OS version might change which means we will need to update our dependecies. Also once we run, we will need to match up the actualy binaries with the actualy UUID's to files in the SDK, or download and cache them locally. This is just the start of the remote platforms, but this modification is the first iteration in getting the platforms really doing something. llvm-svn: 127934
2011-03-19 09:12:21 +08:00
case eSectionTypeEHFrame:
case eSectionTypeARMexidx:
case eSectionTypeARMextab:
case eSectionTypeCompactUnwind:
Change AddressClass type from 'enum' to 'enum class'. If we have a function with signature f(addr_t, AddressClass), it is easy to muddle up the order of arguments without any warnings from compiler. 'enum class' prevents passing integer in place of AddressClass and vice versa. llvm-svn: 335599
2018-06-26 21:06:54 +08:00
return AddressClass::eRuntime;
Added more platform support. There are now some new commands: platform status -- gets status information for the selected platform platform create <platform-name> -- creates a new instance of a remote platform platform list -- list all available platforms platform select -- select a platform instance as the current platform (not working yet) When using "platform create" it will create a remote platform and make it the selected platform. For instances for iPhone OS debugging on Mac OS X one can do: (lldb) platform create remote-ios --sdk-version=4.0 Remote platform: iOS platform SDK version: 4.0 SDK path: "/Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0" Not connected to a remote device. (lldb) file ~/Documents/a.out Current executable set to '~/Documents/a.out' (armv6). (lldb) image list [ 0] /Volumes/work/gclayton/Documents/devb/attach/a.out [ 1] /Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0/Symbols/usr/lib/dyld [ 2] /Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0/Symbols/usr/lib/libSystem.B.dylib Note that this is all happening prior to running _or_ connecting to a remote platform. Once connected to a remote platform the OS version might change which means we will need to update our dependecies. Also once we run, we will need to match up the actualy binaries with the actualy UUID's to files in the SDK, or download and cache them locally. This is just the start of the remote platforms, but this modification is the first iteration in getting the platforms really doing something. llvm-svn: 127934
2011-03-19 09:12:21 +08:00
case eSectionTypeELFSymbolTable:
case eSectionTypeELFDynamicSymbols:
case eSectionTypeELFRelocationEntries:
case eSectionTypeELFDynamicLinkInfo:
sweep up -Wformat warnings from gcc This is a purely mechanical change explicitly casting any parameters for printf style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux. llvm-svn: 205607
2014-04-04 12:06:10 +08:00
case eSectionTypeOther:
Change AddressClass type from 'enum' to 'enum class'. If we have a function with signature f(addr_t, AddressClass), it is easy to muddle up the order of arguments without any warnings from compiler. 'enum class' prevents passing integer in place of AddressClass and vice versa. llvm-svn: 335599
2018-06-26 21:06:54 +08:00
return AddressClass::eUnknown;
Added new symbol types for Objective C classes, metaclasses, and ivars. Each object file can correctly make these symbols which will abstract us from the file format and ABI and we can then ask for the objective C class symbol for a class and find out which object file it was defined in. llvm-svn: 145744
2011-12-03 10:30:59 +08:00
case eSectionTypeAbsoluteAddress:
<rdar://problem/14496092> Fixed an issue with reexported symbols on MacOSX by adding support for symbols re-exporting symbols. There is now a new symbol type eSymbolTypeReExported which contains a new name for the re-exported symbol and the new shared library. These symbols are only used when a symbol is re-exported as a symbol under a different name. Modified the expression parser to be able to deal with finding the re-exported symbols and track down the actual symbol it refers to. llvm-svn: 193101
2013-10-22 02:40:51 +08:00
// In case of absolute sections decide the address class based on
Reflow paragraphs in comments. This is intended as a clean up after the big clang-format commit (r280751), which unfortunately resulted in many of the comment paragraphs in LLDB being very hard to read. FYI, the script I used was: import textwrap import commands import os import sys import re tmp = "%s.tmp"%sys.argv[1] out = open(tmp, "w+") with open(sys.argv[1], "r") as f: header = "" text = "" comment = re.compile(r'^( *//) ([^ ].*)$') special = re.compile(r'^((([A-Z]+[: ])|([0-9]+ )).*)|(.*;)$') for line in f: match = comment.match(line) if match and not special.match(match.group(2)): # skip intentionally short comments. if not text and len(match.group(2)) < 40: out.write(line) continue if text: text += " " + match.group(2) else: header = match.group(1) text = match.group(2) continue if text: filled = textwrap.wrap(text, width=(78-len(header)), break_long_words=False) for l in filled: out.write(header+" "+l+'\n') text = "" out.write(line) os.rename(tmp, sys.argv[1]) Differential Revision: https://reviews.llvm.org/D46144 llvm-svn: 331197
2018-05-01 00:49:04 +08:00
// the symbol type because the section type isn't specify if it is
// a code or a data section.
<rdar://problem/14496092> Fixed an issue with reexported symbols on MacOSX by adding support for symbols re-exporting symbols. There is now a new symbol type eSymbolTypeReExported which contains a new name for the re-exported symbol and the new shared library. These symbols are only used when a symbol is re-exported as a symbol under a different name. Modified the expression parser to be able to deal with finding the re-exported symbols and track down the actual symbol it refers to. llvm-svn: 193101
2013-10-22 02:40:51 +08:00
break;
Added more platform support. There are now some new commands: platform status -- gets status information for the selected platform platform create <platform-name> -- creates a new instance of a remote platform platform list -- list all available platforms platform select -- select a platform instance as the current platform (not working yet) When using "platform create" it will create a remote platform and make it the selected platform. For instances for iPhone OS debugging on Mac OS X one can do: (lldb) platform create remote-ios --sdk-version=4.0 Remote platform: iOS platform SDK version: 4.0 SDK path: "/Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0" Not connected to a remote device. (lldb) file ~/Documents/a.out Current executable set to '~/Documents/a.out' (armv6). (lldb) image list [ 0] /Volumes/work/gclayton/Documents/devb/attach/a.out [ 1] /Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0/Symbols/usr/lib/dyld [ 2] /Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0/Symbols/usr/lib/libSystem.B.dylib Note that this is all happening prior to running _or_ connecting to a remote platform. Once connected to a remote platform the OS version might change which means we will need to update our dependecies. Also once we run, we will need to match up the actualy binaries with the actualy UUID's to files in the SDK, or download and cache them locally. This is just the start of the remote platforms, but this modification is the first iteration in getting the platforms really doing something. llvm-svn: 127934
2011-03-19 09:12:21 +08:00
}
}
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
}
<rdar://problem/10103468> I started work on being able to add symbol files after a debug session had started with a new "target symfile add" command and quickly ran into problems with stale Address objects in breakpoint locations that had lldb_private::Section pointers into modules that had been removed or replaced. This also let to grabbing stale modules from those sections. So I needed to thread harded the Address, Section and related objects. To do this I modified the ModuleChild class to now require a ModuleSP on initialization so that a weak reference can created. I also changed all places that were handing out "Section *" to have them hand out SectionSP. All ObjectFile, SymbolFile and SymbolVendors were inheriting from ModuleChild so all of the find plug-in, static creation function and constructors now require ModuleSP references instead of Module *. Address objects now have weak references to their sections which can safely go stale when a module gets destructed. This checkin doesn't complete the "target symfile add" command, but it does get us a lot clioser to being able to do such things without a high risk of crashing or memory corruption. llvm-svn: 151336
2012-02-24 09:59:29 +08:00
const SymbolType symbol_type = symbol->GetType();
Added more platform support. There are now some new commands: platform status -- gets status information for the selected platform platform create <platform-name> -- creates a new instance of a remote platform platform list -- list all available platforms platform select -- select a platform instance as the current platform (not working yet) When using "platform create" it will create a remote platform and make it the selected platform. For instances for iPhone OS debugging on Mac OS X one can do: (lldb) platform create remote-ios --sdk-version=4.0 Remote platform: iOS platform SDK version: 4.0 SDK path: "/Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0" Not connected to a remote device. (lldb) file ~/Documents/a.out Current executable set to '~/Documents/a.out' (armv6). (lldb) image list [ 0] /Volumes/work/gclayton/Documents/devb/attach/a.out [ 1] /Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0/Symbols/usr/lib/dyld [ 2] /Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0/Symbols/usr/lib/libSystem.B.dylib Note that this is all happening prior to running _or_ connecting to a remote platform. Once connected to a remote platform the OS version might change which means we will need to update our dependecies. Also once we run, we will need to match up the actualy binaries with the actualy UUID's to files in the SDK, or download and cache them locally. This is just the start of the remote platforms, but this modification is the first iteration in getting the platforms really doing something. llvm-svn: 127934
2011-03-19 09:12:21 +08:00
switch (symbol_type) {
case eSymbolTypeAny:
Change AddressClass type from 'enum' to 'enum class'. If we have a function with signature f(addr_t, AddressClass), it is easy to muddle up the order of arguments without any warnings from compiler. 'enum class' prevents passing integer in place of AddressClass and vice versa. llvm-svn: 335599
2018-06-26 21:06:54 +08:00
return AddressClass::eUnknown;
Added more platform support. There are now some new commands: platform status -- gets status information for the selected platform platform create <platform-name> -- creates a new instance of a remote platform platform list -- list all available platforms platform select -- select a platform instance as the current platform (not working yet) When using "platform create" it will create a remote platform and make it the selected platform. For instances for iPhone OS debugging on Mac OS X one can do: (lldb) platform create remote-ios --sdk-version=4.0 Remote platform: iOS platform SDK version: 4.0 SDK path: "/Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0" Not connected to a remote device. (lldb) file ~/Documents/a.out Current executable set to '~/Documents/a.out' (armv6). (lldb) image list [ 0] /Volumes/work/gclayton/Documents/devb/attach/a.out [ 1] /Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0/Symbols/usr/lib/dyld [ 2] /Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0/Symbols/usr/lib/libSystem.B.dylib Note that this is all happening prior to running _or_ connecting to a remote platform. Once connected to a remote platform the OS version might change which means we will need to update our dependecies. Also once we run, we will need to match up the actualy binaries with the actualy UUID's to files in the SDK, or download and cache them locally. This is just the start of the remote platforms, but this modification is the first iteration in getting the platforms really doing something. llvm-svn: 127934
2011-03-19 09:12:21 +08:00
case eSymbolTypeAbsolute:
Change AddressClass type from 'enum' to 'enum class'. If we have a function with signature f(addr_t, AddressClass), it is easy to muddle up the order of arguments without any warnings from compiler. 'enum class' prevents passing integer in place of AddressClass and vice versa. llvm-svn: 335599
2018-06-26 21:06:54 +08:00
return AddressClass::eUnknown;
Split symbol support for ELF and Linux. llvm-svn: 185366
2013-07-02 03:45:50 +08:00
case eSymbolTypeCode:
Change AddressClass type from 'enum' to 'enum class'. If we have a function with signature f(addr_t, AddressClass), it is easy to muddle up the order of arguments without any warnings from compiler. 'enum class' prevents passing integer in place of AddressClass and vice versa. llvm-svn: 335599
2018-06-26 21:06:54 +08:00
return AddressClass::eCode;
Added more platform support. There are now some new commands: platform status -- gets status information for the selected platform platform create <platform-name> -- creates a new instance of a remote platform platform list -- list all available platforms platform select -- select a platform instance as the current platform (not working yet) When using "platform create" it will create a remote platform and make it the selected platform. For instances for iPhone OS debugging on Mac OS X one can do: (lldb) platform create remote-ios --sdk-version=4.0 Remote platform: iOS platform SDK version: 4.0 SDK path: "/Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0" Not connected to a remote device. (lldb) file ~/Documents/a.out Current executable set to '~/Documents/a.out' (armv6). (lldb) image list [ 0] /Volumes/work/gclayton/Documents/devb/attach/a.out [ 1] /Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0/Symbols/usr/lib/dyld [ 2] /Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0/Symbols/usr/lib/libSystem.B.dylib Note that this is all happening prior to running _or_ connecting to a remote platform. Once connected to a remote platform the OS version might change which means we will need to update our dependecies. Also once we run, we will need to match up the actualy binaries with the actualy UUID's to files in the SDK, or download and cache them locally. This is just the start of the remote platforms, but this modification is the first iteration in getting the platforms really doing something. llvm-svn: 127934
2011-03-19 09:12:21 +08:00
case eSymbolTypeTrampoline:
Change AddressClass type from 'enum' to 'enum class'. If we have a function with signature f(addr_t, AddressClass), it is easy to muddle up the order of arguments without any warnings from compiler. 'enum class' prevents passing integer in place of AddressClass and vice versa. llvm-svn: 335599
2018-06-26 21:06:54 +08:00
return AddressClass::eCode;
Added more platform support. There are now some new commands: platform status -- gets status information for the selected platform platform create <platform-name> -- creates a new instance of a remote platform platform list -- list all available platforms platform select -- select a platform instance as the current platform (not working yet) When using "platform create" it will create a remote platform and make it the selected platform. For instances for iPhone OS debugging on Mac OS X one can do: (lldb) platform create remote-ios --sdk-version=4.0 Remote platform: iOS platform SDK version: 4.0 SDK path: "/Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0" Not connected to a remote device. (lldb) file ~/Documents/a.out Current executable set to '~/Documents/a.out' (armv6). (lldb) image list [ 0] /Volumes/work/gclayton/Documents/devb/attach/a.out [ 1] /Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0/Symbols/usr/lib/dyld [ 2] /Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0/Symbols/usr/lib/libSystem.B.dylib Note that this is all happening prior to running _or_ connecting to a remote platform. Once connected to a remote platform the OS version might change which means we will need to update our dependecies. Also once we run, we will need to match up the actualy binaries with the actualy UUID's to files in the SDK, or download and cache them locally. This is just the start of the remote platforms, but this modification is the first iteration in getting the platforms really doing something. llvm-svn: 127934
2011-03-19 09:12:21 +08:00
case eSymbolTypeResolver:
Change AddressClass type from 'enum' to 'enum class'. If we have a function with signature f(addr_t, AddressClass), it is easy to muddle up the order of arguments without any warnings from compiler. 'enum class' prevents passing integer in place of AddressClass and vice versa. llvm-svn: 335599
2018-06-26 21:06:54 +08:00
return AddressClass::eCode;
Added more platform support. There are now some new commands: platform status -- gets status information for the selected platform platform create <platform-name> -- creates a new instance of a remote platform platform list -- list all available platforms platform select -- select a platform instance as the current platform (not working yet) When using "platform create" it will create a remote platform and make it the selected platform. For instances for iPhone OS debugging on Mac OS X one can do: (lldb) platform create remote-ios --sdk-version=4.0 Remote platform: iOS platform SDK version: 4.0 SDK path: "/Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0" Not connected to a remote device. (lldb) file ~/Documents/a.out Current executable set to '~/Documents/a.out' (armv6). (lldb) image list [ 0] /Volumes/work/gclayton/Documents/devb/attach/a.out [ 1] /Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0/Symbols/usr/lib/dyld [ 2] /Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0/Symbols/usr/lib/libSystem.B.dylib Note that this is all happening prior to running _or_ connecting to a remote platform. Once connected to a remote platform the OS version might change which means we will need to update our dependecies. Also once we run, we will need to match up the actualy binaries with the actualy UUID's to files in the SDK, or download and cache them locally. This is just the start of the remote platforms, but this modification is the first iteration in getting the platforms really doing something. llvm-svn: 127934
2011-03-19 09:12:21 +08:00
case eSymbolTypeData:
Change AddressClass type from 'enum' to 'enum class'. If we have a function with signature f(addr_t, AddressClass), it is easy to muddle up the order of arguments without any warnings from compiler. 'enum class' prevents passing integer in place of AddressClass and vice versa. llvm-svn: 335599
2018-06-26 21:06:54 +08:00
return AddressClass::eData;
Added new symbol types for Objective C classes, metaclasses, and ivars. Each object file can correctly make these symbols which will abstract us from the file format and ABI and we can then ask for the objective C class symbol for a class and find out which object file it was defined in. llvm-svn: 145744
2011-12-03 10:30:59 +08:00
case eSymbolTypeRuntime:
Change AddressClass type from 'enum' to 'enum class'. If we have a function with signature f(addr_t, AddressClass), it is easy to muddle up the order of arguments without any warnings from compiler. 'enum class' prevents passing integer in place of AddressClass and vice versa. llvm-svn: 335599
2018-06-26 21:06:54 +08:00
return AddressClass::eRuntime;
Split symbol support for ELF and Linux. llvm-svn: 185366
2013-07-02 03:45:50 +08:00
case eSymbolTypeException:
Change AddressClass type from 'enum' to 'enum class'. If we have a function with signature f(addr_t, AddressClass), it is easy to muddle up the order of arguments without any warnings from compiler. 'enum class' prevents passing integer in place of AddressClass and vice versa. llvm-svn: 335599
2018-06-26 21:06:54 +08:00
return AddressClass::eRuntime;
Added more platform support. There are now some new commands: platform status -- gets status information for the selected platform platform create <platform-name> -- creates a new instance of a remote platform platform list -- list all available platforms platform select -- select a platform instance as the current platform (not working yet) When using "platform create" it will create a remote platform and make it the selected platform. For instances for iPhone OS debugging on Mac OS X one can do: (lldb) platform create remote-ios --sdk-version=4.0 Remote platform: iOS platform SDK version: 4.0 SDK path: "/Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0" Not connected to a remote device. (lldb) file ~/Documents/a.out Current executable set to '~/Documents/a.out' (armv6). (lldb) image list [ 0] /Volumes/work/gclayton/Documents/devb/attach/a.out [ 1] /Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0/Symbols/usr/lib/dyld [ 2] /Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0/Symbols/usr/lib/libSystem.B.dylib Note that this is all happening prior to running _or_ connecting to a remote platform. Once connected to a remote platform the OS version might change which means we will need to update our dependecies. Also once we run, we will need to match up the actualy binaries with the actualy UUID's to files in the SDK, or download and cache them locally. This is just the start of the remote platforms, but this modification is the first iteration in getting the platforms really doing something. llvm-svn: 127934
2011-03-19 09:12:21 +08:00
case eSymbolTypeSourceFile:
Change AddressClass type from 'enum' to 'enum class'. If we have a function with signature f(addr_t, AddressClass), it is easy to muddle up the order of arguments without any warnings from compiler. 'enum class' prevents passing integer in place of AddressClass and vice versa. llvm-svn: 335599
2018-06-26 21:06:54 +08:00
return AddressClass::eDebug;
Added more platform support. There are now some new commands: platform status -- gets status information for the selected platform platform create <platform-name> -- creates a new instance of a remote platform platform list -- list all available platforms platform select -- select a platform instance as the current platform (not working yet) When using "platform create" it will create a remote platform and make it the selected platform. For instances for iPhone OS debugging on Mac OS X one can do: (lldb) platform create remote-ios --sdk-version=4.0 Remote platform: iOS platform SDK version: 4.0 SDK path: "/Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0" Not connected to a remote device. (lldb) file ~/Documents/a.out Current executable set to '~/Documents/a.out' (armv6). (lldb) image list [ 0] /Volumes/work/gclayton/Documents/devb/attach/a.out [ 1] /Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0/Symbols/usr/lib/dyld [ 2] /Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0/Symbols/usr/lib/libSystem.B.dylib Note that this is all happening prior to running _or_ connecting to a remote platform. Once connected to a remote platform the OS version might change which means we will need to update our dependecies. Also once we run, we will need to match up the actualy binaries with the actualy UUID's to files in the SDK, or download and cache them locally. This is just the start of the remote platforms, but this modification is the first iteration in getting the platforms really doing something. llvm-svn: 127934
2011-03-19 09:12:21 +08:00
case eSymbolTypeHeaderFile:
Change AddressClass type from 'enum' to 'enum class'. If we have a function with signature f(addr_t, AddressClass), it is easy to muddle up the order of arguments without any warnings from compiler. 'enum class' prevents passing integer in place of AddressClass and vice versa. llvm-svn: 335599
2018-06-26 21:06:54 +08:00
return AddressClass::eDebug;
Added more platform support. There are now some new commands: platform status -- gets status information for the selected platform platform create <platform-name> -- creates a new instance of a remote platform platform list -- list all available platforms platform select -- select a platform instance as the current platform (not working yet) When using "platform create" it will create a remote platform and make it the selected platform. For instances for iPhone OS debugging on Mac OS X one can do: (lldb) platform create remote-ios --sdk-version=4.0 Remote platform: iOS platform SDK version: 4.0 SDK path: "/Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0" Not connected to a remote device. (lldb) file ~/Documents/a.out Current executable set to '~/Documents/a.out' (armv6). (lldb) image list [ 0] /Volumes/work/gclayton/Documents/devb/attach/a.out [ 1] /Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0/Symbols/usr/lib/dyld [ 2] /Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0/Symbols/usr/lib/libSystem.B.dylib Note that this is all happening prior to running _or_ connecting to a remote platform. Once connected to a remote platform the OS version might change which means we will need to update our dependecies. Also once we run, we will need to match up the actualy binaries with the actualy UUID's to files in the SDK, or download and cache them locally. This is just the start of the remote platforms, but this modification is the first iteration in getting the platforms really doing something. llvm-svn: 127934
2011-03-19 09:12:21 +08:00
case eSymbolTypeObjectFile:
Change AddressClass type from 'enum' to 'enum class'. If we have a function with signature f(addr_t, AddressClass), it is easy to muddle up the order of arguments without any warnings from compiler. 'enum class' prevents passing integer in place of AddressClass and vice versa. llvm-svn: 335599
2018-06-26 21:06:54 +08:00
return AddressClass::eDebug;
Added more platform support. There are now some new commands: platform status -- gets status information for the selected platform platform create <platform-name> -- creates a new instance of a remote platform platform list -- list all available platforms platform select -- select a platform instance as the current platform (not working yet) When using "platform create" it will create a remote platform and make it the selected platform. For instances for iPhone OS debugging on Mac OS X one can do: (lldb) platform create remote-ios --sdk-version=4.0 Remote platform: iOS platform SDK version: 4.0 SDK path: "/Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0" Not connected to a remote device. (lldb) file ~/Documents/a.out Current executable set to '~/Documents/a.out' (armv6). (lldb) image list [ 0] /Volumes/work/gclayton/Documents/devb/attach/a.out [ 1] /Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0/Symbols/usr/lib/dyld [ 2] /Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0/Symbols/usr/lib/libSystem.B.dylib Note that this is all happening prior to running _or_ connecting to a remote platform. Once connected to a remote platform the OS version might change which means we will need to update our dependecies. Also once we run, we will need to match up the actualy binaries with the actualy UUID's to files in the SDK, or download and cache them locally. This is just the start of the remote platforms, but this modification is the first iteration in getting the platforms really doing something. llvm-svn: 127934
2011-03-19 09:12:21 +08:00
case eSymbolTypeCommonBlock:
Change AddressClass type from 'enum' to 'enum class'. If we have a function with signature f(addr_t, AddressClass), it is easy to muddle up the order of arguments without any warnings from compiler. 'enum class' prevents passing integer in place of AddressClass and vice versa. llvm-svn: 335599
2018-06-26 21:06:54 +08:00
return AddressClass::eDebug;
Added more platform support. There are now some new commands: platform status -- gets status information for the selected platform platform create <platform-name> -- creates a new instance of a remote platform platform list -- list all available platforms platform select -- select a platform instance as the current platform (not working yet) When using "platform create" it will create a remote platform and make it the selected platform. For instances for iPhone OS debugging on Mac OS X one can do: (lldb) platform create remote-ios --sdk-version=4.0 Remote platform: iOS platform SDK version: 4.0 SDK path: "/Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0" Not connected to a remote device. (lldb) file ~/Documents/a.out Current executable set to '~/Documents/a.out' (armv6). (lldb) image list [ 0] /Volumes/work/gclayton/Documents/devb/attach/a.out [ 1] /Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0/Symbols/usr/lib/dyld [ 2] /Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0/Symbols/usr/lib/libSystem.B.dylib Note that this is all happening prior to running _or_ connecting to a remote platform. Once connected to a remote platform the OS version might change which means we will need to update our dependecies. Also once we run, we will need to match up the actualy binaries with the actualy UUID's to files in the SDK, or download and cache them locally. This is just the start of the remote platforms, but this modification is the first iteration in getting the platforms really doing something. llvm-svn: 127934
2011-03-19 09:12:21 +08:00
case eSymbolTypeBlock:
Change AddressClass type from 'enum' to 'enum class'. If we have a function with signature f(addr_t, AddressClass), it is easy to muddle up the order of arguments without any warnings from compiler. 'enum class' prevents passing integer in place of AddressClass and vice versa. llvm-svn: 335599
2018-06-26 21:06:54 +08:00
return AddressClass::eDebug;
Added more platform support. There are now some new commands: platform status -- gets status information for the selected platform platform create <platform-name> -- creates a new instance of a remote platform platform list -- list all available platforms platform select -- select a platform instance as the current platform (not working yet) When using "platform create" it will create a remote platform and make it the selected platform. For instances for iPhone OS debugging on Mac OS X one can do: (lldb) platform create remote-ios --sdk-version=4.0 Remote platform: iOS platform SDK version: 4.0 SDK path: "/Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0" Not connected to a remote device. (lldb) file ~/Documents/a.out Current executable set to '~/Documents/a.out' (armv6). (lldb) image list [ 0] /Volumes/work/gclayton/Documents/devb/attach/a.out [ 1] /Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0/Symbols/usr/lib/dyld [ 2] /Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0/Symbols/usr/lib/libSystem.B.dylib Note that this is all happening prior to running _or_ connecting to a remote platform. Once connected to a remote platform the OS version might change which means we will need to update our dependecies. Also once we run, we will need to match up the actualy binaries with the actualy UUID's to files in the SDK, or download and cache them locally. This is just the start of the remote platforms, but this modification is the first iteration in getting the platforms really doing something. llvm-svn: 127934
2011-03-19 09:12:21 +08:00
case eSymbolTypeLocal:
Change AddressClass type from 'enum' to 'enum class'. If we have a function with signature f(addr_t, AddressClass), it is easy to muddle up the order of arguments without any warnings from compiler. 'enum class' prevents passing integer in place of AddressClass and vice versa. llvm-svn: 335599
2018-06-26 21:06:54 +08:00
return AddressClass::eData;
Added more platform support. There are now some new commands: platform status -- gets status information for the selected platform platform create <platform-name> -- creates a new instance of a remote platform platform list -- list all available platforms platform select -- select a platform instance as the current platform (not working yet) When using "platform create" it will create a remote platform and make it the selected platform. For instances for iPhone OS debugging on Mac OS X one can do: (lldb) platform create remote-ios --sdk-version=4.0 Remote platform: iOS platform SDK version: 4.0 SDK path: "/Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0" Not connected to a remote device. (lldb) file ~/Documents/a.out Current executable set to '~/Documents/a.out' (armv6). (lldb) image list [ 0] /Volumes/work/gclayton/Documents/devb/attach/a.out [ 1] /Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0/Symbols/usr/lib/dyld [ 2] /Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0/Symbols/usr/lib/libSystem.B.dylib Note that this is all happening prior to running _or_ connecting to a remote platform. Once connected to a remote platform the OS version might change which means we will need to update our dependecies. Also once we run, we will need to match up the actualy binaries with the actualy UUID's to files in the SDK, or download and cache them locally. This is just the start of the remote platforms, but this modification is the first iteration in getting the platforms really doing something. llvm-svn: 127934
2011-03-19 09:12:21 +08:00
case eSymbolTypeParam:
Change AddressClass type from 'enum' to 'enum class'. If we have a function with signature f(addr_t, AddressClass), it is easy to muddle up the order of arguments without any warnings from compiler. 'enum class' prevents passing integer in place of AddressClass and vice versa. llvm-svn: 335599
2018-06-26 21:06:54 +08:00
return AddressClass::eData;
Split symbol support for ELF and Linux. llvm-svn: 185366
2013-07-02 03:45:50 +08:00
case eSymbolTypeVariable:
Change AddressClass type from 'enum' to 'enum class'. If we have a function with signature f(addr_t, AddressClass), it is easy to muddle up the order of arguments without any warnings from compiler. 'enum class' prevents passing integer in place of AddressClass and vice versa. llvm-svn: 335599
2018-06-26 21:06:54 +08:00
return AddressClass::eData;
Split symbol support for ELF and Linux. llvm-svn: 185366
2013-07-02 03:45:50 +08:00
case eSymbolTypeVariableType:
Change AddressClass type from 'enum' to 'enum class'. If we have a function with signature f(addr_t, AddressClass), it is easy to muddle up the order of arguments without any warnings from compiler. 'enum class' prevents passing integer in place of AddressClass and vice versa. llvm-svn: 335599
2018-06-26 21:06:54 +08:00
return AddressClass::eDebug;
Added more platform support. There are now some new commands: platform status -- gets status information for the selected platform platform create <platform-name> -- creates a new instance of a remote platform platform list -- list all available platforms platform select -- select a platform instance as the current platform (not working yet) When using "platform create" it will create a remote platform and make it the selected platform. For instances for iPhone OS debugging on Mac OS X one can do: (lldb) platform create remote-ios --sdk-version=4.0 Remote platform: iOS platform SDK version: 4.0 SDK path: "/Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0" Not connected to a remote device. (lldb) file ~/Documents/a.out Current executable set to '~/Documents/a.out' (armv6). (lldb) image list [ 0] /Volumes/work/gclayton/Documents/devb/attach/a.out [ 1] /Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0/Symbols/usr/lib/dyld [ 2] /Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0/Symbols/usr/lib/libSystem.B.dylib Note that this is all happening prior to running _or_ connecting to a remote platform. Once connected to a remote platform the OS version might change which means we will need to update our dependecies. Also once we run, we will need to match up the actualy binaries with the actualy UUID's to files in the SDK, or download and cache them locally. This is just the start of the remote platforms, but this modification is the first iteration in getting the platforms really doing something. llvm-svn: 127934
2011-03-19 09:12:21 +08:00
case eSymbolTypeLineEntry:
Change AddressClass type from 'enum' to 'enum class'. If we have a function with signature f(addr_t, AddressClass), it is easy to muddle up the order of arguments without any warnings from compiler. 'enum class' prevents passing integer in place of AddressClass and vice versa. llvm-svn: 335599
2018-06-26 21:06:54 +08:00
return AddressClass::eDebug;
Added more platform support. There are now some new commands: platform status -- gets status information for the selected platform platform create <platform-name> -- creates a new instance of a remote platform platform list -- list all available platforms platform select -- select a platform instance as the current platform (not working yet) When using "platform create" it will create a remote platform and make it the selected platform. For instances for iPhone OS debugging on Mac OS X one can do: (lldb) platform create remote-ios --sdk-version=4.0 Remote platform: iOS platform SDK version: 4.0 SDK path: "/Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0" Not connected to a remote device. (lldb) file ~/Documents/a.out Current executable set to '~/Documents/a.out' (armv6). (lldb) image list [ 0] /Volumes/work/gclayton/Documents/devb/attach/a.out [ 1] /Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0/Symbols/usr/lib/dyld [ 2] /Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0/Symbols/usr/lib/libSystem.B.dylib Note that this is all happening prior to running _or_ connecting to a remote platform. Once connected to a remote platform the OS version might change which means we will need to update our dependecies. Also once we run, we will need to match up the actualy binaries with the actualy UUID's to files in the SDK, or download and cache them locally. This is just the start of the remote platforms, but this modification is the first iteration in getting the platforms really doing something. llvm-svn: 127934
2011-03-19 09:12:21 +08:00
case eSymbolTypeLineHeader:
Change AddressClass type from 'enum' to 'enum class'. If we have a function with signature f(addr_t, AddressClass), it is easy to muddle up the order of arguments without any warnings from compiler. 'enum class' prevents passing integer in place of AddressClass and vice versa. llvm-svn: 335599
2018-06-26 21:06:54 +08:00
return AddressClass::eDebug;
Added more platform support. There are now some new commands: platform status -- gets status information for the selected platform platform create <platform-name> -- creates a new instance of a remote platform platform list -- list all available platforms platform select -- select a platform instance as the current platform (not working yet) When using "platform create" it will create a remote platform and make it the selected platform. For instances for iPhone OS debugging on Mac OS X one can do: (lldb) platform create remote-ios --sdk-version=4.0 Remote platform: iOS platform SDK version: 4.0 SDK path: "/Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0" Not connected to a remote device. (lldb) file ~/Documents/a.out Current executable set to '~/Documents/a.out' (armv6). (lldb) image list [ 0] /Volumes/work/gclayton/Documents/devb/attach/a.out [ 1] /Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0/Symbols/usr/lib/dyld [ 2] /Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0/Symbols/usr/lib/libSystem.B.dylib Note that this is all happening prior to running _or_ connecting to a remote platform. Once connected to a remote platform the OS version might change which means we will need to update our dependecies. Also once we run, we will need to match up the actualy binaries with the actualy UUID's to files in the SDK, or download and cache them locally. This is just the start of the remote platforms, but this modification is the first iteration in getting the platforms really doing something. llvm-svn: 127934
2011-03-19 09:12:21 +08:00
case eSymbolTypeScopeBegin:
Change AddressClass type from 'enum' to 'enum class'. If we have a function with signature f(addr_t, AddressClass), it is easy to muddle up the order of arguments without any warnings from compiler. 'enum class' prevents passing integer in place of AddressClass and vice versa. llvm-svn: 335599
2018-06-26 21:06:54 +08:00
return AddressClass::eDebug;
Added new symbol types for Objective C classes, metaclasses, and ivars. Each object file can correctly make these symbols which will abstract us from the file format and ABI and we can then ask for the objective C class symbol for a class and find out which object file it was defined in. llvm-svn: 145744
2011-12-03 10:30:59 +08:00
case eSymbolTypeScopeEnd:
Change AddressClass type from 'enum' to 'enum class'. If we have a function with signature f(addr_t, AddressClass), it is easy to muddle up the order of arguments without any warnings from compiler. 'enum class' prevents passing integer in place of AddressClass and vice versa. llvm-svn: 335599
2018-06-26 21:06:54 +08:00
return AddressClass::eDebug;
Added new symbol types for Objective C classes, metaclasses, and ivars. Each object file can correctly make these symbols which will abstract us from the file format and ABI and we can then ask for the objective C class symbol for a class and find out which object file it was defined in. llvm-svn: 145744
2011-12-03 10:30:59 +08:00
case eSymbolTypeAdditional:
Change AddressClass type from 'enum' to 'enum class'. If we have a function with signature f(addr_t, AddressClass), it is easy to muddle up the order of arguments without any warnings from compiler. 'enum class' prevents passing integer in place of AddressClass and vice versa. llvm-svn: 335599
2018-06-26 21:06:54 +08:00
return AddressClass::eUnknown;
Added more platform support. There are now some new commands: platform status -- gets status information for the selected platform platform create <platform-name> -- creates a new instance of a remote platform platform list -- list all available platforms platform select -- select a platform instance as the current platform (not working yet) When using "platform create" it will create a remote platform and make it the selected platform. For instances for iPhone OS debugging on Mac OS X one can do: (lldb) platform create remote-ios --sdk-version=4.0 Remote platform: iOS platform SDK version: 4.0 SDK path: "/Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0" Not connected to a remote device. (lldb) file ~/Documents/a.out Current executable set to '~/Documents/a.out' (armv6). (lldb) image list [ 0] /Volumes/work/gclayton/Documents/devb/attach/a.out [ 1] /Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0/Symbols/usr/lib/dyld [ 2] /Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0/Symbols/usr/lib/libSystem.B.dylib Note that this is all happening prior to running _or_ connecting to a remote platform. Once connected to a remote platform the OS version might change which means we will need to update our dependecies. Also once we run, we will need to match up the actualy binaries with the actualy UUID's to files in the SDK, or download and cache them locally. This is just the start of the remote platforms, but this modification is the first iteration in getting the platforms really doing something. llvm-svn: 127934
2011-03-19 09:12:21 +08:00
case eSymbolTypeCompiler:
Change AddressClass type from 'enum' to 'enum class'. If we have a function with signature f(addr_t, AddressClass), it is easy to muddle up the order of arguments without any warnings from compiler. 'enum class' prevents passing integer in place of AddressClass and vice versa. llvm-svn: 335599
2018-06-26 21:06:54 +08:00
return AddressClass::eDebug;
Split symbol support for ELF and Linux. llvm-svn: 185366
2013-07-02 03:45:50 +08:00
case eSymbolTypeInstrumentation:
Change AddressClass type from 'enum' to 'enum class'. If we have a function with signature f(addr_t, AddressClass), it is easy to muddle up the order of arguments without any warnings from compiler. 'enum class' prevents passing integer in place of AddressClass and vice versa. llvm-svn: 335599
2018-06-26 21:06:54 +08:00
return AddressClass::eDebug;
Added more platform support. There are now some new commands: platform status -- gets status information for the selected platform platform create <platform-name> -- creates a new instance of a remote platform platform list -- list all available platforms platform select -- select a platform instance as the current platform (not working yet) When using "platform create" it will create a remote platform and make it the selected platform. For instances for iPhone OS debugging on Mac OS X one can do: (lldb) platform create remote-ios --sdk-version=4.0 Remote platform: iOS platform SDK version: 4.0 SDK path: "/Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0" Not connected to a remote device. (lldb) file ~/Documents/a.out Current executable set to '~/Documents/a.out' (armv6). (lldb) image list [ 0] /Volumes/work/gclayton/Documents/devb/attach/a.out [ 1] /Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0/Symbols/usr/lib/dyld [ 2] /Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0/Symbols/usr/lib/libSystem.B.dylib Note that this is all happening prior to running _or_ connecting to a remote platform. Once connected to a remote platform the OS version might change which means we will need to update our dependecies. Also once we run, we will need to match up the actualy binaries with the actualy UUID's to files in the SDK, or download and cache them locally. This is just the start of the remote platforms, but this modification is the first iteration in getting the platforms really doing something. llvm-svn: 127934
2011-03-19 09:12:21 +08:00
case eSymbolTypeUndefined:
Change AddressClass type from 'enum' to 'enum class'. If we have a function with signature f(addr_t, AddressClass), it is easy to muddle up the order of arguments without any warnings from compiler. 'enum class' prevents passing integer in place of AddressClass and vice versa. llvm-svn: 335599
2018-06-26 21:06:54 +08:00
return AddressClass::eUnknown;
Added new symbol types for Objective C classes, metaclasses, and ivars. Each object file can correctly make these symbols which will abstract us from the file format and ABI and we can then ask for the objective C class symbol for a class and find out which object file it was defined in. llvm-svn: 145744
2011-12-03 10:30:59 +08:00
case eSymbolTypeObjCClass:
Change AddressClass type from 'enum' to 'enum class'. If we have a function with signature f(addr_t, AddressClass), it is easy to muddle up the order of arguments without any warnings from compiler. 'enum class' prevents passing integer in place of AddressClass and vice versa. llvm-svn: 335599
2018-06-26 21:06:54 +08:00
return AddressClass::eRuntime;
Added new symbol types for Objective C classes, metaclasses, and ivars. Each object file can correctly make these symbols which will abstract us from the file format and ABI and we can then ask for the objective C class symbol for a class and find out which object file it was defined in. llvm-svn: 145744
2011-12-03 10:30:59 +08:00
case eSymbolTypeObjCMetaClass:
Change AddressClass type from 'enum' to 'enum class'. If we have a function with signature f(addr_t, AddressClass), it is easy to muddle up the order of arguments without any warnings from compiler. 'enum class' prevents passing integer in place of AddressClass and vice versa. llvm-svn: 335599
2018-06-26 21:06:54 +08:00
return AddressClass::eRuntime;
Added new symbol types for Objective C classes, metaclasses, and ivars. Each object file can correctly make these symbols which will abstract us from the file format and ABI and we can then ask for the objective C class symbol for a class and find out which object file it was defined in. llvm-svn: 145744
2011-12-03 10:30:59 +08:00
case eSymbolTypeObjCIVar:
Change AddressClass type from 'enum' to 'enum class'. If we have a function with signature f(addr_t, AddressClass), it is easy to muddle up the order of arguments without any warnings from compiler. 'enum class' prevents passing integer in place of AddressClass and vice versa. llvm-svn: 335599
2018-06-26 21:06:54 +08:00
return AddressClass::eRuntime;
Added more platform support. There are now some new commands: platform status -- gets status information for the selected platform platform create <platform-name> -- creates a new instance of a remote platform platform list -- list all available platforms platform select -- select a platform instance as the current platform (not working yet) When using "platform create" it will create a remote platform and make it the selected platform. For instances for iPhone OS debugging on Mac OS X one can do: (lldb) platform create remote-ios --sdk-version=4.0 Remote platform: iOS platform SDK version: 4.0 SDK path: "/Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0" Not connected to a remote device. (lldb) file ~/Documents/a.out Current executable set to '~/Documents/a.out' (armv6). (lldb) image list [ 0] /Volumes/work/gclayton/Documents/devb/attach/a.out [ 1] /Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0/Symbols/usr/lib/dyld [ 2] /Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0/Symbols/usr/lib/libSystem.B.dylib Note that this is all happening prior to running _or_ connecting to a remote platform. Once connected to a remote platform the OS version might change which means we will need to update our dependecies. Also once we run, we will need to match up the actualy binaries with the actualy UUID's to files in the SDK, or download and cache them locally. This is just the start of the remote platforms, but this modification is the first iteration in getting the platforms really doing something. llvm-svn: 127934
2011-03-19 09:12:21 +08:00
case eSymbolTypeReExported:
Change AddressClass type from 'enum' to 'enum class'. If we have a function with signature f(addr_t, AddressClass), it is easy to muddle up the order of arguments without any warnings from compiler. 'enum class' prevents passing integer in place of AddressClass and vice versa. llvm-svn: 335599
2018-06-26 21:06:54 +08:00
return AddressClass::eRuntime;
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
}
Added more platform support. There are now some new commands: platform status -- gets status information for the selected platform platform create <platform-name> -- creates a new instance of a remote platform platform list -- list all available platforms platform select -- select a platform instance as the current platform (not working yet) When using "platform create" it will create a remote platform and make it the selected platform. For instances for iPhone OS debugging on Mac OS X one can do: (lldb) platform create remote-ios --sdk-version=4.0 Remote platform: iOS platform SDK version: 4.0 SDK path: "/Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0" Not connected to a remote device. (lldb) file ~/Documents/a.out Current executable set to '~/Documents/a.out' (armv6). (lldb) image list [ 0] /Volumes/work/gclayton/Documents/devb/attach/a.out [ 1] /Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0/Symbols/usr/lib/dyld [ 2] /Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0/Symbols/usr/lib/libSystem.B.dylib Note that this is all happening prior to running _or_ connecting to a remote platform. Once connected to a remote platform the OS version might change which means we will need to update our dependecies. Also once we run, we will need to match up the actualy binaries with the actualy UUID's to files in the SDK, or download and cache them locally. This is just the start of the remote platforms, but this modification is the first iteration in getting the platforms really doing something. llvm-svn: 127934
2011-03-19 09:12:21 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
}
Change AddressClass type from 'enum' to 'enum class'. If we have a function with signature f(addr_t, AddressClass), it is easy to muddle up the order of arguments without any warnings from compiler. 'enum class' prevents passing integer in place of AddressClass and vice versa. llvm-svn: 335599
2018-06-26 21:06:54 +08:00
return AddressClass::eUnknown;
Added more platform support. There are now some new commands: platform status -- gets status information for the selected platform platform create <platform-name> -- creates a new instance of a remote platform platform list -- list all available platforms platform select -- select a platform instance as the current platform (not working yet) When using "platform create" it will create a remote platform and make it the selected platform. For instances for iPhone OS debugging on Mac OS X one can do: (lldb) platform create remote-ios --sdk-version=4.0 Remote platform: iOS platform SDK version: 4.0 SDK path: "/Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0" Not connected to a remote device. (lldb) file ~/Documents/a.out Current executable set to '~/Documents/a.out' (armv6). (lldb) image list [ 0] /Volumes/work/gclayton/Documents/devb/attach/a.out [ 1] /Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0/Symbols/usr/lib/dyld [ 2] /Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0/Symbols/usr/lib/libSystem.B.dylib Note that this is all happening prior to running _or_ connecting to a remote platform. Once connected to a remote platform the OS version might change which means we will need to update our dependecies. Also once we run, we will need to match up the actualy binaries with the actualy UUID's to files in the SDK, or download and cache them locally. This is just the start of the remote platforms, but this modification is the first iteration in getting the platforms really doing something. llvm-svn: 127934
2011-03-19 09:12:21 +08:00
}
<rdar://problem/10560053> Fixed "target modules list" (aliased to "image list") to output more information by default. Modified the "target modules list" to have a few new options: "--header" or "-h" => show the image header address "--offset" or "-o" => show the image header address offset from the address in the file (the slide applied to the shared library) Removed the "--symfile-basename" or "-S" option, and repurposed it to "--symfile-unique" "-S" which will show the symbol file if it differs from the executable file. ObjectFile's can now be loaded from memory for cases where we don't have the files cached locally in an SDK or net mounted root. ObjectFileMachO can now read mach files from memory. Moved the section data reading code into the ObjectFile so that the object file can get the section data from Process memory if the file is only in memory. lldb_private::Module can now load its object file in a target with a rigid slide (very common operation for most dynamic linkers) by using: bool Module::SetLoadAddress (Target &target, lldb::addr_t offset, bool &changed) lldb::SBModule() now has a new constructor in the public interface: SBModule::SBModule (lldb::SBProcess &process, lldb::addr_t header_addr); This will find an appropriate ObjectFile plug-in to load an image from memory where the object file header is at "header_addr". llvm-svn: 149804
2012-02-05 10:38:54 +08:00
DataBufferSP ObjectFile::ReadMemory(const ProcessSP &process_sp,
lldb::addr_t addr, size_t byte_size) {
DataBufferSP data_sp;
if (process_sp) {
Replace 'ap' with 'up' suffix in variable names. (NFC) The `ap` suffix is a remnant of lldb's former use of auto pointers, before they got deprecated. Although all their uses were replaced by unique pointers, some variables still carried the suffix. In r353795 I removed another auto_ptr remnant, namely redundant calls to ::get for unique_pointers. Jim justly noted that this is a good opportunity to clean up the variable names as well. I went over all the changes to ensure my find-and-replace didn't have any undesired side-effects. I hope I didn't miss any, but if you end up at this commit doing a git blame on a weirdly named variable, please know that the change was unintentional. llvm-svn: 353912
2019-02-13 14:25:41 +08:00
std::unique_ptr<DataBufferHeap> data_up(new DataBufferHeap(byte_size, 0));
Rename Error -> Status. This renames the LLDB error class to Status, as discussed on the lldb-dev mailing list. A change of this magnitude cannot easily be done without find and replace, but that has potential to catch unwanted occurrences of common strings such as "Error". Every effort was made to find all the obvious things such as the word "Error" appearing in a string, etc, but it's possible there are still some lingering occurences left around. Hopefully nothing too serious. llvm-svn: 302872
2017-05-12 12:51:55 +08:00
Status error;
<rdar://problem/10560053> Fixed "target modules list" (aliased to "image list") to output more information by default. Modified the "target modules list" to have a few new options: "--header" or "-h" => show the image header address "--offset" or "-o" => show the image header address offset from the address in the file (the slide applied to the shared library) Removed the "--symfile-basename" or "-S" option, and repurposed it to "--symfile-unique" "-S" which will show the symbol file if it differs from the executable file. ObjectFile's can now be loaded from memory for cases where we don't have the files cached locally in an SDK or net mounted root. ObjectFileMachO can now read mach files from memory. Moved the section data reading code into the ObjectFile so that the object file can get the section data from Process memory if the file is only in memory. lldb_private::Module can now load its object file in a target with a rigid slide (very common operation for most dynamic linkers) by using: bool Module::SetLoadAddress (Target &target, lldb::addr_t offset, bool &changed) lldb::SBModule() now has a new constructor in the public interface: SBModule::SBModule (lldb::SBProcess &process, lldb::addr_t header_addr); This will find an appropriate ObjectFile plug-in to load an image from memory where the object file header is at "header_addr". llvm-svn: 149804
2012-02-05 10:38:54 +08:00
const size_t bytes_read = process_sp->ReadMemory(
Replace 'ap' with 'up' suffix in variable names. (NFC) The `ap` suffix is a remnant of lldb's former use of auto pointers, before they got deprecated. Although all their uses were replaced by unique pointers, some variables still carried the suffix. In r353795 I removed another auto_ptr remnant, namely redundant calls to ::get for unique_pointers. Jim justly noted that this is a good opportunity to clean up the variable names as well. I went over all the changes to ensure my find-and-replace didn't have any undesired side-effects. I hope I didn't miss any, but if you end up at this commit doing a git blame on a weirdly named variable, please know that the change was unintentional. llvm-svn: 353912
2019-02-13 14:25:41 +08:00
addr, data_up->GetBytes(), data_up->GetByteSize(), error);
<rdar://problem/10560053> Fixed "target modules list" (aliased to "image list") to output more information by default. Modified the "target modules list" to have a few new options: "--header" or "-h" => show the image header address "--offset" or "-o" => show the image header address offset from the address in the file (the slide applied to the shared library) Removed the "--symfile-basename" or "-S" option, and repurposed it to "--symfile-unique" "-S" which will show the symbol file if it differs from the executable file. ObjectFile's can now be loaded from memory for cases where we don't have the files cached locally in an SDK or net mounted root. ObjectFileMachO can now read mach files from memory. Moved the section data reading code into the ObjectFile so that the object file can get the section data from Process memory if the file is only in memory. lldb_private::Module can now load its object file in a target with a rigid slide (very common operation for most dynamic linkers) by using: bool Module::SetLoadAddress (Target &target, lldb::addr_t offset, bool &changed) lldb::SBModule() now has a new constructor in the public interface: SBModule::SBModule (lldb::SBProcess &process, lldb::addr_t header_addr); This will find an appropriate ObjectFile plug-in to load an image from memory where the object file header is at "header_addr". llvm-svn: 149804
2012-02-05 10:38:54 +08:00
if (bytes_read == byte_size)
Replace 'ap' with 'up' suffix in variable names. (NFC) The `ap` suffix is a remnant of lldb's former use of auto pointers, before they got deprecated. Although all their uses were replaced by unique pointers, some variables still carried the suffix. In r353795 I removed another auto_ptr remnant, namely redundant calls to ::get for unique_pointers. Jim justly noted that this is a good opportunity to clean up the variable names as well. I went over all the changes to ensure my find-and-replace didn't have any undesired side-effects. I hope I didn't miss any, but if you end up at this commit doing a git blame on a weirdly named variable, please know that the change was unintentional. llvm-svn: 353912
2019-02-13 14:25:41 +08:00
data_sp.reset(data_up.release());
<rdar://problem/10560053> Fixed "target modules list" (aliased to "image list") to output more information by default. Modified the "target modules list" to have a few new options: "--header" or "-h" => show the image header address "--offset" or "-o" => show the image header address offset from the address in the file (the slide applied to the shared library) Removed the "--symfile-basename" or "-S" option, and repurposed it to "--symfile-unique" "-S" which will show the symbol file if it differs from the executable file. ObjectFile's can now be loaded from memory for cases where we don't have the files cached locally in an SDK or net mounted root. ObjectFileMachO can now read mach files from memory. Moved the section data reading code into the ObjectFile so that the object file can get the section data from Process memory if the file is only in memory. lldb_private::Module can now load its object file in a target with a rigid slide (very common operation for most dynamic linkers) by using: bool Module::SetLoadAddress (Target &target, lldb::addr_t offset, bool &changed) lldb::SBModule() now has a new constructor in the public interface: SBModule::SBModule (lldb::SBProcess &process, lldb::addr_t header_addr); This will find an appropriate ObjectFile plug-in to load an image from memory where the object file header is at "header_addr". llvm-svn: 149804
2012-02-05 10:38:54 +08:00
}
return data_sp;
}
Start converting usages of off_t to other types. off_t is a type which is used for file offsets. Even more specifically, it is only used by a limited number of C APIs that deal with files. Any usage of off_t where the variable is not intended to be used with one of these APIs is a bug, by definition. This patch corrects some easy mis-uses of off_t, generally by converting them to lldb::offset_t, but sometimes by using other types such as size_t, when appropriate. The use of off_t to represent these offsets has worked fine in practice on linux-y platforms, since we used _FILE_OFFSET_64 to guarantee that off_t was a uint64. On Windows, however, _FILE_OFFSET_64 is unrecognized, and off_t will always be 32-bit. So the usage of off_t on Windows actually leads to legitimate bugs. Reviewed by: Greg Clayton Differential Revision: http://reviews.llvm.org/D4358 llvm-svn: 212192
2014-07-03 01:24:07 +08:00
size_t ObjectFile::GetData(lldb::offset_t offset, size_t length,
DataExtractor &data) const {
Big change in the way ObjectFile file contents are managed. We now mmap() the entire object file contents into memory with MAP_PRIVATE. We do this because object file contents can change on us and currently this helps alleviate this situation. It also make the code for accessing object file data much easier to manage and we don't end up opening the file, reading some data and closing the file over and over. llvm-svn: 148017
2012-01-12 13:25:17 +08:00
// The entire file has already been mmap'ed into m_data, so just copy from
Reflow paragraphs in comments. This is intended as a clean up after the big clang-format commit (r280751), which unfortunately resulted in many of the comment paragraphs in LLDB being very hard to read. FYI, the script I used was: import textwrap import commands import os import sys import re tmp = "%s.tmp"%sys.argv[1] out = open(tmp, "w+") with open(sys.argv[1], "r") as f: header = "" text = "" comment = re.compile(r'^( *//) ([^ ].*)$') special = re.compile(r'^((([A-Z]+[: ])|([0-9]+ )).*)|(.*;)$') for line in f: match = comment.match(line) if match and not special.match(match.group(2)): # skip intentionally short comments. if not text and len(match.group(2)) < 40: out.write(line) continue if text: text += " " + match.group(2) else: header = match.group(1) text = match.group(2) continue if text: filled = textwrap.wrap(text, width=(78-len(header)), break_long_words=False) for l in filled: out.write(header+" "+l+'\n') text = "" out.write(line) os.rename(tmp, sys.argv[1]) Differential Revision: https://reviews.llvm.org/D46144 llvm-svn: 331197
2018-05-01 00:49:04 +08:00
// there as the back mmap buffer will be shared with shared pointers.
Big change in the way ObjectFile file contents are managed. We now mmap() the entire object file contents into memory with MAP_PRIVATE. We do this because object file contents can change on us and currently this helps alleviate this situation. It also make the code for accessing object file data much easier to manage and we don't end up opening the file, reading some data and closing the file over and over. llvm-svn: 148017
2012-01-12 13:25:17 +08:00
return data.SetData(m_data, offset, length);
}
Start converting usages of off_t to other types. off_t is a type which is used for file offsets. Even more specifically, it is only used by a limited number of C APIs that deal with files. Any usage of off_t where the variable is not intended to be used with one of these APIs is a bug, by definition. This patch corrects some easy mis-uses of off_t, generally by converting them to lldb::offset_t, but sometimes by using other types such as size_t, when appropriate. The use of off_t to represent these offsets has worked fine in practice on linux-y platforms, since we used _FILE_OFFSET_64 to guarantee that off_t was a uint64. On Windows, however, _FILE_OFFSET_64 is unrecognized, and off_t will always be 32-bit. So the usage of off_t on Windows actually leads to legitimate bugs. Reviewed by: Greg Clayton Differential Revision: http://reviews.llvm.org/D4358 llvm-svn: 212192
2014-07-03 01:24:07 +08:00
size_t ObjectFile::CopyData(lldb::offset_t offset, size_t length,
void *dst) const {
Big change in the way ObjectFile file contents are managed. We now mmap() the entire object file contents into memory with MAP_PRIVATE. We do this because object file contents can change on us and currently this helps alleviate this situation. It also make the code for accessing object file data much easier to manage and we don't end up opening the file, reading some data and closing the file over and over. llvm-svn: 148017
2012-01-12 13:25:17 +08:00
// The entire file has already been mmap'ed into m_data, so just copy from
Reflow paragraphs in comments. This is intended as a clean up after the big clang-format commit (r280751), which unfortunately resulted in many of the comment paragraphs in LLDB being very hard to read. FYI, the script I used was: import textwrap import commands import os import sys import re tmp = "%s.tmp"%sys.argv[1] out = open(tmp, "w+") with open(sys.argv[1], "r") as f: header = "" text = "" comment = re.compile(r'^( *//) ([^ ].*)$') special = re.compile(r'^((([A-Z]+[: ])|([0-9]+ )).*)|(.*;)$') for line in f: match = comment.match(line) if match and not special.match(match.group(2)): # skip intentionally short comments. if not text and len(match.group(2)) < 40: out.write(line) continue if text: text += " " + match.group(2) else: header = match.group(1) text = match.group(2) continue if text: filled = textwrap.wrap(text, width=(78-len(header)), break_long_words=False) for l in filled: out.write(header+" "+l+'\n') text = "" out.write(line) os.rename(tmp, sys.argv[1]) Differential Revision: https://reviews.llvm.org/D46144 llvm-svn: 331197
2018-05-01 00:49:04 +08:00
// there Note that the data remains in target byte order.
Fix endianness in ObjectFile::CopyData ObjectFile::CopyData is used to copy a block of target memory to the caller's buffer (e.g. for "memory read"). This should be a straight memcpy, and not byte-swapped if the target and host have different endianness. Add a new DataExtractor::CopyData() method that performs this straight copy and use it in ObjectFile::CopyData(). llvm-svn: 192323
2013-10-10 04:34:25 +08:00
return m_data.CopyData(offset, length, dst);
Big change in the way ObjectFile file contents are managed. We now mmap() the entire object file contents into memory with MAP_PRIVATE. We do this because object file contents can change on us and currently this helps alleviate this situation. It also make the code for accessing object file data much easier to manage and we don't end up opening the file, reading some data and closing the file over and over. llvm-svn: 148017
2012-01-12 13:25:17 +08:00
}
Added more platform support. There are now some new commands: platform status -- gets status information for the selected platform platform create <platform-name> -- creates a new instance of a remote platform platform list -- list all available platforms platform select -- select a platform instance as the current platform (not working yet) When using "platform create" it will create a remote platform and make it the selected platform. For instances for iPhone OS debugging on Mac OS X one can do: (lldb) platform create remote-ios --sdk-version=4.0 Remote platform: iOS platform SDK version: 4.0 SDK path: "/Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0" Not connected to a remote device. (lldb) file ~/Documents/a.out Current executable set to '~/Documents/a.out' (armv6). (lldb) image list [ 0] /Volumes/work/gclayton/Documents/devb/attach/a.out [ 1] /Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0/Symbols/usr/lib/dyld [ 2] /Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0/Symbols/usr/lib/libSystem.B.dylib Note that this is all happening prior to running _or_ connecting to a remote platform. Once connected to a remote platform the OS version might change which means we will need to update our dependecies. Also once we run, we will need to match up the actualy binaries with the actualy UUID's to files in the SDK, or download and cache them locally. This is just the start of the remote platforms, but this modification is the first iteration in getting the platforms really doing something. llvm-svn: 127934
2011-03-19 09:12:21 +08:00
Improve FreeBSD kernel debugging FreeBSD kernel modules are actually relocatable (.o) ELF files and this previously caused some issues for LLDB. This change addresses these when using lldb to symbolicate FreeBSD kernel backtraces. The major problems: - Relocations were not being applied to the DWARF debug info despite there being code to do this. Several issues prevented it from working: - Relocations are computed at the same time as the symbol table, but in the case of split debug files, symbol table parsing always redirects to the primary object file, meaning that relocations would never be applied in the debug file. - There's actually no guarantee that the symbol table has been parsed yet when trying to parse debug information. - When actually applying relocations, it will segfault because the object files are not mapped with MAP_PRIVATE and PROT_WRITE. - LLDB returned invalid results when performing ordinary address-to- symbol resolution. It turned out that the addresses specified in the section headers were all 0, so LLDB believed all the sections had overlapping "file addresses" and would sometimes return a symbol from the wrong section. Patch by Brian Koropoff Differential Revision: https://reviews.llvm.org/D38142 llvm-svn: 314672
2017-10-02 22:35:07 +08:00
size_t ObjectFile::ReadSectionData(Section *section,
Start converting usages of off_t to other types. off_t is a type which is used for file offsets. Even more specifically, it is only used by a limited number of C APIs that deal with files. Any usage of off_t where the variable is not intended to be used with one of these APIs is a bug, by definition. This patch corrects some easy mis-uses of off_t, generally by converting them to lldb::offset_t, but sometimes by using other types such as size_t, when appropriate. The use of off_t to represent these offsets has worked fine in practice on linux-y platforms, since we used _FILE_OFFSET_64 to guarantee that off_t was a uint64. On Windows, however, _FILE_OFFSET_64 is unrecognized, and off_t will always be 32-bit. So the usage of off_t on Windows actually leads to legitimate bugs. Reviewed by: Greg Clayton Differential Revision: http://reviews.llvm.org/D4358 llvm-svn: 212192
2014-07-03 01:24:07 +08:00
lldb::offset_t section_offset, void *dst,
Improve FreeBSD kernel debugging FreeBSD kernel modules are actually relocatable (.o) ELF files and this previously caused some issues for LLDB. This change addresses these when using lldb to symbolicate FreeBSD kernel backtraces. The major problems: - Relocations were not being applied to the DWARF debug info despite there being code to do this. Several issues prevented it from working: - Relocations are computed at the same time as the symbol table, but in the case of split debug files, symbol table parsing always redirects to the primary object file, meaning that relocations would never be applied in the debug file. - There's actually no guarantee that the symbol table has been parsed yet when trying to parse debug information. - When actually applying relocations, it will segfault because the object files are not mapped with MAP_PRIVATE and PROT_WRITE. - LLDB returned invalid results when performing ordinary address-to- symbol resolution. It turned out that the addresses specified in the section headers were all 0, so LLDB believed all the sections had overlapping "file addresses" and would sometimes return a symbol from the wrong section. Patch by Brian Koropoff Differential Revision: https://reviews.llvm.org/D38142 llvm-svn: 314672
2017-10-02 22:35:07 +08:00
size_t dst_len) {
Very minimal support 24-bit kalimbas. Vanilla "memory read" for data sections works, as do breakpoints, run and pause, display zeroth frame. See http://reviews.llvm.org/D5503 for a fuller description of the changes in this commit. llvm-svn: 218596
2014-09-29 16:02:24 +08:00
assert(section);
section_offset *= section->GetTargetByteSize();
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
Split symbol support for ELF and Linux. llvm-svn: 185366
2013-07-02 03:45:50 +08: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);
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
First pass at mach-o core file support is in. It currently works for x86_64 user space programs. The core file support is implemented by making a process plug-in that will dress up the threads and stack frames by using the core file memory. Added many default implementations for the lldb_private::Process functions so that plug-ins like the ProcessMachCore don't need to override many many functions only to have to return an error. Added new virtual functions to the ObjectFile class for extracting the frozen thread states that might be stored in object files. The default implementations return no thread information, but any platforms that support core files that contain frozen thread states (like mach-o) can make a module using the core file and then extract the information. The object files can enumerate the threads and also provide the register state for each thread. Since each object file knows how the thread registers are stored, they are responsible for creating a suitable register context that can be used by the core file threads. Changed the process CreateInstace callbacks to return a shared pointer and to also take an "const FileSpec *core_file" parameter to allow for core file support. This will also allow for lldb_private::Process subclasses to be made that could load crash logs. This should be possible on darwin where the crash logs contain all of the stack frames for all of the threads, yet the crash logs only contain the registers for the crashed thrad. It should also allow some variables to be viewed for the thread that crashed. llvm-svn: 150154
2012-02-09 14:16:32 +08:00
if (IsInMemory()) {
<rdar://problem/10560053> Fixed "target modules list" (aliased to "image list") to output more information by default. Modified the "target modules list" to have a few new options: "--header" or "-h" => show the image header address "--offset" or "-o" => show the image header address offset from the address in the file (the slide applied to the shared library) Removed the "--symfile-basename" or "-S" option, and repurposed it to "--symfile-unique" "-S" which will show the symbol file if it differs from the executable file. ObjectFile's can now be loaded from memory for cases where we don't have the files cached locally in an SDK or net mounted root. ObjectFileMachO can now read mach files from memory. Moved the section data reading code into the ObjectFile so that the object file can get the section data from Process memory if the file is only in memory. lldb_private::Module can now load its object file in a target with a rigid slide (very common operation for most dynamic linkers) by using: bool Module::SetLoadAddress (Target &target, lldb::addr_t offset, bool &changed) lldb::SBModule() now has a new constructor in the public interface: SBModule::SBModule (lldb::SBProcess &process, lldb::addr_t header_addr); This will find an appropriate ObjectFile plug-in to load an image from memory where the object file header is at "header_addr". llvm-svn: 149804
2012-02-05 10:38:54 +08:00
ProcessSP process_sp(m_process_wp.lock());
if (process_sp) {
Rename Error -> Status. This renames the LLDB error class to Status, as discussed on the lldb-dev mailing list. A change of this magnitude cannot easily be done without find and replace, but that has potential to catch unwanted occurrences of common strings such as "Error". Every effort was made to find all the obvious things such as the word "Error" appearing in a string, etc, but it's possible there are still some lingering occurences left around. Hopefully nothing too serious. llvm-svn: 302872
2017-05-12 12:51:55 +08:00
Status error;
<rdar://problem/13092722> Fix in loading mach files from memory when using DynamicLoaderMacOSXDYLD. Removed the uuid mismatch warning that could be spit out and any time during debugging and removed the test case that was looking for that. Currently the "add-dsym" or "target symbols add" command will report an error when the UUID's don't match. Be more careful when checking and resolving section + offset addresses to make sure none of the base addresses are invalid. llvm-svn: 174222
2013-02-02 05:38:35 +08: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);
<rdar://problem/10560053> Fixed "target modules list" (aliased to "image list") to output more information by default. Modified the "target modules list" to have a few new options: "--header" or "-h" => show the image header address "--offset" or "-o" => show the image header address offset from the address in the file (the slide applied to the shared library) Removed the "--symfile-basename" or "-S" option, and repurposed it to "--symfile-unique" "-S" which will show the symbol file if it differs from the executable file. ObjectFile's can now be loaded from memory for cases where we don't have the files cached locally in an SDK or net mounted root. ObjectFileMachO can now read mach files from memory. Moved the section data reading code into the ObjectFile so that the object file can get the section data from Process memory if the file is only in memory. lldb_private::Module can now load its object file in a target with a rigid slide (very common operation for most dynamic linkers) by using: bool Module::SetLoadAddress (Target &target, lldb::addr_t offset, bool &changed) lldb::SBModule() now has a new constructor in the public interface: SBModule::SBModule (lldb::SBProcess &process, lldb::addr_t header_addr); This will find an appropriate ObjectFile plug-in to load an image from memory where the object file header is at "header_addr". llvm-svn: 149804
2012-02-05 10:38:54 +08:00
}
} else {
Improve FreeBSD kernel debugging FreeBSD kernel modules are actually relocatable (.o) ELF files and this previously caused some issues for LLDB. This change addresses these when using lldb to symbolicate FreeBSD kernel backtraces. The major problems: - Relocations were not being applied to the DWARF debug info despite there being code to do this. Several issues prevented it from working: - Relocations are computed at the same time as the symbol table, but in the case of split debug files, symbol table parsing always redirects to the primary object file, meaning that relocations would never be applied in the debug file. - There's actually no guarantee that the symbol table has been parsed yet when trying to parse debug information. - When actually applying relocations, it will segfault because the object files are not mapped with MAP_PRIVATE and PROT_WRITE. - LLDB returned invalid results when performing ordinary address-to- symbol resolution. It turned out that the addresses specified in the section headers were all 0, so LLDB believed all the sections had overlapping "file addresses" and would sometimes return a symbol from the wrong section. Patch by Brian Koropoff Differential Revision: https://reviews.llvm.org/D38142 llvm-svn: 314672
2017-10-02 22:35:07 +08:00
if (!section->IsRelocated())
RelocateSection(section);
Start converting usages of off_t to other types. off_t is a type which is used for file offsets. Even more specifically, it is only used by a limited number of C APIs that deal with files. Any usage of off_t where the variable is not intended to be used with one of these APIs is a bug, by definition. This patch corrects some easy mis-uses of off_t, generally by converting them to lldb::offset_t, but sometimes by using other types such as size_t, when appropriate. The use of off_t to represent these offsets has worked fine in practice on linux-y platforms, since we used _FILE_OFFSET_64 to guarantee that off_t was a uint64. On Windows, however, _FILE_OFFSET_64 is unrecognized, and off_t will always be 32-bit. So the usage of off_t on Windows actually leads to legitimate bugs. Reviewed by: Greg Clayton Differential Revision: http://reviews.llvm.org/D4358 llvm-svn: 212192
2014-07-03 01:24:07 +08: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;
Fixed an issue where empty sections or zero filled sections could return incorrect values and also fire an assertion. llvm-svn: 151066
2012-02-22 01:34:25 +08:00
if (section_dst_len > section_bytes_left)
section_dst_len = section_bytes_left;
return CopyData(section->GetFileOffset() + section_offset,
section_dst_len, dst);
Read bytes from zero-filled sections correctly instead of failing to read. <rdar://problem/12958589> llvm-svn: 171552
2013-01-05 07:20:01 +08: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;
MingW compilation (windows). Includes various refactoring to improve portability. llvm-svn: 189107
2013-08-23 20:44:05 +08:00
memset(dst, 0, section_dst_len);
Read bytes from zero-filled sections correctly instead of failing to read. <rdar://problem/12958589> llvm-svn: 171552
2013-01-05 07:20:01 +08:00
return section_dst_len;
}
<rdar://problem/10560053> Fixed "target modules list" (aliased to "image list") to output more information by default. Modified the "target modules list" to have a few new options: "--header" or "-h" => show the image header address "--offset" or "-o" => show the image header address offset from the address in the file (the slide applied to the shared library) Removed the "--symfile-basename" or "-S" option, and repurposed it to "--symfile-unique" "-S" which will show the symbol file if it differs from the executable file. ObjectFile's can now be loaded from memory for cases where we don't have the files cached locally in an SDK or net mounted root. ObjectFileMachO can now read mach files from memory. Moved the section data reading code into the ObjectFile so that the object file can get the section data from Process memory if the file is only in memory. lldb_private::Module can now load its object file in a target with a rigid slide (very common operation for most dynamic linkers) by using: bool Module::SetLoadAddress (Target &target, lldb::addr_t offset, bool &changed) lldb::SBModule() now has a new constructor in the public interface: SBModule::SBModule (lldb::SBProcess &process, lldb::addr_t header_addr); This will find an appropriate ObjectFile plug-in to load an image from memory where the object file header is at "header_addr". llvm-svn: 149804
2012-02-05 10:38:54 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
}
<rdar://problem/10560053> Fixed "target modules list" (aliased to "image list") to output more information by default. Modified the "target modules list" to have a few new options: "--header" or "-h" => show the image header address "--offset" or "-o" => show the image header address offset from the address in the file (the slide applied to the shared library) Removed the "--symfile-basename" or "-S" option, and repurposed it to "--symfile-unique" "-S" which will show the symbol file if it differs from the executable file. ObjectFile's can now be loaded from memory for cases where we don't have the files cached locally in an SDK or net mounted root. ObjectFileMachO can now read mach files from memory. Moved the section data reading code into the ObjectFile so that the object file can get the section data from Process memory if the file is only in memory. lldb_private::Module can now load its object file in a target with a rigid slide (very common operation for most dynamic linkers) by using: bool Module::SetLoadAddress (Target &target, lldb::addr_t offset, bool &changed) lldb::SBModule() now has a new constructor in the public interface: SBModule::SBModule (lldb::SBProcess &process, lldb::addr_t header_addr); This will find an appropriate ObjectFile plug-in to load an image from memory where the object file header is at "header_addr". llvm-svn: 149804
2012-02-05 10:38:54 +08:00
return 0;
}
// Get the section data the file on disk
Improve FreeBSD kernel debugging FreeBSD kernel modules are actually relocatable (.o) ELF files and this previously caused some issues for LLDB. This change addresses these when using lldb to symbolicate FreeBSD kernel backtraces. The major problems: - Relocations were not being applied to the DWARF debug info despite there being code to do this. Several issues prevented it from working: - Relocations are computed at the same time as the symbol table, but in the case of split debug files, symbol table parsing always redirects to the primary object file, meaning that relocations would never be applied in the debug file. - There's actually no guarantee that the symbol table has been parsed yet when trying to parse debug information. - When actually applying relocations, it will segfault because the object files are not mapped with MAP_PRIVATE and PROT_WRITE. - LLDB returned invalid results when performing ordinary address-to- symbol resolution. It turned out that the addresses specified in the section headers were all 0, so LLDB believed all the sections had overlapping "file addresses" and would sometimes return a symbol from the wrong section. Patch by Brian Koropoff Differential Revision: https://reviews.llvm.org/D38142 llvm-svn: 314672
2017-10-02 22:35:07 +08:00
size_t ObjectFile::ReadSectionData(Section *section,
DataExtractor &section_data) {
Split symbol support for ELF and Linux. llvm-svn: 185366
2013-07-02 03:45:50 +08:00
// If some other objectfile owns this data, pass this to them.
if (section->GetObjectFile() != this)
return section->GetObjectFile()->ReadSectionData(section, section_data);
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
First pass at mach-o core file support is in. It currently works for x86_64 user space programs. The core file support is implemented by making a process plug-in that will dress up the threads and stack frames by using the core file memory. Added many default implementations for the lldb_private::Process functions so that plug-ins like the ProcessMachCore don't need to override many many functions only to have to return an error. Added new virtual functions to the ObjectFile class for extracting the frozen thread states that might be stored in object files. The default implementations return no thread information, but any platforms that support core files that contain frozen thread states (like mach-o) can make a module using the core file and then extract the information. The object files can enumerate the threads and also provide the register state for each thread. Since each object file knows how the thread registers are stored, they are responsible for creating a suitable register context that can be used by the core file threads. Changed the process CreateInstace callbacks to return a shared pointer and to also take an "const FileSpec *core_file" parameter to allow for core file support. This will also allow for lldb_private::Process subclasses to be made that could load crash logs. This should be possible on darwin where the crash logs contain all of the stack frames for all of the threads, yet the crash logs only contain the registers for the crashed thrad. It should also allow some variables to be viewed for the thread that crashed. llvm-svn: 150154
2012-02-09 14:16:32 +08:00
if (IsInMemory()) {
<rdar://problem/10560053> Fixed "target modules list" (aliased to "image list") to output more information by default. Modified the "target modules list" to have a few new options: "--header" or "-h" => show the image header address "--offset" or "-o" => show the image header address offset from the address in the file (the slide applied to the shared library) Removed the "--symfile-basename" or "-S" option, and repurposed it to "--symfile-unique" "-S" which will show the symbol file if it differs from the executable file. ObjectFile's can now be loaded from memory for cases where we don't have the files cached locally in an SDK or net mounted root. ObjectFileMachO can now read mach files from memory. Moved the section data reading code into the ObjectFile so that the object file can get the section data from Process memory if the file is only in memory. lldb_private::Module can now load its object file in a target with a rigid slide (very common operation for most dynamic linkers) by using: bool Module::SetLoadAddress (Target &target, lldb::addr_t offset, bool &changed) lldb::SBModule() now has a new constructor in the public interface: SBModule::SBModule (lldb::SBProcess &process, lldb::addr_t header_addr); This will find an appropriate ObjectFile plug-in to load an image from memory where the object file header is at "header_addr". llvm-svn: 149804
2012-02-05 10:38:54 +08:00
ProcessSP process_sp(m_process_wp.lock());
if (process_sp) {
<rdar://problem/13092722> Fix in loading mach files from memory when using DynamicLoaderMacOSXDYLD. Removed the uuid mismatch warning that could be spit out and any time during debugging and removed the test case that was looking for that. Currently the "add-dsym" or "target symbols add" command will report an error when the UUID's don't match. Be more careful when checking and resolving section + offset addresses to make sure none of the base addresses are invalid. llvm-svn: 174222
2013-02-02 05:38:35 +08: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();
<rdar://problem/10560053> Fixed "target modules list" (aliased to "image list") to output more information by default. Modified the "target modules list" to have a few new options: "--header" or "-h" => show the image header address "--offset" or "-o" => show the image header address offset from the address in the file (the slide applied to the shared library) Removed the "--symfile-basename" or "-S" option, and repurposed it to "--symfile-unique" "-S" which will show the symbol file if it differs from the executable file. ObjectFile's can now be loaded from memory for cases where we don't have the files cached locally in an SDK or net mounted root. ObjectFileMachO can now read mach files from memory. Moved the section data reading code into the ObjectFile so that the object file can get the section data from Process memory if the file is only in memory. lldb_private::Module can now load its object file in a target with a rigid slide (very common operation for most dynamic linkers) by using: bool Module::SetLoadAddress (Target &target, lldb::addr_t offset, bool &changed) lldb::SBModule() now has a new constructor in the public interface: SBModule::SBModule (lldb::SBProcess &process, lldb::addr_t header_addr); This will find an appropriate ObjectFile plug-in to load an image from memory where the object file header is at "header_addr". llvm-svn: 149804
2012-02-05 10:38:54 +08:00
}
}
}
Fix in-memory section loading for JIT-ed code. http://reviews.llvm.org/D15172 llvm-svn: 254638
2015-12-04 03:41:21 +08:00
return GetData(section->GetFileOffset(), section->GetFileSize(),
section_data);
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
} else {
Reflow paragraphs in comments. This is intended as a clean up after the big clang-format commit (r280751), which unfortunately resulted in many of the comment paragraphs in LLDB being very hard to read. FYI, the script I used was: import textwrap import commands import os import sys import re tmp = "%s.tmp"%sys.argv[1] out = open(tmp, "w+") with open(sys.argv[1], "r") as f: header = "" text = "" comment = re.compile(r'^( *//) ([^ ].*)$') special = re.compile(r'^((([A-Z]+[: ])|([0-9]+ )).*)|(.*;)$') for line in f: match = comment.match(line) if match and not special.match(match.group(2)): # skip intentionally short comments. if not text and len(match.group(2)) < 40: out.write(line) continue if text: text += " " + match.group(2) else: header = match.group(1) text = match.group(2) continue if text: filled = textwrap.wrap(text, width=(78-len(header)), break_long_words=False) for l in filled: out.write(header+" "+l+'\n') text = "" out.write(line) os.rename(tmp, sys.argv[1]) Differential Revision: https://reviews.llvm.org/D46144 llvm-svn: 331197
2018-05-01 00:49:04 +08:00
// The object file now contains a full mmap'ed copy of the object file
// data, so just use this
Improve FreeBSD kernel debugging FreeBSD kernel modules are actually relocatable (.o) ELF files and this previously caused some issues for LLDB. This change addresses these when using lldb to symbolicate FreeBSD kernel backtraces. The major problems: - Relocations were not being applied to the DWARF debug info despite there being code to do this. Several issues prevented it from working: - Relocations are computed at the same time as the symbol table, but in the case of split debug files, symbol table parsing always redirects to the primary object file, meaning that relocations would never be applied in the debug file. - There's actually no guarantee that the symbol table has been parsed yet when trying to parse debug information. - When actually applying relocations, it will segfault because the object files are not mapped with MAP_PRIVATE and PROT_WRITE. - LLDB returned invalid results when performing ordinary address-to- symbol resolution. It turned out that the addresses specified in the section headers were all 0, so LLDB believed all the sections had overlapping "file addresses" and would sometimes return a symbol from the wrong section. Patch by Brian Koropoff Differential Revision: https://reviews.llvm.org/D38142 llvm-svn: 314672
2017-10-02 22:35:07 +08:00
if (!section->IsRelocated())
RelocateSection(section);
Fixed a few things in the ELF object file: 1 - sections only get a valid VM size if they have SHF_ALLOC in the section flags 2 - symbol names are marked as mangled if they start with "_Z" Also fixed the DWARF parser to correctly use the section file size when extracting the DWARF. llvm-svn: 153496
2012-03-27 10:40:46 +08:00
return GetData(section->GetFileOffset(), section->GetFileSize(),
section_data);
<rdar://problem/10560053> Fixed "target modules list" (aliased to "image list") to output more information by default. Modified the "target modules list" to have a few new options: "--header" or "-h" => show the image header address "--offset" or "-o" => show the image header address offset from the address in the file (the slide applied to the shared library) Removed the "--symfile-basename" or "-S" option, and repurposed it to "--symfile-unique" "-S" which will show the symbol file if it differs from the executable file. ObjectFile's can now be loaded from memory for cases where we don't have the files cached locally in an SDK or net mounted root. ObjectFileMachO can now read mach files from memory. Moved the section data reading code into the ObjectFile so that the object file can get the section data from Process memory if the file is only in memory. lldb_private::Module can now load its object file in a target with a rigid slide (very common operation for most dynamic linkers) by using: bool Module::SetLoadAddress (Target &target, lldb::addr_t offset, bool &changed) lldb::SBModule() now has a new constructor in the public interface: SBModule::SBModule (lldb::SBProcess &process, lldb::addr_t header_addr); This will find an appropriate ObjectFile plug-in to load an image from memory where the object file header is at "header_addr". llvm-svn: 149804
2012-02-05 10:38:54 +08:00
}
}
Replace regex match with rfind (NFCish) This change is mostly performance-neutral since our regex engine is fast, but it's IMHO slightly more readable. Also, matching matching parenthesis is not a great match for regular expressions. Differential Revision: https://reviews.llvm.org/D68609 llvm-svn: 374082
2019-10-09 00:29:39 +08:00
bool ObjectFile::SplitArchivePathWithObject(llvm::StringRef path_with_object,
<rdar://problem/11109570> The first part of the fix for having LLDB handle LTO debugging when the DWARF is in the .o files. This part separates the object file's modules into a separate cache map that maps unique C strings for the N_OSO path to the ModuleSP since one object file might be mentioned more than once in LTO binaries. llvm-svn: 174476
2013-02-06 08:38:25 +08:00
FileSpec &archive_file,
ConstString &archive_object,
bool must_exist) {
Replace regex match with rfind (NFCish) This change is mostly performance-neutral since our regex engine is fast, but it's IMHO slightly more readable. Also, matching matching parenthesis is not a great match for regular expressions. Differential Revision: https://reviews.llvm.org/D68609 llvm-svn: 374082
2019-10-09 00:29:39 +08: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-30 05:13:06 +08:00
}
Cleanup on the unified section list changes. Main changes are: - ObjectFile::GetSymtab() and ObjectFile::ClearSymtab() no longer takes any flags - Module coordinates with the object files and contain a unified section list so that object file and symbol file can share sections when they need to, yet contain their own sections. Other cleanups: - Fixed Symbol::GetByteSize() to not have the symbol table compute the byte sizes on the fly - Modified the ObjectFileMachO class to compute symbol sizes all at once efficiently - Modified the Symtab class to store a file address lookup table for more efficient lookups - Removed Section::Finalize() and SectionList::Finalize() as they did nothing - Improved performance of the detection of symbol files that have debug maps by excluding stripped files and core files, debug files, object files and stubs - Added the ability to tell if an ObjectFile has been stripped with ObjectFile::IsStripped() (used this for the above performance improvement) llvm-svn: 185990
2013-07-10 09:23:25 +08:00
void ObjectFile::ClearSymtab() {
<rdar://problem/13338643> DWARF with .o files now uses 40-60% less memory! Big fixes include: - Change line table internal representation to contain "file addresses". Since each line table is owned by a compile unit that is owned by a module, it makes address translation into lldb_private::Address easy to do when needed. - Removed linked address members/methods from lldb_private::Section and lldb_private::Address - lldb_private::LineTable can now relink itself using a FileRangeMap to make it easier to re-link line tables in the future - Added ObjectFile::ClearSymtab() so that we can get rid of the object file symbol tables after we parse them once since they are not needed and kept memory allocated for no reason - Moved the m_sections_ap (std::auto_ptr to section list) and m_symtab_ap (std::auto_ptr to the lldb_private::Symtab) out of each of the ObjectFile subclasses and put it into lldb_private::ObjectFile. - Changed how the debug map is parsed and stored to be able to: - Lazily parse the debug map for each object file - not require the address map for a .o file until debug information is linked for a .o file llvm-svn: 176454
2013-03-05 05:46:16 +08:00
ModuleSP module_sp(GetModule());
if (module_sp) {
remove use of Mutex in favour of std::{,recursive_}mutex This is a pretty straightforward first pass over removing a number of uses of Mutex in favor of std::mutex or std::recursive_mutex. The problem is that there are interfaces which take Mutex::Locker & to lock internal locks. This patch cleans up most of the easy cases. The only non-trivial change is in CommandObjectTarget.cpp where a Mutex::Locker was split into two. llvm-svn: 269877
2016-05-18 09:59:10 +08:00
std::lock_guard<std::recursive_mutex> guard(module_sp->GetMutex());
<rdar://problem/13521159> LLDB is crashing when logging is enabled from lldb-perf-clang. This has to do with the global destructor chain as the process and its threads are being torn down. All logging channels now make one and only one instance that is kept in a global pointer which is never freed. This guarantees that logging can correctly continue as the process tears itself down. llvm-svn: 178191
2013-03-28 07:08:40 +08:00
Log *log(lldb_private::GetLogIfAllCategoriesSet(LIBLLDB_LOG_OBJECT));
[Logging] Replace Log::Printf with LLDB_LOG macro (NFC) This patch replaces explicit calls to log::Printf with the new LLDB_LOGF macro. The macro is similar to LLDB_LOG but supports printf-style format strings, instead of formatv-style format strings. So instead of writing: if (log) log->Printf("%s\n", str); You'd write: LLDB_LOG(log, "%s\n", str); This change was done mechanically with the command below. I replaced the spurious if-checks with vim, since I know how to do multi-line replacements with it. find . -type f -name '*.cpp' -exec \ sed -i '' -E 's/log->Printf\(/LLDB_LOGF\(log, /g' "{}" + Differential revision: https://reviews.llvm.org/D65128 llvm-svn: 366936
2019-07-25 01:56:10 +08:00
LLDB_LOGF(log, "%p ObjectFile::ClearSymtab () symtab = %p",
static_cast<void *>(this),
static_cast<void *>(m_symtab_up.get()));
Replace 'ap' with 'up' suffix in variable names. (NFC) The `ap` suffix is a remnant of lldb's former use of auto pointers, before they got deprecated. Although all their uses were replaced by unique pointers, some variables still carried the suffix. In r353795 I removed another auto_ptr remnant, namely redundant calls to ::get for unique_pointers. Jim justly noted that this is a good opportunity to clean up the variable names as well. I went over all the changes to ensure my find-and-replace didn't have any undesired side-effects. I hope I didn't miss any, but if you end up at this commit doing a git blame on a weirdly named variable, please know that the change was unintentional. llvm-svn: 353912
2019-02-13 14:25:41 +08:00
m_symtab_up.reset();
Cleanup on the unified section list changes. Main changes are: - ObjectFile::GetSymtab() and ObjectFile::ClearSymtab() no longer takes any flags - Module coordinates with the object files and contain a unified section list so that object file and symbol file can share sections when they need to, yet contain their own sections. Other cleanups: - Fixed Symbol::GetByteSize() to not have the symbol table compute the byte sizes on the fly - Modified the ObjectFileMachO class to compute symbol sizes all at once efficiently - Modified the Symtab class to store a file address lookup table for more efficient lookups - Removed Section::Finalize() and SectionList::Finalize() as they did nothing - Improved performance of the detection of symbol files that have debug maps by excluding stripped files and core files, debug files, object files and stubs - Added the ability to tell if an ObjectFile has been stripped with ObjectFile::IsStripped() (used this for the above performance improvement) llvm-svn: 185990
2013-07-10 09:23:25 +08:00
}
}
Add basic fission support to SymbolFileDWARF * Create new dwo symbol file class * Add handling for .dwo sections * Change indexes in SymbolFileDWARF to store compile unit offset next to DIE offset * Propagate queries from dwarf compile unit to the dwo compile unit where applicable Differential revision: http://reviews.llvm.org/D12291 llvm-svn: 247132
2015-09-09 18:20:48 +08:00
SectionList *ObjectFile::GetSectionList(bool update_module_section_list) {
Replace 'ap' with 'up' suffix in variable names. (NFC) The `ap` suffix is a remnant of lldb's former use of auto pointers, before they got deprecated. Although all their uses were replaced by unique pointers, some variables still carried the suffix. In r353795 I removed another auto_ptr remnant, namely redundant calls to ::get for unique_pointers. Jim justly noted that this is a good opportunity to clean up the variable names as well. I went over all the changes to ensure my find-and-replace didn't have any undesired side-effects. I hope I didn't miss any, but if you end up at this commit doing a git blame on a weirdly named variable, please know that the change was unintentional. llvm-svn: 353912
2019-02-13 14:25:41 +08:00
if (m_sections_up == nullptr) {
Add basic fission support to SymbolFileDWARF * Create new dwo symbol file class * Add handling for .dwo sections * Change indexes in SymbolFileDWARF to store compile unit offset next to DIE offset * Propagate queries from dwarf compile unit to the dwo compile unit where applicable Differential revision: http://reviews.llvm.org/D12291 llvm-svn: 247132
2015-09-09 18:20:48 +08:00
if (update_module_section_list) {
ModuleSP module_sp(GetModule());
if (module_sp) {
remove use of Mutex in favour of std::{,recursive_}mutex This is a pretty straightforward first pass over removing a number of uses of Mutex in favor of std::mutex or std::recursive_mutex. The problem is that there are interfaces which take Mutex::Locker & to lock internal locks. This patch cleans up most of the easy cases. The only non-trivial change is in CommandObjectTarget.cpp where a Mutex::Locker was split into two. llvm-svn: 269877
2016-05-18 09:59:10 +08:00
std::lock_guard<std::recursive_mutex> guard(module_sp->GetMutex());
Add basic fission support to SymbolFileDWARF * Create new dwo symbol file class * Add handling for .dwo sections * Change indexes in SymbolFileDWARF to store compile unit offset next to DIE offset * Propagate queries from dwarf compile unit to the dwo compile unit where applicable Differential revision: http://reviews.llvm.org/D12291 llvm-svn: 247132
2015-09-09 18:20:48 +08:00
CreateSections(*module_sp->GetUnifiedSectionList());
}
} else {
SectionList unified_section_list;
CreateSections(unified_section_list);
<rdar://problem/13338643> DWARF with .o files now uses 40-60% less memory! Big fixes include: - Change line table internal representation to contain "file addresses". Since each line table is owned by a compile unit that is owned by a module, it makes address translation into lldb_private::Address easy to do when needed. - Removed linked address members/methods from lldb_private::Section and lldb_private::Address - lldb_private::LineTable can now relink itself using a FileRangeMap to make it easier to re-link line tables in the future - Added ObjectFile::ClearSymtab() so that we can get rid of the object file symbol tables after we parse them once since they are not needed and kept memory allocated for no reason - Moved the m_sections_ap (std::auto_ptr to section list) and m_symtab_ap (std::auto_ptr to the lldb_private::Symtab) out of each of the ObjectFile subclasses and put it into lldb_private::ObjectFile. - Changed how the debug map is parsed and stored to be able to: - Lazily parse the debug map for each object file - not require the address map for a .o file until debug information is linked for a .o file llvm-svn: 176454
2013-03-05 05:46:16 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
}
Replace 'ap' with 'up' suffix in variable names. (NFC) The `ap` suffix is a remnant of lldb's former use of auto pointers, before they got deprecated. Although all their uses were replaced by unique pointers, some variables still carried the suffix. In r353795 I removed another auto_ptr remnant, namely redundant calls to ::get for unique_pointers. Jim justly noted that this is a good opportunity to clean up the variable names as well. I went over all the changes to ensure my find-and-replace didn't have any undesired side-effects. I hope I didn't miss any, but if you end up at this commit doing a git blame on a weirdly named variable, please know that the change was unintentional. llvm-svn: 353912
2019-02-13 14:25:41 +08:00
return m_sections_up.get();
<rdar://problem/13338643> DWARF with .o files now uses 40-60% less memory! Big fixes include: - Change line table internal representation to contain "file addresses". Since each line table is owned by a compile unit that is owned by a module, it makes address translation into lldb_private::Address easy to do when needed. - Removed linked address members/methods from lldb_private::Section and lldb_private::Address - lldb_private::LineTable can now relink itself using a FileRangeMap to make it easier to re-link line tables in the future - Added ObjectFile::ClearSymtab() so that we can get rid of the object file symbol tables after we parse them once since they are not needed and kept memory allocated for no reason - Moved the m_sections_ap (std::auto_ptr to section list) and m_symtab_ap (std::auto_ptr to the lldb_private::Symtab) out of each of the ObjectFile subclasses and put it into lldb_private::ObjectFile. - Changed how the debug map is parsed and stored to be able to: - Lazily parse the debug map for each object file - not require the address map for a .o file until debug information is linked for a .o file llvm-svn: 176454
2013-03-05 05:46:16 +08:00
}
Add support for tvos and watchos to ObjectFileMachO. Add support for the new dyld shared cache format on ios etc devices. Small changes for classifying ObjC metadata symbols. llvm-svn: 252588
2015-11-10 13:21:54 +08:00
lldb::SymbolType
ObjectFile::GetSymbolTypeFromName(llvm::StringRef name,
lldb::SymbolType symbol_type_hint) {
if (!name.empty()) {
if (name.startswith("_OBJC_")) {
// ObjC
if (name.startswith("_OBJC_CLASS_$_"))
return lldb::eSymbolTypeObjCClass;
if (name.startswith("_OBJC_METACLASS_$_"))
return lldb::eSymbolTypeObjCMetaClass;
if (name.startswith("_OBJC_IVAR_$_"))
return lldb::eSymbolTypeObjCIVar;
} else if (name.startswith(".objc_class_name_")) {
// ObjC v1
return lldb::eSymbolTypeObjCClass;
}
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
}
Add support for tvos and watchos to ObjectFileMachO. Add support for the new dyld shared cache format on ios etc devices. Small changes for classifying ObjC metadata symbols. llvm-svn: 252588
2015-11-10 13:21:54 +08:00
return symbol_type_hint;
}
Improve the handling of missing elf symtab and missing symbol sizes * Generate artificial symbol names from eh_fame during symbol parsing so these symbols are already present when we calcualte the size of the symbols where 0 is specified. * Fix symbol size calculation for the last symbol in the file where it have to last until the end of the parent section. This is the re-commit of the original change after fixing some test failures on OSX. Differential revision: http://reviews.llvm.org/D16996 llvm-svn: 261205
2016-02-18 19:12:18 +08:00
ConstString ObjectFile::GetNextSyntheticSymbolName() {
StreamString ss;
ConstString file_name = GetModule()->GetFileSpec().GetFilename();
ss.Printf("___lldb_unnamed_symbol%u$$%s", ++m_synthetic_symbol_idx,
file_name.GetCString());
Don't allow direct access to StreamString's internal buffer. This is a large API change that removes the two functions from StreamString that return a std::string& and a const std::string&, and instead provide one function which returns a StringRef. Direct access to the underlying buffer violates the concept of a "stream" which is intended to provide forward only access, and makes porting to llvm::raw_ostream more difficult in the future. Differential Revision: https://reviews.llvm.org/D26698 llvm-svn: 287152
2016-11-17 05:15:24 +08:00
return ConstString(ss.GetString());
Improve the handling of missing elf symtab and missing symbol sizes * Generate artificial symbol names from eh_fame during symbol parsing so these symbols are already present when we calcualte the size of the symbols where 0 is specified. * Fix symbol size calculation for the last symbol in the file where it have to last until the end of the parent section. This is the re-commit of the original change after fixing some test failures on OSX. Differential revision: http://reviews.llvm.org/D16996 llvm-svn: 261205
2016-02-18 19:12:18 +08:00
}
Provide a substitute to load command of gdb. For bare-metal targets, lldb was missing a command like 'load' in gdb which can be used to create executable image on the target. This was discussed in http://lists.llvm.org/pipermail/lldb-dev/2016-December/011752.html This commits adds an option to "target module load" command to provide that functionality. It does not set the PC to entry address which will be done separately. Reviewed in https://reviews.llvm.org/D28804 llvm-svn: 292499
2017-01-20 01:32:50 +08: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 19:56:24 +08:00
std::vector<ObjectFile::LoadableData>
ObjectFile::GetLoadableData(Target &target) {
std::vector<LoadableData> loadables;
Provide a substitute to load command of gdb. For bare-metal targets, lldb was missing a command like 'load' in gdb which can be used to create executable image on the target. This was discussed in http://lists.llvm.org/pipermail/lldb-dev/2016-December/011752.html This commits adds an option to "target module load" command to provide that functionality. It does not set the PC to entry address which will be done separately. Reviewed in https://reviews.llvm.org/D28804 llvm-svn: 292499
2017-01-20 01:32:50 +08: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 19:56:24 +08:00
return loadables;
// Create a list of loadable data from loadable sections
Provide a substitute to load command of gdb. For bare-metal targets, lldb was missing a command like 'load' in gdb which can be used to create executable image on the target. This was discussed in http://lists.llvm.org/pipermail/lldb-dev/2016-December/011752.html This commits adds an option to "target module load" command to provide that functionality. It does not set the PC to entry address which will be done separately. Reviewed in https://reviews.llvm.org/D28804 llvm-svn: 292499
2017-01-20 01:32:50 +08: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 19:56:24 +08:00
LoadableData loadable;
Provide a substitute to load command of gdb. For bare-metal targets, lldb was missing a command like 'load' in gdb which can be used to create executable image on the target. This was discussed in http://lists.llvm.org/pipermail/lldb-dev/2016-December/011752.html This commits adds an option to "target module load" command to provide that functionality. It does not set the PC to entry address which will be done separately. Reviewed in https://reviews.llvm.org/D28804 llvm-svn: 292499
2017-01-20 01:32:50 +08:00
SectionSP section_sp = section_list->GetSectionAtIndex(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 19:56:24 +08:00
loadable.Dest =
target.GetSectionLoadList().GetSectionLoadAddress(section_sp);
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);
Provide option to set pc of the file loaded in memory. Summary: This commit adds an option to set PC to the entry point of the file loaded using "target module load" command. In D28804, Greg asked me to separate this part under a different option. Reviewers: clayborg Reviewed By: clayborg Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D28944 llvm-svn: 292989
2017-01-25 07:07:27 +08: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 19:56:24 +08:00
return loadables;
Provide a substitute to load command of gdb. For bare-metal targets, lldb was missing a command like 'load' in gdb which can be used to create executable image on the target. This was discussed in http://lists.llvm.org/pipermail/lldb-dev/2016-December/011752.html This commits adds an option to "target module load" command to provide that functionality. It does not set the PC to entry address which will be done separately. Reviewed in https://reviews.llvm.org/D28804 llvm-svn: 292499
2017-01-20 01:32:50 +08:00
}
Improve FreeBSD kernel debugging FreeBSD kernel modules are actually relocatable (.o) ELF files and this previously caused some issues for LLDB. This change addresses these when using lldb to symbolicate FreeBSD kernel backtraces. The major problems: - Relocations were not being applied to the DWARF debug info despite there being code to do this. Several issues prevented it from working: - Relocations are computed at the same time as the symbol table, but in the case of split debug files, symbol table parsing always redirects to the primary object file, meaning that relocations would never be applied in the debug file. - There's actually no guarantee that the symbol table has been parsed yet when trying to parse debug information. - When actually applying relocations, it will segfault because the object files are not mapped with MAP_PRIVATE and PROT_WRITE. - LLDB returned invalid results when performing ordinary address-to- symbol resolution. It turned out that the addresses specified in the section headers were all 0, so LLDB believed all the sections had overlapping "file addresses" and would sometimes return a symbol from the wrong section. Patch by Brian Koropoff Differential Revision: https://reviews.llvm.org/D38142 llvm-svn: 314672
2017-10-02 22:35:07 +08: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 17:03:29 +08:00
std::unique_ptr<CallFrameInfo> ObjectFile::CreateCallFrameInfo() {
return {};
}
Improve FreeBSD kernel debugging FreeBSD kernel modules are actually relocatable (.o) ELF files and this previously caused some issues for LLDB. This change addresses these when using lldb to symbolicate FreeBSD kernel backtraces. The major problems: - Relocations were not being applied to the DWARF debug info despite there being code to do this. Several issues prevented it from working: - Relocations are computed at the same time as the symbol table, but in the case of split debug files, symbol table parsing always redirects to the primary object file, meaning that relocations would never be applied in the debug file. - There's actually no guarantee that the symbol table has been parsed yet when trying to parse debug information. - When actually applying relocations, it will segfault because the object files are not mapped with MAP_PRIVATE and PROT_WRITE. - LLDB returned invalid results when performing ordinary address-to- symbol resolution. It turned out that the addresses specified in the section headers were all 0, so LLDB believed all the sections had overlapping "file addresses" and would sometimes return a symbol from the wrong section. Patch by Brian Koropoff Differential Revision: https://reviews.llvm.org/D38142 llvm-svn: 314672
2017-10-02 22:35:07 +08: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 18:54:30 +08:00
DataBufferSP ObjectFile::MapFileData(const FileSpec &file, uint64_t Size,
uint64_t Offset) {
Re-land "Extract construction of DataBufferLLVM into FileSystem" This fixes some UB in isLocal detected by the sanitized bot. llvm-svn: 346707
2018-11-13 05:24:50 +08: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 18:54:30 +08: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-11 01:16:38 +08: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;
}
}