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

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

1889 lines
66 KiB
C++
Raw Normal View History

[lldb][NFC] Fix all formatting errors in .cpp file headers Summary: A *.cpp file header in LLDB (and in LLDB) should like this: ``` //===-- TestUtilities.cpp -------------------------------------------------===// ``` However in LLDB most of our source files have arbitrary changes to this format and these changes are spreading through LLDB as folks usually just use the existing source files as templates for their new files (most notably the unnecessary editor language indicator `-*- C++ -*-` is spreading and in every review someone is pointing out that this is wrong, resulting in people pointing out that this is done in the same way in other files). This patch removes most of these inconsistencies including the editor language indicators, all the different missing/additional '-' characters, files that center the file name, missing trailing `===//` (mostly caused by clang-format breaking the line). Reviewers: aprantl, espindola, jfb, shafik, JDevlieghere Reviewed By: JDevlieghere Subscribers: dexonsmith, wuzish, emaste, sdardis, nemanjai, kbarton, MaskRay, atanasyan, arphaman, jfb, abidh, jsji, JDevlieghere, usaxena95, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D73258
2020-01-24 15:23:27 +08:00
//===-- CommandObjectMemory.cpp -------------------------------------------===//
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
//
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
//
//===----------------------------------------------------------------------===//
Fix Clang-tidy modernize-use-nullptr and modernize-use-default warnings in some files in source/Commands; other minor fixes. llvm-svn: 261389
2016-02-20 08:58:29 +08:00
#include "CommandObjectMemory.h"
[lldb][AArch64] Add "memory tag read" command This new command looks much like "memory read" and mirrors its basic behaviour. (lldb) memory tag read new_buf_ptr new_buf_ptr+32 Logical tag: 0x9 Allocation tags: [0x900fffff7ffa000, 0x900fffff7ffa010): 0x9 [0x900fffff7ffa010, 0x900fffff7ffa020): 0x0 Important proprties: * The end address is optional and defaults to reading 1 tag if ommitted * It is an error to try to read tags if the architecture or process doesn't support it, or if the range asked for is not tagged. * It is an error to read an inverted range (end < begin) (logical tags are removed for this check so you can pass tagged addresses here) * The range will be expanded to fit the tagging granule, so you can get more tags than simply (end-begin)/granule size. Whatever you get back will always cover the original range. Reviewed By: omjavaid Differential Revision: https://reviews.llvm.org/D97285
2021-02-20 00:31:46 +08:00
#include "CommandObjectMemoryTag.h"
Isolate Target-specific functionality of DataExtractor. In an effort to move the various DataBuffer / DataExtractor classes from Core -> Utility, we have to separate the low-level functionality from the higher level functionality. Only a few functions required anything other than reading/writing raw bytes, so those functions are separated out into a more appropriate area. Specifically, Dump() and DumpHexBytes() are moved into free functions in Core/DumpDataExtractor.cpp, and GetGNUEHPointer is moved into a static function in the only file that it's referenced from. Differential Revision: https://reviews.llvm.org/D30560 llvm-svn: 296910
2017-03-04 04:57:05 +08:00
#include "lldb/Core/DumpDataExtractor.h"
Since our expression parser needs to locate areas of memory that are not in use when you have a process that can't JIT code, like core file debugging, the core file process plug-ins should be able to override the Process::GetMemoryRegionInfo(...) function. In order to make this happen, I have added permissions to sections so that we can know what the permissions are for a given section, and modified both core file plug-ins to override Process::GetMemoryRegionInfo() and answer things correctly. llvm-svn: 272276
2016-06-10 00:34:06 +08:00
#include "lldb/Core/Section.h"
Added a new OptionValue subclass for lldb::Format: OptionValueFormat. Added new OptionGroup subclasses for: - output file for use with options: long opts: --outfile <path> --append--output short opts: -o <path> -A - format for use with options: long opts: --format <format> - variable object display controls for depth, pointer depth, wether to show types, show summary, show location, flat output, use objc "po" style summary. Modified ValueObjectMemory to be able to be created either with a TypeSP or a ClangASTType. Switched "memory read" over to use OptionGroup subclasses: one for the outfile options, one for the command specific options, and one for the format. llvm-svn: 130334
2011-04-28 06:04:39 +08:00
#include "lldb/Core/ValueObjectMemory.h"
[Expression] Add PersistentExpressionState::GetCompilerTypeFromPersistentDecl Summary: PersistentStateExpressions (e.g. ClangPersistentVariables) have the ability to define types using expressions that persist throughout the debugging session. GetCompilerTypeFromPersistentDecl is a useful operation to have if you need to use any of those persistently declared types, like in CommandObjectMemory. This decouples clang from CommandObjectMemory and decouples Plugins from Commands in general. Differential Revision: https://reviews.llvm.org/D62797 llvm-svn: 363183
2019-06-13 01:47:06 +08:00
#include "lldb/Expression/ExpressionVariable.h"
Delete some more dead includes. This breaks the cycle between Target and PluginLanguageC++, reducing the overall cycle count from 43 to 42. llvm-svn: 298561
2017-03-23 07:33:16 +08:00
#include "lldb/Host/OptionParser.h"
Since our expression parser needs to locate areas of memory that are not in use when you have a process that can't JIT code, like core file debugging, the core file process plug-ins should be able to override the Process::GetMemoryRegionInfo(...) function. In order to make this happen, I have added permissions to sections so that we can know what the permissions are for a given section, and modified both core file plug-ins to override Process::GetMemoryRegionInfo() and answer things correctly. llvm-svn: 272276
2016-06-10 00:34:06 +08:00
#include "lldb/Interpreter/CommandReturnObject.h"
Move Args::StringTo*** functions to a new OptionArgParser class Summary: The idea behind this is to move the functionality which depend on other lldb classes into a separate class. This way, the Args class can be turned into a lightweight arc+argv wrapper and moved into the lower lldb layers. Reviewers: jingham, zturner Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D44306 llvm-svn: 329677
2018-04-10 17:03:59 +08:00
#include "lldb/Interpreter/OptionArgParser.h"
Added a new OptionValue subclass for lldb::Format: OptionValueFormat. Added new OptionGroup subclasses for: - output file for use with options: long opts: --outfile <path> --append--output short opts: -o <path> -A - format for use with options: long opts: --format <format> - variable object display controls for depth, pointer depth, wether to show types, show summary, show location, flat output, use objc "po" style summary. Modified ValueObjectMemory to be able to be created either with a TypeSP or a ClangASTType. Switched "memory read" over to use OptionGroup subclasses: one for the outfile options, one for the command specific options, and one for the format. llvm-svn: 130334
2011-04-28 06:04:39 +08:00
#include "lldb/Interpreter/OptionGroupFormat.h"
[lldb] Change implementation of memory read --show-tags option This does 2 things: * Moves it after the short options. Which makes sense given it's a niche, default off option. (if 2 files for one option seems a bit much, I am going to reuse them for "memory find" later) * Fixes the use of repeated commands. For example: memory read buf --show-tags <shows tags> memory read <shows tags> Added tests for the repetition and updated existing help tests. Reviewed By: omjavaid Differential Revision: https://reviews.llvm.org/D125089
2022-04-14 18:56:44 +08:00
#include "lldb/Interpreter/OptionGroupMemoryTag.h"
Added a new OptionValue subclass for lldb::Format: OptionValueFormat. Added new OptionGroup subclasses for: - output file for use with options: long opts: --outfile <path> --append--output short opts: -o <path> -A - format for use with options: long opts: --format <format> - variable object display controls for depth, pointer depth, wether to show types, show summary, show location, flat output, use objc "po" style summary. Modified ValueObjectMemory to be able to be created either with a TypeSP or a ClangASTType. Switched "memory read" over to use OptionGroup subclasses: one for the outfile options, one for the command specific options, and one for the format. llvm-svn: 130334
2011-04-28 06:04:39 +08:00
#include "lldb/Interpreter/OptionGroupOutputFile.h"
Added the ability to specify dumping options (show types, show location, depth control, pointer depth, and more) when dumping memory and viewing as a type. llvm-svn: 130436
2011-04-29 04:55:26 +08:00
#include "lldb/Interpreter/OptionGroupValueObjectDisplay.h"
[Expression] Add PersistentExpressionState::GetCompilerTypeFromPersistentDecl Summary: PersistentStateExpressions (e.g. ClangPersistentVariables) have the ability to define types using expressions that persist throughout the debugging session. GetCompilerTypeFromPersistentDecl is a useful operation to have if you need to use any of those persistently declared types, like in CommandObjectMemory. This decouples clang from CommandObjectMemory and decouples Plugins from Commands in general. Differential Revision: https://reviews.llvm.org/D62797 llvm-svn: 363183
2019-06-13 01:47:06 +08:00
#include "lldb/Interpreter/OptionValueLanguage.h"
Reimplemented the code that backed the "settings" in lldb. There were many issues with the previous implementation: - no setting auto completion - very manual and error prone way of getting/setting variables - tons of code duplication - useless instance names for processes, threads Now settings can easily be defined like option values. The new settings makes use of the "OptionValue" classes so we can re-use the option value code that we use to set settings in command options. No more instances, just "does the right thing". llvm-svn: 162366
2012-08-23 01:17:09 +08:00
#include "lldb/Interpreter/OptionValueString.h"
Since our expression parser needs to locate areas of memory that are not in use when you have a process that can't JIT code, like core file debugging, the core file process plug-ins should be able to override the Process::GetMemoryRegionInfo(...) function. In order to make this happen, I have added permissions to sections so that we can know what the permissions are for a given section, and modified both core file plug-ins to override Process::GetMemoryRegionInfo() and answer things correctly. llvm-svn: 272276
2016-06-10 00:34:06 +08:00
#include "lldb/Interpreter/Options.h"
Now that SymbolFileDWARF supports having types in completely separate .pcm file with "-fmodules -gmodules", each SymbolFileDWARF can reference module DWARF info by looking in other DWARF files. Then if you have 1000 .o files that each reference one or more .pcm files in their debug info, a simple Module::FindTypes(...) call can end up searching the same .pcm file over and over and over. Now all internal FindTypes methods in classes (ModuleList, Module, SymbolFile) now take an extra argument: llvm::DenseSet<lldb_private::SymbolFile *> &searched_symbol_files Each time a SymbolFile::FindTypes() is called, it needs to check the searched_symbol_files list to make sure it hasn't already been asked to find the type and return immediately if it has been checked. This will stop circular dependencies from also crashing LLDB during type queries. This has proven to be an issue when debugging large applications on MacOSX that use DWARF in .o files. <rdar://problem/24581488> llvm-svn: 260434
2016-02-11 05:28:13 +08:00
#include "lldb/Symbol/SymbolFile.h"
Since our expression parser needs to locate areas of memory that are not in use when you have a process that can't JIT code, like core file debugging, the core file process plug-ins should be able to override the Process::GetMemoryRegionInfo(...) function. In order to make this happen, I have added permissions to sections so that we can know what the permissions are for a given section, and modified both core file plug-ins to override Process::GetMemoryRegionInfo() and answer things correctly. llvm-svn: 272276
2016-06-10 00:34:06 +08:00
#include "lldb/Symbol/TypeList.h"
[lldb] Remove non address bits from memory read arguments Addresses on AArch64 can have top byte tags, memory tags and pointer authentication signatures in the upper bits. While testing memory tagging I found that memory read couldn't read a range if the two addresses had different tags. The same could apply to signed pointers given the right circumstance. (lldb) memory read mte_buf_alt_tag mte_buf+16 error: end address (0x900fffff7ff8010) must be greater than the start address (0xa00fffff7ff8000). Or it would try to read a lot more memory than expected. (lldb) memory read mte_buf mte_buf_alt_tag+16 error: Normally, 'memory read' will not read over 1024 bytes of data. error: Please use --force to override this restriction just once. error: or set target.max-memory-read-size if you will often need a larger limit. Fix this by removing non address bits before we calculate the read range. A test is added for AArch64 Linux that confirms this by using the top byte ignore feature. This means that if you do read with a tagged pointer the output does not include those tags. This is potentially confusing but I think overall it's better that we don't pretend that we're reading memory from a range that the process is unable to map. (lldb) p ptr1 (char *) $4 = 0x3400fffffffff140 "\x80\xf1\xff\xff\xff\xff" (lldb) p ptr2 (char *) $5 = 0x5600fffffffff140 "\x80\xf1\xff\xff\xff\xff" (lldb) memory read ptr1 ptr2+16 0xfffffffff140: 80 f1 ff ff ff ff 00 00 38 70 bc f7 ff ff 00 00 ........8p...... Reviewed By: omjavaid, danielkiss Differential Revision: https://reviews.llvm.org/D103626
2021-11-03 20:10:40 +08:00
#include "lldb/Target/ABI.h"
[Expression] Add PersistentExpressionState::GetCompilerTypeFromPersistentDecl Summary: PersistentStateExpressions (e.g. ClangPersistentVariables) have the ability to define types using expressions that persist throughout the debugging session. GetCompilerTypeFromPersistentDecl is a useful operation to have if you need to use any of those persistently declared types, like in CommandObjectMemory. This decouples clang from CommandObjectMemory and decouples Plugins from Commands in general. Differential Revision: https://reviews.llvm.org/D62797 llvm-svn: 363183
2019-06-13 01:47:06 +08:00
#include "lldb/Target/Language.h"
ASan malloc/free history threads Reviewed at http://reviews.llvm.org/D4596 llvm-svn: 217116
2014-09-04 09:03:18 +08:00
#include "lldb/Target/MemoryHistory.h"
Since our expression parser needs to locate areas of memory that are not in use when you have a process that can't JIT code, like core file debugging, the core file process plug-ins should be able to override the Process::GetMemoryRegionInfo(...) function. In order to make this happen, I have added permissions to sections so that we can know what the permissions are for a given section, and modified both core file plug-ins to override Process::GetMemoryRegionInfo() and answer things correctly. llvm-svn: 272276
2016-06-10 00:34:06 +08:00
#include "lldb/Target/MemoryRegionInfo.h"
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
#include "lldb/Target/Process.h"
Roll back the changes I made in r193907 which created a new Frame pure virtual base class and made StackFrame a subclass of that. As I started to build on top of that arrangement today, I found that it wasn't working out like I intended. Instead I'll try sticking with the single StackFrame class -- there's too much code duplication to make a more complicated class hierarchy sensible I think. llvm-svn: 193983
2013-11-04 17:33:30 +08:00
#include "lldb/Target/StackFrame.h"
[Expression] Add PersistentExpressionState::GetCompilerTypeFromPersistentDecl Summary: PersistentStateExpressions (e.g. ClangPersistentVariables) have the ability to define types using expressions that persist throughout the debugging session. GetCompilerTypeFromPersistentDecl is a useful operation to have if you need to use any of those persistently declared types, like in CommandObjectMemory. This decouples clang from CommandObjectMemory and decouples Plugins from Commands in general. Differential Revision: https://reviews.llvm.org/D62797 llvm-svn: 363183
2019-06-13 01:47:06 +08:00
#include "lldb/Target/Target.h"
ASan malloc/free history threads Reviewed at http://reviews.llvm.org/D4596 llvm-svn: 217116
2014-09-04 09:03:18 +08:00
#include "lldb/Target/Thread.h"
Move Args.cpp from Interpreter to Utility Summary: The Args class is used in plenty of places besides the command interpreter (e.g., anything requiring an argc+argv combo, such as when launching a process), so it needs to be in a lower layer. Now that the class has no external dependencies, it can be moved down to the Utility module. This removes the last (direct) dependency from the Host module to Interpreter, so I remove the Interpreter module from Host's dependency list. Reviewers: zturner, jingham, davide Subscribers: mgorny, lldb-commits Differential Revision: https://reviews.llvm.org/D45480 llvm-svn: 330200
2018-04-18 02:53:35 +08:00
#include "lldb/Utility/Args.h"
Move DataBuffer / DataExtractor and friends from Core -> Utility. llvm-svn: 296943
2017-03-04 09:30:05 +08:00
#include "lldb/Utility/DataBufferHeap.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/Utility/StreamString.h"
[lldb] Remove [US]IntValueIsValidForSize from CommandObjectMemory Use llvm::is(U)IntN (MathExtras.h) instead.
2020-11-04 23:25:38 +08:00
#include "llvm/Support/MathExtras.h"
Use std::make_shared in LLDB (NFC) Unlike std::make_unique, which is only available since C++14, std::make_shared is available since C++11. Not only is std::make_shared a lot more readable compared to ::reset(new), it also performs a single heap allocation for the object and control block. Differential revision: https://reviews.llvm.org/D57990 llvm-svn: 353764
2019-02-12 07:13:08 +08:00
#include <cinttypes>
#include <memory>
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;
[lldb] Tablegenify expr/frame/log/register/memory llvm-svn: 367009
2019-07-25 19:22:46 +08:00
#define LLDB_OPTIONS_memory_read
#include "CommandOptions.inc"
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
Added a new OptionValue subclass for lldb::Format: OptionValueFormat. Added new OptionGroup subclasses for: - output file for use with options: long opts: --outfile <path> --append--output short opts: -o <path> -A - format for use with options: long opts: --format <format> - variable object display controls for depth, pointer depth, wether to show types, show summary, show location, flat output, use objc "po" style summary. Modified ValueObjectMemory to be able to be created either with a TypeSP or a ClangASTType. Switched "memory read" over to use OptionGroup subclasses: one for the outfile options, one for the command specific options, and one for the format. llvm-svn: 130334
2011-04-28 06:04:39 +08:00
class OptionGroupReadMemory : public OptionGroup {
public:
OptionGroupReadMemory()
[Commands] Remove redundant member initialization (NFC) Identified with readability-redundant-member-init.
2022-01-24 03:07:14 +08:00
: m_num_per_line(1, 1), m_offset(0, 0),
[Expression] Add PersistentExpressionState::GetCompilerTypeFromPersistentDecl Summary: PersistentStateExpressions (e.g. ClangPersistentVariables) have the ability to define types using expressions that persist throughout the debugging session. GetCompilerTypeFromPersistentDecl is a useful operation to have if you need to use any of those persistently declared types, like in CommandObjectMemory. This decouples clang from CommandObjectMemory and decouples Plugins from Commands in general. Differential Revision: https://reviews.llvm.org/D62797 llvm-svn: 363183
2019-06-13 01:47:06 +08:00
m_language_for_type(eLanguageTypeUnknown) {}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
Fix Clang-tidy modernize-use-nullptr and modernize-use-default warnings in some files in source/Commands; other minor fixes. llvm-svn: 261389
2016-02-20 08:58:29 +08:00
~OptionGroupReadMemory() override = default;
Convert option tables to ArrayRefs. This change is very mechanical. All it does is change the signature of `Options::GetDefinitions()` and `OptionGroup:: GetDefinitions()` to return an `ArrayRef<OptionDefinition>` instead of a `const OptionDefinition *`. In the case of the former, it deletes the sentinel entry from every table, and in the case of the latter, it removes the `GetNumDefinitions()` method from the interface. These are no longer necessary as `ArrayRef` carries its own length. In the former case, iteration was done by using a sentinel entry, so there was no knowledge of length. Because of this the individual option tables were allowed to be defined below the corresponding class (after all, only a pointer was needed). Now, however, the length must be known at compile time to construct the `ArrayRef`, and as a result it is necessary to move every option table before its corresponding class. This results in this CL looking very big, but in terms of substance there is not much here. Differential revision: https://reviews.llvm.org/D24834 llvm-svn: 282188
2016-09-23 04:22:55 +08:00
llvm::ArrayRef<OptionDefinition> GetDefinitions() override {
[lldb] Also include the array definition in CommandOptions.inc Summary: Right now our CommandOptions.inc only generates the initializer for the options list but not the array declaration boilerplate around it. As the array definition is identical for all arrays, we might as well also let the CommandOptions.inc generate it alongside the initializers. This patch will also allow us to generate additional declarations related to that option list in the future (e.g. a enum class representing the specific options which would make our handling code less prone). This patch also fixes a few option tables that didn't follow our naming style. Reviewers: JDevlieghere Reviewed By: JDevlieghere Subscribers: abidh, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D65331 llvm-svn: 367186
2019-07-28 14:24:07 +08:00
return llvm::makeArrayRef(g_memory_read_options);
Added a new OptionValue subclass for lldb::Format: OptionValueFormat. Added new OptionGroup subclasses for: - output file for use with options: long opts: --outfile <path> --append--output short opts: -o <path> -A - format for use with options: long opts: --format <format> - variable object display controls for depth, pointer depth, wether to show types, show summary, show location, flat output, use objc "po" style summary. Modified ValueObjectMemory to be able to be created either with a TypeSP or a ClangASTType. Switched "memory read" over to use OptionGroup subclasses: one for the outfile options, one for the command specific options, and one for the format. llvm-svn: 130334
2011-04-28 06:04:39 +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
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 SetOptionValue(uint32_t option_idx, llvm::StringRef option_value,
ExecutionContext *execution_context) override {
Status error;
[lldb] Also include the array definition in CommandOptions.inc Summary: Right now our CommandOptions.inc only generates the initializer for the options list but not the array declaration boilerplate around it. As the array definition is identical for all arrays, we might as well also let the CommandOptions.inc generate it alongside the initializers. This patch will also allow us to generate additional declarations related to that option list in the future (e.g. a enum class representing the specific options which would make our handling code less prone). This patch also fixes a few option tables that didn't follow our naming style. Reviewers: JDevlieghere Reviewed By: JDevlieghere Subscribers: abidh, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D65331 llvm-svn: 367186
2019-07-28 14:24:07 +08:00
const int short_option = g_memory_read_options[option_idx].short_option;
*** 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 a new OptionValue subclass for lldb::Format: OptionValueFormat. Added new OptionGroup subclasses for: - output file for use with options: long opts: --outfile <path> --append--output short opts: -o <path> -A - format for use with options: long opts: --format <format> - variable object display controls for depth, pointer depth, wether to show types, show summary, show location, flat output, use objc "po" style summary. Modified ValueObjectMemory to be able to be created either with a TypeSP or a ClangASTType. Switched "memory read" over to use OptionGroup subclasses: one for the outfile options, one for the command specific options, and one for the format. llvm-svn: 130334
2011-04-28 06:04:39 +08:00
switch (short_option) {
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
case 'l':
Update OptionGroup::SetValue to take StringRef. Then deal with all the fallout. Differential Revision: https://reviews.llvm.org/D24847 llvm-svn: 282265
2016-09-24 01:48:13 +08:00
error = m_num_per_line.SetValueFromString(option_value);
Added a new OptionValue subclass for lldb::Format: OptionValueFormat. Added new OptionGroup subclasses for: - output file for use with options: long opts: --outfile <path> --append--output short opts: -o <path> -A - format for use with options: long opts: --format <format> - variable object display controls for depth, pointer depth, wether to show types, show summary, show location, flat output, use objc "po" style summary. Modified ValueObjectMemory to be able to be created either with a TypeSP or a ClangASTType. Switched "memory read" over to use OptionGroup subclasses: one for the outfile options, one for the command specific options, and one for the format. llvm-svn: 130334
2011-04-28 06:04:39 +08:00
if (m_num_per_line.GetCurrentValue() == 0)
Cleaned up many error codes. For any who is filling in error strings into lldb_private::Error objects the rules are: - short strings that don't start with a capitol letter unless the name is a class or anything else that is always capitolized - no trailing newline character - should be one line if possible Implemented a first pass at adding "--gdb-format" support to anything that accepts format with optional size/count. llvm-svn: 142999
2011-10-26 08:56:27 +08:00
error.SetErrorStringWithFormat(
Update OptionGroup::SetValue to take StringRef. Then deal with all the fallout. Differential Revision: https://reviews.llvm.org/D24847 llvm-svn: 282265
2016-09-24 01:48:13 +08:00
"invalid value for --num-per-line option '%s'",
option_value.str().c_str());
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
break;
*** 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 new options to memory read to allow saving memory to disk as binary bytes or as an ASCII text dump. - The output file is specified with the "--outfile FILE" option. - The memory can be appended to an existing file using the "--append" option. - The memory will be written as an ASCII text dump by default, or as binary with the "--binary" option. Added new options to memory write to allow writing all or part of a file on disk to target memory: - The input file is specified using the "--infile FILE" option - The offset at which to start in the file defaults to zero, but can be overridden using the "--offset OFFSET" option. If the size is not specified, the remaining number of bytes in the file will be used as the default byte size. - The number of bytes to write defaults to the entire file byte size, but can be changed with the "--size COUNT" option. llvm-svn: 116172
2010-10-11 04:52:20 +08:00
case 'b':
m_output_as_binary = true;
break;
*** 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 a new OptionValue subclass for lldb::Format: OptionValueFormat. Added new OptionGroup subclasses for: - output file for use with options: long opts: --outfile <path> --append--output short opts: -o <path> -A - format for use with options: long opts: --format <format> - variable object display controls for depth, pointer depth, wether to show types, show summary, show location, flat output, use objc "po" style summary. Modified ValueObjectMemory to be able to be created either with a TypeSP or a ClangASTType. Switched "memory read" over to use OptionGroup subclasses: one for the outfile options, one for the command specific options, and one for the format. llvm-svn: 130334
2011-04-28 06:04:39 +08:00
case 't':
Update OptionGroup::SetValue to take StringRef. Then deal with all the fallout. Differential Revision: https://reviews.llvm.org/D24847 llvm-svn: 282265
2016-09-24 01:48:13 +08:00
error = m_view_as_type.SetValueFromString(option_value);
Added new options to memory read to allow saving memory to disk as binary bytes or as an ASCII text dump. - The output file is specified with the "--outfile FILE" option. - The memory can be appended to an existing file using the "--append" option. - The memory will be written as an ASCII text dump by default, or as binary with the "--binary" option. Added new options to memory write to allow writing all or part of a file on disk to target memory: - The input file is specified using the "--infile FILE" option - The offset at which to start in the file defaults to zero, but can be overridden using the "--offset OFFSET" option. If the size is not specified, the remaining number of bytes in the file will be used as the default byte size. - The number of bytes to write defaults to the entire file byte size, but can be changed with the "--size COUNT" option. llvm-svn: 116172
2010-10-11 04:52:20 +08:00
break;
*** 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 a --force option to "memory read," disallowing reads over 1KiB in total size unless the user explicitly allows them. llvm-svn: 155750
2012-04-28 09:27:38 +08:00
case 'r':
m_force = true;
break;
*** 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
[Expression] Add PersistentExpressionState::GetCompilerTypeFromPersistentDecl Summary: PersistentStateExpressions (e.g. ClangPersistentVariables) have the ability to define types using expressions that persist throughout the debugging session. GetCompilerTypeFromPersistentDecl is a useful operation to have if you need to use any of those persistently declared types, like in CommandObjectMemory. This decouples clang from CommandObjectMemory and decouples Plugins from Commands in general. Differential Revision: https://reviews.llvm.org/D62797 llvm-svn: 363183
2019-06-13 01:47:06 +08:00
case 'x':
error = m_language_for_type.SetValueFromString(option_value);
break;
Fix TestMemoryRead after r252035 llvm-svn: 252065
2015-11-05 03:32:01 +08:00
case 'E':
Update OptionGroup::SetValue to take StringRef. Then deal with all the fallout. Differential Revision: https://reviews.llvm.org/D24847 llvm-svn: 282265
2016-09-24 01:48:13 +08:00
error = m_offset.SetValueFromString(option_value);
Add a --offset option to memory read that allows one to specify, given a type, how many sizeof(type) bytes to speak before starting to read memory llvm-svn: 251668
2015-10-30 07:40:24 +08:00
break;
*** 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
default:
[lldb][NFC] Remove dead code that is supposed to handle invalid command options Summary: We currently have a bunch of code that is supposed to handle invalid command options, but all this code is unreachable because invalid options are already handled in `Options::Parse`. The only way we can reach this code is when we declare but then not implement an option (which will be made impossible with D65386, which is also when we can completely remove the `default` cases). This patch replaces all this code with `llvm_unreachable` to make clear this is dead code that can't be reached. Reviewers: JDevlieghere Reviewed By: JDevlieghere Subscribers: lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D66522 llvm-svn: 369625
2019-08-22 16:08:05 +08:00
llvm_unreachable("Unimplemented option");
Added a new OptionValue subclass for lldb::Format: OptionValueFormat. Added new OptionGroup subclasses for: - output file for use with options: long opts: --outfile <path> --append--output short opts: -o <path> -A - format for use with options: long opts: --format <format> - variable object display controls for depth, pointer depth, wether to show types, show summary, show location, flat output, use objc "po" style summary. Modified ValueObjectMemory to be able to be created either with a TypeSP or a ClangASTType. Switched "memory read" over to use OptionGroup subclasses: one for the outfile options, one for the command specific options, and one for the format. llvm-svn: 130334
2011-04-28 06:04:39 +08:00
}
Added the ability to specify dumping options (show types, show location, depth control, pointer depth, and more) when dumping memory and viewing as a type. llvm-svn: 130436
2011-04-29 04:55:26 +08:00
return error;
*** 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
}
Updated all commands that use a "--format" / "-f" options to use the new OptionGroupFormat. Updated OptionGroupFormat to be able to also use the "--size" and "--count" options. Commands that use a OptionGroupFormat instance can choose which of the options they want by initializing OptionGroupFormat accordingly. Clients can either get only the "--format", "--format" + "--size", or "--format" + "--size" + "--count". This is in preparation for upcoming chnages where there are alternate ways (GDB format specification) to set a format. llvm-svn: 142911
2011-10-25 14:44:01 +08:00
void OptionParsingStarting(ExecutionContext *execution_context) override {
m_num_per_line.Clear();
m_output_as_binary = false;
Added a new OptionValue subclass for lldb::Format: OptionValueFormat. Added new OptionGroup subclasses for: - output file for use with options: long opts: --outfile <path> --append--output short opts: -o <path> -A - format for use with options: long opts: --format <format> - variable object display controls for depth, pointer depth, wether to show types, show summary, show location, flat output, use objc "po" style summary. Modified ValueObjectMemory to be able to be created either with a TypeSP or a ClangASTType. Switched "memory read" over to use OptionGroup subclasses: one for the outfile options, one for the command specific options, and one for the format. llvm-svn: 130334
2011-04-28 06:04:39 +08:00
m_view_as_type.Clear();
Updated all commands that use a "--format" / "-f" options to use the new OptionGroupFormat. Updated OptionGroupFormat to be able to also use the "--size" and "--count" options. Commands that use a OptionGroupFormat instance can choose which of the options they want by initializing OptionGroupFormat accordingly. Clients can either get only the "--format", "--format" + "--size", or "--format" + "--size" + "--count". This is in preparation for upcoming chnages where there are alternate ways (GDB format specification) to set a format. llvm-svn: 142911
2011-10-25 14:44:01 +08:00
m_force = false;
m_offset.Clear();
[Expression] Add PersistentExpressionState::GetCompilerTypeFromPersistentDecl Summary: PersistentStateExpressions (e.g. ClangPersistentVariables) have the ability to define types using expressions that persist throughout the debugging session. GetCompilerTypeFromPersistentDecl is a useful operation to have if you need to use any of those persistently declared types, like in CommandObjectMemory. This decouples clang from CommandObjectMemory and decouples Plugins from Commands in general. Differential Revision: https://reviews.llvm.org/D62797 llvm-svn: 363183
2019-06-13 01:47:06 +08:00
m_language_for_type.Clear();
*** 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
}
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 FinalizeSettings(Target *target, OptionGroupFormat &format_options) {
Status error;
Updated all commands that use a "--format" / "-f" options to use the new OptionGroupFormat. Updated OptionGroupFormat to be able to also use the "--size" and "--count" options. Commands that use a OptionGroupFormat instance can choose which of the options they want by initializing OptionGroupFormat accordingly. Clients can either get only the "--format", "--format" + "--size", or "--format" + "--size" + "--count". This is in preparation for upcoming chnages where there are alternate ways (GDB format specification) to set a format. llvm-svn: 142911
2011-10-25 14:44:01 +08:00
OptionValueUInt64 &byte_size_value = format_options.GetByteSizeValue();
OptionValueUInt64 &count_value = format_options.GetCountValue();
Cleaned up many error codes. For any who is filling in error strings into lldb_private::Error objects the rules are: - short strings that don't start with a capitol letter unless the name is a class or anything else that is always capitolized - no trailing newline character - should be one line if possible Implemented a first pass at adding "--gdb-format" support to anything that accepts format with optional size/count. llvm-svn: 142999
2011-10-26 08:56:27 +08:00
const bool byte_size_option_set = byte_size_value.OptionWasSet();
Updated all commands that use a "--format" / "-f" options to use the new OptionGroupFormat. Updated OptionGroupFormat to be able to also use the "--size" and "--count" options. Commands that use a OptionGroupFormat instance can choose which of the options they want by initializing OptionGroupFormat accordingly. Clients can either get only the "--format", "--format" + "--size", or "--format" + "--size" + "--count". This is in preparation for upcoming chnages where there are alternate ways (GDB format specification) to set a format. llvm-svn: 142911
2011-10-25 14:44:01 +08:00
const bool num_per_line_option_set = m_num_per_line.OptionWasSet();
const bool count_option_set = format_options.GetCountValue().OptionWasSet();
*** 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 a new OptionValue subclass for lldb::Format: OptionValueFormat. Added new OptionGroup subclasses for: - output file for use with options: long opts: --outfile <path> --append--output short opts: -o <path> -A - format for use with options: long opts: --format <format> - variable object display controls for depth, pointer depth, wether to show types, show summary, show location, flat output, use objc "po" style summary. Modified ValueObjectMemory to be able to be created either with a TypeSP or a ClangASTType. Switched "memory read" over to use OptionGroup subclasses: one for the outfile options, one for the command specific options, and one for the format. llvm-svn: 130334
2011-04-28 06:04:39 +08:00
switch (format_options.GetFormat()) {
default:
break;
*** 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 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 eFormatBoolean:
if (!byte_size_option_set)
Updated all commands that use a "--format" / "-f" options to use the new OptionGroupFormat. Updated OptionGroupFormat to be able to also use the "--size" and "--count" options. Commands that use a OptionGroupFormat instance can choose which of the options they want by initializing OptionGroupFormat accordingly. Clients can either get only the "--format", "--format" + "--size", or "--format" + "--size" + "--count". This is in preparation for upcoming chnages where there are alternate ways (GDB format specification) to set a format. llvm-svn: 142911
2011-10-25 14:44:01 +08:00
byte_size_value = 1;
Added the ability to specify dumping options (show types, show location, depth control, pointer depth, and more) when dumping memory and viewing as a type. llvm-svn: 130436
2011-04-29 04:55:26 +08:00
if (!num_per_line_option_set)
m_num_per_line = 1;
if (!count_option_set)
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
format_options.GetCountValue() = 8;
break;
*** 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
case eFormatCString:
*** 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
break;
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 eFormatInstruction:
if (count_option_set)
byte_size_value = target->GetArchitecture().GetMaximumOpcodeByteSize();
m_num_per_line = 1;
break;
*** 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 a new OptionValue subclass for lldb::Format: OptionValueFormat. Added new OptionGroup subclasses for: - output file for use with options: long opts: --outfile <path> --append--output short opts: -o <path> -A - format for use with options: long opts: --format <format> - variable object display controls for depth, pointer depth, wether to show types, show summary, show location, flat output, use objc "po" style summary. Modified ValueObjectMemory to be able to be created either with a TypeSP or a ClangASTType. Switched "memory read" over to use OptionGroup subclasses: one for the outfile options, one for the command specific options, and one for the format. llvm-svn: 130334
2011-04-28 06:04:39 +08:00
case eFormatAddressInfo:
if (!byte_size_option_set)
Updated all commands that use a "--format" / "-f" options to use the new OptionGroupFormat. Updated OptionGroupFormat to be able to also use the "--size" and "--count" options. Commands that use a OptionGroupFormat instance can choose which of the options they want by initializing OptionGroupFormat accordingly. Clients can either get only the "--format", "--format" + "--size", or "--format" + "--size" + "--count". This is in preparation for upcoming chnages where there are alternate ways (GDB format specification) to set a format. llvm-svn: 142911
2011-10-25 14:44:01 +08:00
byte_size_value = target->GetArchitecture().GetAddressByteSize();
Added the ability to specify dumping options (show types, show location, depth control, pointer depth, and more) when dumping memory and viewing as a type. llvm-svn: 130436
2011-04-29 04:55:26 +08:00
m_num_per_line = 1;
if (!count_option_set)
Updated all commands that use a "--format" / "-f" options to use the new OptionGroupFormat. Updated OptionGroupFormat to be able to also use the "--size" and "--count" options. Commands that use a OptionGroupFormat instance can choose which of the options they want by initializing OptionGroupFormat accordingly. Clients can either get only the "--format", "--format" + "--size", or "--format" + "--size" + "--count". This is in preparation for upcoming chnages where there are alternate ways (GDB format specification) to set a format. llvm-svn: 142911
2011-10-25 14:44:01 +08:00
format_options.GetCountValue() = 8;
Added a new OptionValue subclass for lldb::Format: OptionValueFormat. Added new OptionGroup subclasses for: - output file for use with options: long opts: --outfile <path> --append--output short opts: -o <path> -A - format for use with options: long opts: --format <format> - variable object display controls for depth, pointer depth, wether to show types, show summary, show location, flat output, use objc "po" style summary. Modified ValueObjectMemory to be able to be created either with a TypeSP or a ClangASTType. Switched "memory read" over to use OptionGroup subclasses: one for the outfile options, one for the command specific options, and one for the format. llvm-svn: 130334
2011-04-28 06:04:39 +08:00
break;
*** 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 a new OptionValue subclass for lldb::Format: OptionValueFormat. Added new OptionGroup subclasses for: - output file for use with options: long opts: --outfile <path> --append--output short opts: -o <path> -A - format for use with options: long opts: --format <format> - variable object display controls for depth, pointer depth, wether to show types, show summary, show location, flat output, use objc "po" style summary. Modified ValueObjectMemory to be able to be created either with a TypeSP or a ClangASTType. Switched "memory read" over to use OptionGroup subclasses: one for the outfile options, one for the command specific options, and one for the format. llvm-svn: 130334
2011-04-28 06:04:39 +08:00
case eFormatPointer:
Updated all commands that use a "--format" / "-f" options to use the new OptionGroupFormat. Updated OptionGroupFormat to be able to also use the "--size" and "--count" options. Commands that use a OptionGroupFormat instance can choose which of the options they want by initializing OptionGroupFormat accordingly. Clients can either get only the "--format", "--format" + "--size", or "--format" + "--size" + "--count". This is in preparation for upcoming chnages where there are alternate ways (GDB format specification) to set a format. llvm-svn: 142911
2011-10-25 14:44:01 +08:00
byte_size_value = target->GetArchitecture().GetAddressByteSize();
Added the ability to specify dumping options (show types, show location, depth control, pointer depth, and more) when dumping memory and viewing as a type. llvm-svn: 130436
2011-04-29 04:55:26 +08:00
if (!num_per_line_option_set)
m_num_per_line = 4;
if (!count_option_set)
Updated all commands that use a "--format" / "-f" options to use the new OptionGroupFormat. Updated OptionGroupFormat to be able to also use the "--size" and "--count" options. Commands that use a OptionGroupFormat instance can choose which of the options they want by initializing OptionGroupFormat accordingly. Clients can either get only the "--format", "--format" + "--size", or "--format" + "--size" + "--count". This is in preparation for upcoming chnages where there are alternate ways (GDB format specification) to set a format. llvm-svn: 142911
2011-10-25 14:44:01 +08:00
format_options.GetCountValue() = 8;
Added a new OptionValue subclass for lldb::Format: OptionValueFormat. Added new OptionGroup subclasses for: - output file for use with options: long opts: --outfile <path> --append--output short opts: -o <path> -A - format for use with options: long opts: --format <format> - variable object display controls for depth, pointer depth, wether to show types, show summary, show location, flat output, use objc "po" style summary. Modified ValueObjectMemory to be able to be created either with a TypeSP or a ClangASTType. Switched "memory read" over to use OptionGroup subclasses: one for the outfile options, one for the command specific options, and one for the format. llvm-svn: 130334
2011-04-28 06:04:39 +08:00
break;
*** 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 a new OptionValue subclass for lldb::Format: OptionValueFormat. Added new OptionGroup subclasses for: - output file for use with options: long opts: --outfile <path> --append--output short opts: -o <path> -A - format for use with options: long opts: --format <format> - variable object display controls for depth, pointer depth, wether to show types, show summary, show location, flat output, use objc "po" style summary. Modified ValueObjectMemory to be able to be created either with a TypeSP or a ClangASTType. Switched "memory read" over to use OptionGroup subclasses: one for the outfile options, one for the command specific options, and one for the format. llvm-svn: 130334
2011-04-28 06:04:39 +08:00
case eFormatBinary:
case eFormatFloat:
case eFormatOctal:
case eFormatDecimal:
case eFormatEnum:
Add char8_t support (C++20) This patch adds support for the char8_t type introduced in C++20 char8_t. The original patch was submitted by James Blachly on the LLDB mailing list [1]. I modified the patch a bit and added a test. [1] http://lists.llvm.org/pipermail/lldb-dev/2019-August/015393.html Differential revision: https://reviews.llvm.org/D66447 llvm-svn: 369582
2019-08-22 05:30:55 +08:00
case eFormatUnicode8:
Added a new OptionValue subclass for lldb::Format: OptionValueFormat. Added new OptionGroup subclasses for: - output file for use with options: long opts: --outfile <path> --append--output short opts: -o <path> -A - format for use with options: long opts: --format <format> - variable object display controls for depth, pointer depth, wether to show types, show summary, show location, flat output, use objc "po" style summary. Modified ValueObjectMemory to be able to be created either with a TypeSP or a ClangASTType. Switched "memory read" over to use OptionGroup subclasses: one for the outfile options, one for the command specific options, and one for the format. llvm-svn: 130334
2011-04-28 06:04:39 +08:00
case eFormatUnicode16:
case eFormatUnicode32:
case eFormatUnsigned:
case eFormatHexFloat:
Cleaned up many error codes. For any who is filling in error strings into lldb_private::Error objects the rules are: - short strings that don't start with a capitol letter unless the name is a class or anything else that is always capitolized - no trailing newline character - should be one line if possible Implemented a first pass at adding "--gdb-format" support to anything that accepts format with optional size/count. llvm-svn: 142999
2011-10-26 08:56:27 +08:00
if (!byte_size_option_set)
Updated all commands that use a "--format" / "-f" options to use the new OptionGroupFormat. Updated OptionGroupFormat to be able to also use the "--size" and "--count" options. Commands that use a OptionGroupFormat instance can choose which of the options they want by initializing OptionGroupFormat accordingly. Clients can either get only the "--format", "--format" + "--size", or "--format" + "--size" + "--count". This is in preparation for upcoming chnages where there are alternate ways (GDB format specification) to set a format. llvm-svn: 142911
2011-10-25 14:44:01 +08:00
byte_size_value = 4;
Added the ability to specify dumping options (show types, show location, depth control, pointer depth, and more) when dumping memory and viewing as a type. llvm-svn: 130436
2011-04-29 04:55:26 +08:00
if (!num_per_line_option_set)
m_num_per_line = 1;
if (!count_option_set)
Updated all commands that use a "--format" / "-f" options to use the new OptionGroupFormat. Updated OptionGroupFormat to be able to also use the "--size" and "--count" options. Commands that use a OptionGroupFormat instance can choose which of the options they want by initializing OptionGroupFormat accordingly. Clients can either get only the "--format", "--format" + "--size", or "--format" + "--size" + "--count". This is in preparation for upcoming chnages where there are alternate ways (GDB format specification) to set a format. llvm-svn: 142911
2011-10-25 14:44:01 +08:00
format_options.GetCountValue() = 8;
Added a new OptionValue subclass for lldb::Format: OptionValueFormat. Added new OptionGroup subclasses for: - output file for use with options: long opts: --outfile <path> --append--output short opts: -o <path> -A - format for use with options: long opts: --format <format> - variable object display controls for depth, pointer depth, wether to show types, show summary, show location, flat output, use objc "po" style summary. Modified ValueObjectMemory to be able to be created either with a TypeSP or a ClangASTType. Switched "memory read" over to use OptionGroup subclasses: one for the outfile options, one for the command specific options, and one for the format. llvm-svn: 130334
2011-04-28 06:04:39 +08:00
break;
*** 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 a new format for displaying an array of characters: eFormatCharArray This us useful because sometomes you have to show a single character as: 'a' (using eFormatChar) and other times you might have an array of single charcters for display as: 'a' 'b' 'c', and other times you might want to show the contents of buffer of characters that can contain non printable chars: "\0\x22\n123". This also fixes an issue that currently happens when you have a single character C string (const char *a = "a"; or char b[1] = { 'b' };) that was being output as "'a'" incorrectly due to the way the eFormatChar format output worked. llvm-svn: 133316
2011-06-18 07:50:44 +08:00
case eFormatBytes:
Added a new OptionValue subclass for lldb::Format: OptionValueFormat. Added new OptionGroup subclasses for: - output file for use with options: long opts: --outfile <path> --append--output short opts: -o <path> -A - format for use with options: long opts: --format <format> - variable object display controls for depth, pointer depth, wether to show types, show summary, show location, flat output, use objc "po" style summary. Modified ValueObjectMemory to be able to be created either with a TypeSP or a ClangASTType. Switched "memory read" over to use OptionGroup subclasses: one for the outfile options, one for the command specific options, and one for the format. llvm-svn: 130334
2011-04-28 06:04:39 +08:00
case eFormatBytesWithASCII:
Added the ability to specify dumping options (show types, show location, depth control, pointer depth, and more) when dumping memory and viewing as a type. llvm-svn: 130436
2011-04-29 04:55:26 +08:00
if (byte_size_option_set) {
Updated all commands that use a "--format" / "-f" options to use the new OptionGroupFormat. Updated OptionGroupFormat to be able to also use the "--size" and "--count" options. Commands that use a OptionGroupFormat instance can choose which of the options they want by initializing OptionGroupFormat accordingly. Clients can either get only the "--format", "--format" + "--size", or "--format" + "--size" + "--count". This is in preparation for upcoming chnages where there are alternate ways (GDB format specification) to set a format. llvm-svn: 142911
2011-10-25 14:44:01 +08:00
if (byte_size_value > 1)
LLDB help content has accumulated over time without a recent attempt to review it for consistency, accuracy, and clarity. These changes attempt to address all of the above while keeping the text relatively terse. <rdar://problem/24868841> llvm-svn: 275485
2016-07-15 06:03:10 +08:00
error.SetErrorStringWithFormat(
"display format (bytes/bytes with ASCII) conflicts with the "
"specified byte size %" PRIu64 "\n"
"\tconsider using a different display format or don't specify "
"the byte size.",
byte_size_value.GetCurrentValue());
*** 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
Updated all commands that use a "--format" / "-f" options to use the new OptionGroupFormat. Updated OptionGroupFormat to be able to also use the "--size" and "--count" options. Commands that use a OptionGroupFormat instance can choose which of the options they want by initializing OptionGroupFormat accordingly. Clients can either get only the "--format", "--format" + "--size", or "--format" + "--size" + "--count". This is in preparation for upcoming chnages where there are alternate ways (GDB format specification) to set a format. llvm-svn: 142911
2011-10-25 14:44:01 +08:00
byte_size_value = 1;
Added the ability to specify dumping options (show types, show location, depth control, pointer depth, and more) when dumping memory and viewing as a type. llvm-svn: 130436
2011-04-29 04:55:26 +08:00
if (!num_per_line_option_set)
m_num_per_line = 16;
if (!count_option_set)
Updated all commands that use a "--format" / "-f" options to use the new OptionGroupFormat. Updated OptionGroupFormat to be able to also use the "--size" and "--count" options. Commands that use a OptionGroupFormat instance can choose which of the options they want by initializing OptionGroupFormat accordingly. Clients can either get only the "--format", "--format" + "--size", or "--format" + "--size" + "--count". This is in preparation for upcoming chnages where there are alternate ways (GDB format specification) to set a format. llvm-svn: 142911
2011-10-25 14:44:01 +08:00
format_options.GetCountValue() = 32;
Set the correct byte size for complex integer (-fI) memory reads. <rdar://problem/12281172> llvm-svn: 177814
2013-03-23 13:16:54 +08:00
break;
*** 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 a new format for displaying an array of characters: eFormatCharArray This us useful because sometomes you have to show a single character as: 'a' (using eFormatChar) and other times you might have an array of single charcters for display as: 'a' 'b' 'c', and other times you might want to show the contents of buffer of characters that can contain non printable chars: "\0\x22\n123". This also fixes an issue that currently happens when you have a single character C string (const char *a = "a"; or char b[1] = { 'b' };) that was being output as "'a'" incorrectly due to the way the eFormatChar format output worked. llvm-svn: 133316
2011-06-18 07:50:44 +08:00
case eFormatCharArray:
Set the correct byte size for complex integer (-fI) memory reads. <rdar://problem/12281172> llvm-svn: 177814
2013-03-23 13:16:54 +08:00
case eFormatChar:
case eFormatCharPrintable:
if (!byte_size_option_set)
byte_size_value = 1;
if (!num_per_line_option_set)
m_num_per_line = 32;
if (!count_option_set)
format_options.GetCountValue() = 64;
Added a new OptionValue subclass for lldb::Format: OptionValueFormat. Added new OptionGroup subclasses for: - output file for use with options: long opts: --outfile <path> --append--output short opts: -o <path> -A - format for use with options: long opts: --format <format> - variable object display controls for depth, pointer depth, wether to show types, show summary, show location, flat output, use objc "po" style summary. Modified ValueObjectMemory to be able to be created either with a TypeSP or a ClangASTType. Switched "memory read" over to use OptionGroup subclasses: one for the outfile options, one for the command specific options, and one for the format. llvm-svn: 130334
2011-04-28 06:04:39 +08:00
break;
*** 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 a new OptionValue subclass for lldb::Format: OptionValueFormat. Added new OptionGroup subclasses for: - output file for use with options: long opts: --outfile <path> --append--output short opts: -o <path> -A - format for use with options: long opts: --format <format> - variable object display controls for depth, pointer depth, wether to show types, show summary, show location, flat output, use objc "po" style summary. Modified ValueObjectMemory to be able to be created either with a TypeSP or a ClangASTType. Switched "memory read" over to use OptionGroup subclasses: one for the outfile options, one for the command specific options, and one for the format. llvm-svn: 130334
2011-04-28 06:04:39 +08:00
case eFormatComplex:
Added the ability to specify dumping options (show types, show location, depth control, pointer depth, and more) when dumping memory and viewing as a type. llvm-svn: 130436
2011-04-29 04:55:26 +08:00
if (!byte_size_option_set)
Updated all commands that use a "--format" / "-f" options to use the new OptionGroupFormat. Updated OptionGroupFormat to be able to also use the "--size" and "--count" options. Commands that use a OptionGroupFormat instance can choose which of the options they want by initializing OptionGroupFormat accordingly. Clients can either get only the "--format", "--format" + "--size", or "--format" + "--size" + "--count". This is in preparation for upcoming chnages where there are alternate ways (GDB format specification) to set a format. llvm-svn: 142911
2011-10-25 14:44:01 +08:00
byte_size_value = 8;
Added the ability to specify dumping options (show types, show location, depth control, pointer depth, and more) when dumping memory and viewing as a type. llvm-svn: 130436
2011-04-29 04:55:26 +08:00
if (!num_per_line_option_set)
m_num_per_line = 1;
if (!count_option_set)
format_options.GetCountValue() = 8;
break;
*** 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 specify dumping options (show types, show location, depth control, pointer depth, and more) when dumping memory and viewing as a type. llvm-svn: 130436
2011-04-29 04:55:26 +08:00
case eFormatComplexInteger:
if (!byte_size_option_set)
byte_size_value = 8;
if (!num_per_line_option_set)
m_num_per_line = 1;
if (!count_option_set)
Updated all commands that use a "--format" / "-f" options to use the new OptionGroupFormat. Updated OptionGroupFormat to be able to also use the "--size" and "--count" options. Commands that use a OptionGroupFormat instance can choose which of the options they want by initializing OptionGroupFormat accordingly. Clients can either get only the "--format", "--format" + "--size", or "--format" + "--size" + "--count". This is in preparation for upcoming chnages where there are alternate ways (GDB format specification) to set a format. llvm-svn: 142911
2011-10-25 14:44:01 +08:00
format_options.GetCountValue() = 8;
Added a new OptionValue subclass for lldb::Format: OptionValueFormat. Added new OptionGroup subclasses for: - output file for use with options: long opts: --outfile <path> --append--output short opts: -o <path> -A - format for use with options: long opts: --format <format> - variable object display controls for depth, pointer depth, wether to show types, show summary, show location, flat output, use objc "po" style summary. Modified ValueObjectMemory to be able to be created either with a TypeSP or a ClangASTType. Switched "memory read" over to use OptionGroup subclasses: one for the outfile options, one for the command specific options, and one for the format. llvm-svn: 130334
2011-04-28 06:04:39 +08:00
break;
*** 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 a new OptionValue subclass for lldb::Format: OptionValueFormat. Added new OptionGroup subclasses for: - output file for use with options: long opts: --outfile <path> --append--output short opts: -o <path> -A - format for use with options: long opts: --format <format> - variable object display controls for depth, pointer depth, wether to show types, show summary, show location, flat output, use objc "po" style summary. Modified ValueObjectMemory to be able to be created either with a TypeSP or a ClangASTType. Switched "memory read" over to use OptionGroup subclasses: one for the outfile options, one for the command specific options, and one for the format. llvm-svn: 130334
2011-04-28 06:04:39 +08:00
case eFormatHex:
if (!byte_size_option_set)
byte_size_value = 4;
Added the ability to specify dumping options (show types, show location, depth control, pointer depth, and more) when dumping memory and viewing as a type. llvm-svn: 130436
2011-04-29 04:55:26 +08:00
if (!num_per_line_option_set) {
Updated all commands that use a "--format" / "-f" options to use the new OptionGroupFormat. Updated OptionGroupFormat to be able to also use the "--size" and "--count" options. Commands that use a OptionGroupFormat instance can choose which of the options they want by initializing OptionGroupFormat accordingly. Clients can either get only the "--format", "--format" + "--size", or "--format" + "--size" + "--count". This is in preparation for upcoming chnages where there are alternate ways (GDB format specification) to set a format. llvm-svn: 142911
2011-10-25 14:44:01 +08:00
switch (byte_size_value) {
case 1:
*** 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
case 2:
Updated all commands that use a "--format" / "-f" options to use the new OptionGroupFormat. Updated OptionGroupFormat to be able to also use the "--size" and "--count" options. Commands that use a OptionGroupFormat instance can choose which of the options they want by initializing OptionGroupFormat accordingly. Clients can either get only the "--format", "--format" + "--size", or "--format" + "--size" + "--count". This is in preparation for upcoming chnages where there are alternate ways (GDB format specification) to set a format. llvm-svn: 142911
2011-10-25 14:44:01 +08:00
m_num_per_line = 8;
*** 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
break;
case 4:
Added the ability to specify dumping options (show types, show location, depth control, pointer depth, and more) when dumping memory and viewing as a type. llvm-svn: 130436
2011-04-29 04:55:26 +08:00
m_num_per_line = 4;
Updated all commands that use a "--format" / "-f" options to use the new OptionGroupFormat. Updated OptionGroupFormat to be able to also use the "--size" and "--count" options. Commands that use a OptionGroupFormat instance can choose which of the options they want by initializing OptionGroupFormat accordingly. Clients can either get only the "--format", "--format" + "--size", or "--format" + "--size" + "--count". This is in preparation for upcoming chnages where there are alternate ways (GDB format specification) to set a format. llvm-svn: 142911
2011-10-25 14:44:01 +08:00
break;
Added the ability to specify dumping options (show types, show location, depth control, pointer depth, and more) when dumping memory and viewing as a type. llvm-svn: 130436
2011-04-29 04:55:26 +08:00
case 8:
m_num_per_line = 2;
*** 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
break;
default:
Added the ability to specify dumping options (show types, show location, depth control, pointer depth, and more) when dumping memory and viewing as a type. llvm-svn: 130436
2011-04-29 04:55:26 +08:00
m_num_per_line = 1;
Added a new OptionValue subclass for lldb::Format: OptionValueFormat. Added new OptionGroup subclasses for: - output file for use with options: long opts: --outfile <path> --append--output short opts: -o <path> -A - format for use with options: long opts: --format <format> - variable object display controls for depth, pointer depth, wether to show types, show summary, show location, flat output, use objc "po" style summary. Modified ValueObjectMemory to be able to be created either with a TypeSP or a ClangASTType. Switched "memory read" over to use OptionGroup subclasses: one for the outfile options, one for the command specific options, and one for the format. llvm-svn: 130334
2011-04-28 06:04:39 +08:00
break;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +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
}
Added the ability to specify dumping options (show types, show location, depth control, pointer depth, and more) when dumping memory and viewing as a type. llvm-svn: 130436
2011-04-29 04:55:26 +08:00
if (!count_option_set)
Updated all commands that use a "--format" / "-f" options to use the new OptionGroupFormat. Updated OptionGroupFormat to be able to also use the "--size" and "--count" options. Commands that use a OptionGroupFormat instance can choose which of the options they want by initializing OptionGroupFormat accordingly. Clients can either get only the "--format", "--format" + "--size", or "--format" + "--size" + "--count". This is in preparation for upcoming chnages where there are alternate ways (GDB format specification) to set a format. llvm-svn: 142911
2011-10-25 14:44:01 +08:00
count_value = 8;
Added the ability to specify dumping options (show types, show location, depth control, pointer depth, and more) when dumping memory and viewing as a type. llvm-svn: 130436
2011-04-29 04:55:26 +08:00
break;
*** 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 specify dumping options (show types, show location, depth control, pointer depth, and more) when dumping memory and viewing as a type. llvm-svn: 130436
2011-04-29 04:55:26 +08:00
case eFormatVectorOfChar:
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
case eFormatVectorOfSInt8:
Added a new OptionValue subclass for lldb::Format: OptionValueFormat. Added new OptionGroup subclasses for: - output file for use with options: long opts: --outfile <path> --append--output short opts: -o <path> -A - format for use with options: long opts: --format <format> - variable object display controls for depth, pointer depth, wether to show types, show summary, show location, flat output, use objc "po" style summary. Modified ValueObjectMemory to be able to be created either with a TypeSP or a ClangASTType. Switched "memory read" over to use OptionGroup subclasses: one for the outfile options, one for the command specific options, and one for the format. llvm-svn: 130334
2011-04-28 06:04:39 +08:00
case eFormatVectorOfUInt8:
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
case eFormatVectorOfSInt16:
Added a new OptionValue subclass for lldb::Format: OptionValueFormat. Added new OptionGroup subclasses for: - output file for use with options: long opts: --outfile <path> --append--output short opts: -o <path> -A - format for use with options: long opts: --format <format> - variable object display controls for depth, pointer depth, wether to show types, show summary, show location, flat output, use objc "po" style summary. Modified ValueObjectMemory to be able to be created either with a TypeSP or a ClangASTType. Switched "memory read" over to use OptionGroup subclasses: one for the outfile options, one for the command specific options, and one for the format. llvm-svn: 130334
2011-04-28 06:04:39 +08:00
case eFormatVectorOfUInt16:
case eFormatVectorOfSInt32:
case eFormatVectorOfUInt32:
case eFormatVectorOfSInt64:
case eFormatVectorOfUInt64:
Resubmit: RenderScript command for printing allocation contents Previous commit r250281 broke TestDataFormatterSmartArray.py Resolved in in this patch by adding the new enum eFormatVectorOfFloat16 to FormatManager. Differential Revision: http://reviews.llvm.org/D13730 llvm-svn: 250499
2015-10-16 16:28:47 +08:00
case eFormatVectorOfFloat16:
Added a new OptionValue subclass for lldb::Format: OptionValueFormat. Added new OptionGroup subclasses for: - output file for use with options: long opts: --outfile <path> --append--output short opts: -o <path> -A - format for use with options: long opts: --format <format> - variable object display controls for depth, pointer depth, wether to show types, show summary, show location, flat output, use objc "po" style summary. Modified ValueObjectMemory to be able to be created either with a TypeSP or a ClangASTType. Switched "memory read" over to use OptionGroup subclasses: one for the outfile options, one for the command specific options, and one for the format. llvm-svn: 130334
2011-04-28 06:04:39 +08:00
case eFormatVectorOfFloat32:
case eFormatVectorOfFloat64:
case eFormatVectorOfUInt128:
Added the ability to specify dumping options (show types, show location, depth control, pointer depth, and more) when dumping memory and viewing as a type. llvm-svn: 130436
2011-04-29 04:55:26 +08:00
if (!byte_size_option_set)
Updated all commands that use a "--format" / "-f" options to use the new OptionGroupFormat. Updated OptionGroupFormat to be able to also use the "--size" and "--count" options. Commands that use a OptionGroupFormat instance can choose which of the options they want by initializing OptionGroupFormat accordingly. Clients can either get only the "--format", "--format" + "--size", or "--format" + "--size" + "--count". This is in preparation for upcoming chnages where there are alternate ways (GDB format specification) to set a format. llvm-svn: 142911
2011-10-25 14:44:01 +08:00
byte_size_value = 128;
Added the ability to specify dumping options (show types, show location, depth control, pointer depth, and more) when dumping memory and viewing as a type. llvm-svn: 130436
2011-04-29 04:55:26 +08:00
if (!num_per_line_option_set)
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
m_num_per_line = 1;
Added the ability to specify dumping options (show types, show location, depth control, pointer depth, and more) when dumping memory and viewing as a type. llvm-svn: 130436
2011-04-29 04:55:26 +08:00
if (!count_option_set)
Updated all commands that use a "--format" / "-f" options to use the new OptionGroupFormat. Updated OptionGroupFormat to be able to also use the "--size" and "--count" options. Commands that use a OptionGroupFormat instance can choose which of the options they want by initializing OptionGroupFormat accordingly. Clients can either get only the "--format", "--format" + "--size", or "--format" + "--size" + "--count". This is in preparation for upcoming chnages where there are alternate ways (GDB format specification) to set a format. llvm-svn: 142911
2011-10-25 14:44:01 +08:00
count_value = 4;
*** 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
break;
Added a new OptionValue subclass for lldb::Format: OptionValueFormat. Added new OptionGroup subclasses for: - output file for use with options: long opts: --outfile <path> --append--output short opts: -o <path> -A - format for use with options: long opts: --format <format> - variable object display controls for depth, pointer depth, wether to show types, show summary, show location, flat output, use objc "po" style summary. Modified ValueObjectMemory to be able to be created either with a TypeSP or a ClangASTType. Switched "memory read" over to use OptionGroup subclasses: one for the outfile options, one for the command specific options, and one for the format. llvm-svn: 130334
2011-04-28 06:04:39 +08:00
}
return error;
*** 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
A simple fix for the GDB format strings so the byte size parameter gets properly marked as valid. Also modified the "memory read" command to be able to intelligently repeat subsequent memory requests, so now you can do: (lldb) memory read --format hex --count 32 0x1000 Then hit enter to keep viewing the memory that follows the last valid request. llvm-svn: 143015
2011-10-26 12:32:38 +08:00
bool AnyOptionWasSet() const {
return m_num_per_line.OptionWasSet() || m_output_as_binary ||
[Expression] Add PersistentExpressionState::GetCompilerTypeFromPersistentDecl Summary: PersistentStateExpressions (e.g. ClangPersistentVariables) have the ability to define types using expressions that persist throughout the debugging session. GetCompilerTypeFromPersistentDecl is a useful operation to have if you need to use any of those persistently declared types, like in CommandObjectMemory. This decouples clang from CommandObjectMemory and decouples Plugins from Commands in general. Differential Revision: https://reviews.llvm.org/D62797 llvm-svn: 363183
2019-06-13 01:47:06 +08:00
m_view_as_type.OptionWasSet() || m_offset.OptionWasSet() ||
m_language_for_type.OptionWasSet();
A simple fix for the GDB format strings so the byte size parameter gets properly marked as valid. Also modified the "memory read" command to be able to intelligently repeat subsequent memory requests, so now you can do: (lldb) memory read --format hex --count 32 0x1000 Then hit enter to keep viewing the memory that follows the last valid request. llvm-svn: 143015
2011-10-26 12:32:38 +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
Added a new OptionValue subclass for lldb::Format: OptionValueFormat. Added new OptionGroup subclasses for: - output file for use with options: long opts: --outfile <path> --append--output short opts: -o <path> -A - format for use with options: long opts: --format <format> - variable object display controls for depth, pointer depth, wether to show types, show summary, show location, flat output, use objc "po" style summary. Modified ValueObjectMemory to be able to be created either with a TypeSP or a ClangASTType. Switched "memory read" over to use OptionGroup subclasses: one for the outfile options, one for the command specific options, and one for the format. llvm-svn: 130334
2011-04-28 06:04:39 +08:00
OptionValueUInt64 m_num_per_line;
bool m_output_as_binary = false;
OptionValueString m_view_as_type;
Added a --force option to "memory read," disallowing reads over 1KiB in total size unless the user explicitly allows them. llvm-svn: 155750
2012-04-28 09:27:38 +08:00
bool m_force;
Add a --offset option to memory read that allows one to specify, given a type, how many sizeof(type) bytes to speak before starting to read memory llvm-svn: 251668
2015-10-30 07:40:24 +08:00
OptionValueUInt64 m_offset;
[Expression] Add PersistentExpressionState::GetCompilerTypeFromPersistentDecl Summary: PersistentStateExpressions (e.g. ClangPersistentVariables) have the ability to define types using expressions that persist throughout the debugging session. GetCompilerTypeFromPersistentDecl is a useful operation to have if you need to use any of those persistently declared types, like in CommandObjectMemory. This decouples clang from CommandObjectMemory and decouples Plugins from Commands in general. Differential Revision: https://reviews.llvm.org/D62797 llvm-svn: 363183
2019-06-13 01:47:06 +08:00
OptionValueLanguage m_language_for_type;
Added a new OptionValue subclass for lldb::Format: OptionValueFormat. Added new OptionGroup subclasses for: - output file for use with options: long opts: --outfile <path> --append--output short opts: -o <path> -A - format for use with options: long opts: --format <format> - variable object display controls for depth, pointer depth, wether to show types, show summary, show location, flat output, use objc "po" style summary. Modified ValueObjectMemory to be able to be created either with a TypeSP or a ClangASTType. Switched "memory read" over to use OptionGroup subclasses: one for the outfile options, one for the command specific options, and one for the format. llvm-svn: 130334
2011-04-28 06:04:39 +08:00
};
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
Added a new OptionValue subclass for lldb::Format: OptionValueFormat. Added new OptionGroup subclasses for: - output file for use with options: long opts: --outfile <path> --append--output short opts: -o <path> -A - format for use with options: long opts: --format <format> - variable object display controls for depth, pointer depth, wether to show types, show summary, show location, flat output, use objc "po" style summary. Modified ValueObjectMemory to be able to be created either with a TypeSP or a ClangASTType. Switched "memory read" over to use OptionGroup subclasses: one for the outfile options, one for the command specific options, and one for the format. llvm-svn: 130334
2011-04-28 06:04:39 +08:00
// Read memory from the inferior process
Make raw & parsed commands subclasses of CommandObject rather than having the raw version implement an Execute which was never going to get run and another ExecuteRawCommandString. Took the knowledge of how to prepare raw & parsed commands out of CommandInterpreter and put it in CommandObject where it belongs. Also took all the cases where there were the subcommands of Multiword commands declared in the .h file for the overall command and moved them into the .cpp file. Made the CommandObject flags work for raw as well as parsed commands. Made "expr" use the flags so that it requires you to be paused to run "expr". llvm-svn: 158235
2012-06-09 05:56:10 +08:00
class CommandObjectMemoryRead : public CommandObjectParsed {
Added a new OptionValue subclass for lldb::Format: OptionValueFormat. Added new OptionGroup subclasses for: - output file for use with options: long opts: --outfile <path> --append--output short opts: -o <path> -A - format for use with options: long opts: --format <format> - variable object display controls for depth, pointer depth, wether to show types, show summary, show location, flat output, use objc "po" style summary. Modified ValueObjectMemory to be able to be created either with a TypeSP or a ClangASTType. Switched "memory read" over to use OptionGroup subclasses: one for the outfile options, one for the command specific options, and one for the format. llvm-svn: 130334
2011-04-28 06:04:39 +08:00
public:
LLDB help content has accumulated over time without a recent attempt to review it for consistency, accuracy, and clarity. These changes attempt to address all of the above while keeping the text relatively terse. <rdar://problem/24868841> llvm-svn: 275485
2016-07-15 06:03:10 +08:00
CommandObjectMemoryRead(CommandInterpreter &interpreter)
: CommandObjectParsed(
interpreter, "memory read",
"Read from the memory of the current target process.", nullptr,
eCommandRequiresTarget | eCommandProcessMustBePaused),
[Commands] Remove redundant member initialization (NFC) Identified with readability-redundant-member-init.
2022-01-24 03:07:14 +08:00
m_format_options(eFormatBytesWithASCII, 1, 8),
[lldb] Add --show-tags option to "memory find" This is off by default. If you get a result and that memory has memory tags, when --show-tags is given you'll see the tags inline with the memory content. ``` (lldb) memory read mte_buf mte_buf+64 --show-tags <...> 0xfffff7ff8020: 00 00 00 00 00 00 00 00 0d f0 fe ca 00 00 00 00 ................ (tag: 0x2) <...> (lldb) memory find -e 0xcafef00d mte_buf mte_buf+64 --show-tags data found at location: 0xfffff7ff8028 0xfffff7ff8028: 0d f0 fe ca 00 00 00 00 00 00 00 00 00 00 00 00 ................ (tags: 0x2 0x3) 0xfffff7ff8038: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ (tags: 0x3 0x4) ``` The logic for handling alignments is the same as for memory read so in the above example because the line starts misaligned to the granule it covers 2 granules. Depends on D125089 Reviewed By: omjavaid Differential Revision: https://reviews.llvm.org/D125090
2022-04-13 21:32:18 +08:00
m_memory_tag_options(/*note_binary=*/true),
[Commands] Remove redundant member initialization (NFC) Identified with readability-redundant-member-init.
2022-01-24 03:07:14 +08:00
m_prev_format_options(eFormatBytesWithASCII, 1, 8) {
Modify existing commands with arguments to use the new argument mechanism (for standardized argument names, argument help, etc.) llvm-svn: 115570
2010-10-05 06:28:36 +08:00
CommandArgumentEntry arg1;
CommandArgumentEntry arg2;
Updated all commands that use a "--format" / "-f" options to use the new OptionGroupFormat. Updated OptionGroupFormat to be able to also use the "--size" and "--count" options. Commands that use a OptionGroupFormat instance can choose which of the options they want by initializing OptionGroupFormat accordingly. Clients can either get only the "--format", "--format" + "--size", or "--format" + "--size" + "--count". This is in preparation for upcoming chnages where there are alternate ways (GDB format specification) to set a format. llvm-svn: 142911
2011-10-25 14:44:01 +08:00
CommandArgumentData start_addr_arg;
Added the ability to specify dumping options (show types, show location, depth control, pointer depth, and more) when dumping memory and viewing as a type. llvm-svn: 130436
2011-04-29 04:55:26 +08:00
CommandArgumentData end_addr_arg;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
Fix Clang-tidy modernize-use-nullptr and modernize-use-default warnings in some files in source/Commands; other minor fixes. llvm-svn: 261389
2016-02-20 08:58:29 +08:00
// Define the first (and only) variant of this arg.
start_addr_arg.arg_type = eArgTypeAddressOrExpression;
Modify existing commands with arguments to use the new argument mechanism (for standardized argument names, argument help, etc.) llvm-svn: 115570
2010-10-05 06:28:36 +08:00
start_addr_arg.arg_repetition = eArgRepeatPlain;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
commands: Use override instead of virtual. Summary: This removes all uses of virtual on functions where override could be used, including on destructors. It also adds override where virtual was previously missing. Reviewers: clayborg, labath Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D13503 llvm-svn: 249564
2015-10-08 00:56:17 +08:00
// There is only one variant this argument could be; put it into the
Modify existing commands with arguments to use the new argument mechanism (for standardized argument names, argument help, etc.) llvm-svn: 115570
2010-10-05 06:28:36 +08:00
// argument entry.
Added a new OptionValue subclass for lldb::Format: OptionValueFormat. Added new OptionGroup subclasses for: - output file for use with options: long opts: --outfile <path> --append--output short opts: -o <path> -A - format for use with options: long opts: --format <format> - variable object display controls for depth, pointer depth, wether to show types, show summary, show location, flat output, use objc "po" style summary. Modified ValueObjectMemory to be able to be created either with a TypeSP or a ClangASTType. Switched "memory read" over to use OptionGroup subclasses: one for the outfile options, one for the command specific options, and one for the format. llvm-svn: 130334
2011-04-28 06:04:39 +08:00
arg1.push_back(start_addr_arg);
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
commands: Use override instead of virtual. Summary: This removes all uses of virtual on functions where override could be used, including on destructors. It also adds override where virtual was previously missing. Reviewers: clayborg, labath Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D13503 llvm-svn: 249564
2015-10-08 00:56:17 +08:00
// Define the first (and only) variant of this arg.
<rdar://problem/12552374> Replacing the address argument type with address-expression in cases where StringToAddress() is used, and hence an expression can be passed where previously only a numeric address was allowed This makes the documentation more clear and helps users discover that they can truly pass in an expression in these situations. llvm-svn: 173753
2013-01-29 09:48:30 +08:00
end_addr_arg.arg_type = eArgTypeAddressOrExpression;
Modify existing commands with arguments to use the new argument mechanism (for standardized argument names, argument help, etc.) llvm-svn: 115570
2010-10-05 06:28:36 +08:00
end_addr_arg.arg_repetition = eArgRepeatOptional;
*** 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
commands: Use override instead of virtual. Summary: This removes all uses of virtual on functions where override could be used, including on destructors. It also adds override where virtual was previously missing. Reviewers: clayborg, labath Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D13503 llvm-svn: 249564
2015-10-08 00:56:17 +08:00
// There is only one variant this argument could be; put it into the
Modify existing commands with arguments to use the new argument mechanism (for standardized argument names, argument help, etc.) llvm-svn: 115570
2010-10-05 06:28:36 +08:00
// argument entry.
arg2.push_back(end_addr_arg);
*** 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
commands: Use override instead of virtual. Summary: This removes all uses of virtual on functions where override could be used, including on destructors. It also adds override where virtual was previously missing. Reviewers: clayborg, labath Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D13503 llvm-svn: 249564
2015-10-08 00:56:17 +08:00
// Push the data for the first argument into the m_arguments vector.
Modify existing commands with arguments to use the new argument mechanism (for standardized argument names, argument help, etc.) llvm-svn: 115570
2010-10-05 06:28:36 +08:00
m_arguments.push_back(arg1);
<rdar://problem/14322677> Implement a "memory find" command for LLDB This is still fairly rough around the edges but works well enough for simple scenarios where a chunk of text or a number are to be found within a certain range of memory, as in mem find `buffer` `buffer+0x1000` -s "me" -c 5 -r llvm-svn: 194544
2013-11-13 10:18:44 +08:00
m_arguments.push_back(arg2);
*** 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
commands: Use override instead of virtual. Summary: This removes all uses of virtual on functions where override could be used, including on destructors. It also adds override where virtual was previously missing. Reviewers: clayborg, labath Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D13503 llvm-svn: 249564
2015-10-08 00:56:17 +08:00
// Add the "--format" and "--count" options to group 1 and 3
Updated all commands that use a "--format" / "-f" options to use the new OptionGroupFormat. Updated OptionGroupFormat to be able to also use the "--size" and "--count" options. Commands that use a OptionGroupFormat instance can choose which of the options they want by initializing OptionGroupFormat accordingly. Clients can either get only the "--format", "--format" + "--size", or "--format" + "--size" + "--count". This is in preparation for upcoming chnages where there are alternate ways (GDB format specification) to set a format. llvm-svn: 142911
2011-10-25 14:44:01 +08:00
m_option_group.Append(&m_format_options,
OptionGroupFormat::OPTION_GROUP_FORMAT |
OptionGroupFormat::OPTION_GROUP_COUNT,
<rdar://problem/10033754> Fixed an issue with the options for memory read where --count couldn't be used with the --binary option when writing data to a file. Also removed the GDB format option from the --binary version of memory read. llvm-svn: 145067
2011-11-23 02:07:35 +08:00
LLDB_OPT_SET_1 | LLDB_OPT_SET_2 | LLDB_OPT_SET_3);
Updated all commands that use a "--format" / "-f" options to use the new OptionGroupFormat. Updated OptionGroupFormat to be able to also use the "--size" and "--count" options. Commands that use a OptionGroupFormat instance can choose which of the options they want by initializing OptionGroupFormat accordingly. Clients can either get only the "--format", "--format" + "--size", or "--format" + "--size" + "--count". This is in preparation for upcoming chnages where there are alternate ways (GDB format specification) to set a format. llvm-svn: 142911
2011-10-25 14:44:01 +08:00
m_option_group.Append(&m_format_options,
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
OptionGroupFormat::OPTION_GROUP_GDB_FMT,
<rdar://problem/10033754> Fixed an issue with the options for memory read where --count couldn't be used with the --binary option when writing data to a file. Also removed the GDB format option from the --binary version of memory read. llvm-svn: 145067
2011-11-23 02:07:35 +08:00
LLDB_OPT_SET_1 | LLDB_OPT_SET_3);
Updated all commands that use a "--format" / "-f" options to use the new OptionGroupFormat. Updated OptionGroupFormat to be able to also use the "--size" and "--count" options. Commands that use a OptionGroupFormat instance can choose which of the options they want by initializing OptionGroupFormat accordingly. Clients can either get only the "--format", "--format" + "--size", or "--format" + "--size" + "--count". This is in preparation for upcoming chnages where there are alternate ways (GDB format specification) to set a format. llvm-svn: 142911
2011-10-25 14:44:01 +08:00
// Add the "--size" option to group 1 and 2
m_option_group.Append(&m_format_options,
OptionGroupFormat::OPTION_GROUP_SIZE,
LLDB_OPT_SET_1 | LLDB_OPT_SET_2);
Added a new OptionValue subclass for lldb::Format: OptionValueFormat. Added new OptionGroup subclasses for: - output file for use with options: long opts: --outfile <path> --append--output short opts: -o <path> -A - format for use with options: long opts: --format <format> - variable object display controls for depth, pointer depth, wether to show types, show summary, show location, flat output, use objc "po" style summary. Modified ValueObjectMemory to be able to be created either with a TypeSP or a ClangASTType. Switched "memory read" over to use OptionGroup subclasses: one for the outfile options, one for the command specific options, and one for the format. llvm-svn: 130334
2011-04-28 06:04:39 +08:00
m_option_group.Append(&m_memory_options);
m_option_group.Append(&m_outfile_options, LLDB_OPT_SET_ALL,
<rdar://problem/10033754> Fixed an issue with the options for memory read where --count couldn't be used with the --binary option when writing data to a file. Also removed the GDB format option from the --binary version of memory read. llvm-svn: 145067
2011-11-23 02:07:35 +08:00
LLDB_OPT_SET_1 | LLDB_OPT_SET_2 | LLDB_OPT_SET_3);
Added the ability to specify dumping options (show types, show location, depth control, pointer depth, and more) when dumping memory and viewing as a type. llvm-svn: 130436
2011-04-29 04:55:26 +08:00
m_option_group.Append(&m_varobj_options, LLDB_OPT_SET_ALL, LLDB_OPT_SET_3);
[lldb] Change implementation of memory read --show-tags option This does 2 things: * Moves it after the short options. Which makes sense given it's a niche, default off option. (if 2 files for one option seems a bit much, I am going to reuse them for "memory find" later) * Fixes the use of repeated commands. For example: memory read buf --show-tags <shows tags> memory read <shows tags> Added tests for the repetition and updated existing help tests. Reviewed By: omjavaid Differential Revision: https://reviews.llvm.org/D125089
2022-04-14 18:56:44 +08:00
m_option_group.Append(&m_memory_tag_options, LLDB_OPT_SET_ALL,
LLDB_OPT_SET_ALL);
commands: Use override instead of virtual. Summary: This removes all uses of virtual on functions where override could be used, including on destructors. It also adds override where virtual was previously missing. Reviewers: clayborg, labath Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D13503 llvm-svn: 249564
2015-10-08 00:56:17 +08:00
m_option_group.Finalize();
*** 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
}
commands: Use override instead of virtual. Summary: This removes all uses of virtual on functions where override could be used, including on destructors. It also adds override where virtual was previously missing. Reviewers: clayborg, labath Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D13503 llvm-svn: 249564
2015-10-08 00:56:17 +08:00
~CommandObjectMemoryRead() override = default;
*** 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/14393032> DumpValueObject() 2.0 This checkin restores pre-Xcode5 functionality to the "po" (expr -O) command: - expr now has a new --description-verbosity (-v) argument, which takes either compact or full as a value (-v is the same as -vfull) When the full mode is on, "po" will show the extended output with type name, persistent variable name and value, as in (lldb) expr -O -v -- foo (id) $0 = 0x000000010010baf0 { 1 = 2; 2 = 3; } When -v is omitted, or -vcompact is passed, the Xcode5-style output will be shown, as in (lldb) expr -O -- foo { 1 = 2; 2 = 3; } - for a non-ObjectiveC object, LLDB will still try to retrieve a summary and/or value to display (lldb) po 5 5 -v also works in this mode (lldb) expr -O -vfull -- 5 (int) $4 = 5 On top of that, this is a major refactoring of the ValueObject printing code. The functionality is now factored into a ValueObjectPrinter class for easier maintenance in the future DumpValueObject() was turned into an instance method ValueObject::Dump() which simply calls through to the printer code, Dump_Impl has been removed Test case to follow llvm-svn: 191694
2013-10-01 03:11:51 +08:00
Options *GetOptions() override { return &m_option_group; }
*** 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 a repeat command option for "thread backtrace --count N". This way if you have a long stack, you can issue "thread backtrace --count 10" and then subsequent <Return>-s will page you through the stack. This took a little more effort than just adding the repeat command, since the GetRepeatCommand API was returning a "const char *". That meant the command had to keep the repeat string alive, which is inconvenient. The original API returned either a nullptr, or a const char *, so I changed the private API to return an llvm::Optional<std::string>. Most of the patch is propagating that change. Also, there was a little thinko in fetching the repeat command. We don't fetch repeat commands for commands that aren't being added to history, which is in general reasonable. And we don't add repeat commands to the history - also reasonable. But we do want the repeat command to be able to generate the NEXT repeat command. So I adjusted the logic in HandleCommand to work that way. Differential Revision: https://reviews.llvm.org/D119046
2022-02-05 07:16:31 +08:00
llvm::Optional<std::string> GetRepeatCommand(Args &current_command_args,
uint32_t index) override {
return m_cmd_name;
A simple fix for the GDB format strings so the byte size parameter gets properly marked as valid. Also modified the "memory read" command to be able to intelligently repeat subsequent memory requests, so now you can do: (lldb) memory read --format hex --count 32 0x1000 Then hit enter to keep viewing the memory that follows the last valid request. llvm-svn: 143015
2011-10-26 12:32:38 +08:00
}
Make raw & parsed commands subclasses of CommandObject rather than having the raw version implement an Execute which was never going to get run and another ExecuteRawCommandString. Took the knowledge of how to prepare raw & parsed commands out of CommandInterpreter and put it in CommandObject where it belongs. Also took all the cases where there were the subcommands of Multiword commands declared in the .h file for the overall command and moved them into the .cpp file. Made the CommandObject flags work for raw as well as parsed commands. Made "expr" use the flags so that it requires you to be paused to run "expr". llvm-svn: 158235
2012-06-09 05:56:10 +08:00
protected:
commands: Use override instead of virtual. Summary: This removes all uses of virtual on functions where override could be used, including on destructors. It also adds override where virtual was previously missing. Reviewers: clayborg, labath Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D13503 llvm-svn: 249564
2015-10-08 00:56:17 +08:00
bool DoExecute(Args &command, CommandReturnObject &result) override {
Add support for custom commands to set flags on themselves This works for Python commands defined via a class (implement get_flags on your class) and C++ plugin commands (which can call SBCommand::GetFlags()/SetFlags()) Flags allow features such as not letting the command run if there's no target, or if the process is not stopped, ... Commands could always check for these things themselves, but having these accessible via flags makes custom commands more consistent with built-in ones llvm-svn: 238286
2015-05-27 13:04:35 +08:00
// No need to check "target" for validity as eCommandRequiresTarget ensures
// it is valid
Expanded the flags that can be set for a command object in lldb_private::CommandObject. This list of available flags are: enum { //---------------------------------------------------------------------- // eFlagRequiresTarget // // Ensures a valid target is contained in m_exe_ctx prior to executing // the command. If a target doesn't exist or is invalid, the command // will fail and CommandObject::GetInvalidTargetDescription() will be // returned as the error. CommandObject subclasses can override the // virtual function for GetInvalidTargetDescription() to provide custom // strings when needed. //---------------------------------------------------------------------- eFlagRequiresTarget = (1u << 0), //---------------------------------------------------------------------- // eFlagRequiresProcess // // Ensures a valid process is contained in m_exe_ctx prior to executing // the command. If a process doesn't exist or is invalid, the command // will fail and CommandObject::GetInvalidProcessDescription() will be // returned as the error. CommandObject subclasses can override the // virtual function for GetInvalidProcessDescription() to provide custom // strings when needed. //---------------------------------------------------------------------- eFlagRequiresProcess = (1u << 1), //---------------------------------------------------------------------- // eFlagRequiresThread // // Ensures a valid thread is contained in m_exe_ctx prior to executing // the command. If a thread doesn't exist or is invalid, the command // will fail and CommandObject::GetInvalidThreadDescription() will be // returned as the error. CommandObject subclasses can override the // virtual function for GetInvalidThreadDescription() to provide custom // strings when needed. //---------------------------------------------------------------------- eFlagRequiresThread = (1u << 2), //---------------------------------------------------------------------- // eFlagRequiresFrame // // Ensures a valid frame is contained in m_exe_ctx prior to executing // the command. If a frame doesn't exist or is invalid, the command // will fail and CommandObject::GetInvalidFrameDescription() will be // returned as the error. CommandObject subclasses can override the // virtual function for GetInvalidFrameDescription() to provide custom // strings when needed. //---------------------------------------------------------------------- eFlagRequiresFrame = (1u << 3), //---------------------------------------------------------------------- // eFlagRequiresRegContext // // Ensures a valid register context (from the selected frame if there // is a frame in m_exe_ctx, or from the selected thread from m_exe_ctx) // is availble from m_exe_ctx prior to executing the command. If a // target doesn't exist or is invalid, the command will fail and // CommandObject::GetInvalidRegContextDescription() will be returned as // the error. CommandObject subclasses can override the virtual function // for GetInvalidRegContextDescription() to provide custom strings when // needed. //---------------------------------------------------------------------- eFlagRequiresRegContext = (1u << 4), //---------------------------------------------------------------------- // eFlagTryTargetAPILock // // Attempts to acquire the target lock if a target is selected in the // command interpreter. If the command object fails to acquire the API // lock, the command will fail with an appropriate error message. //---------------------------------------------------------------------- eFlagTryTargetAPILock = (1u << 5), //---------------------------------------------------------------------- // eFlagProcessMustBeLaunched // // Verifies that there is a launched process in m_exe_ctx, if there // isn't, the command will fail with an appropriate error message. //---------------------------------------------------------------------- eFlagProcessMustBeLaunched = (1u << 6), //---------------------------------------------------------------------- // eFlagProcessMustBePaused // // Verifies that there is a paused process in m_exe_ctx, if there // isn't, the command will fail with an appropriate error message. //---------------------------------------------------------------------- eFlagProcessMustBePaused = (1u << 7) }; Now each command object contains a "ExecutionContext m_exe_ctx;" member variable that gets initialized prior to running the command. The validity of the target objects in m_exe_ctx are checked to ensure that any target/process/thread/frame/reg context that are required are valid prior to executing the command. Each command object also contains a Mutex::Locker m_api_locker which gets used if eFlagTryTargetAPILock is set. This centralizes a lot of checking code that was previously and inconsistently implemented across many commands. llvm-svn: 171990
2013-01-10 03:44:40 +08:00
Target *target = m_exe_ctx.GetTargetPtr();
*** 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
const size_t argc = command.GetArgumentCount();
*** 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
A simple fix for the GDB format strings so the byte size parameter gets properly marked as valid. Also modified the "memory read" command to be able to intelligently repeat subsequent memory requests, so now you can do: (lldb) memory read --format hex --count 32 0x1000 Then hit enter to keep viewing the memory that follows the last valid request. llvm-svn: 143015
2011-10-26 12:32:38 +08:00
if ((argc == 0 && m_next_addr == LLDB_INVALID_ADDRESS) || argc > 2) {
<rdar://problem/12820334> I modified the "Args::StringtoAddress(...)" function to be able to evaluate address expressions. This is now used for any command line arguments or options that takes addresses like: memory read <addr> [<end-addr>] memory write <addr> breakpoint set --address <addr> disassemble --start-address <addr> --end-address <addr> It calls the expression parser to evaluate the address expression and will also work around the issue where the compiler doesn't like to add offsets to function pointers (which is what happens when you try to evaluate "main + 12"). So there is a temp fix in the Args::StringtoAddress() to work around this until we can get special compiler support for debug expressions with function pointers. llvm-svn: 169556
2012-12-07 06:49:16 +08:00
result.AppendErrorWithFormat("%s takes a start address expression with "
"an optional end address expression.\n",
m_cmd_name.c_str());
[lldb] Prevent double new lines behind errors/warning/messages from LLDB commands The current API for printing errors/warnings/messages from LLDB commands sometimes adds newlines behind the messages for the caller. However, this happens unconditionally so when the caller already specified a trailing newline in the error message (or is trying to print a generated error message that ends in a newline), LLDB ends up printing both the automatically added newline and the one that was in the error message string. This leads to all the randomly appearing new lines in error such as: ``` (lldb) command a error: 'command alias' requires at least two arguments (lldb) apropos a b error: 'apropos' must be called with exactly one argument. (lldb) why is there an empty line behind the second error? ``` This code adds a check that only appends the new line if the passed message doesn't already contain a trailing new line. Also removes the AppendRawWarning which had only one caller and doesn't serve any purpose now. Reviewed By: #lldb, mib Differential Revision: https://reviews.llvm.org/D96947
2021-02-24 21:08:49 +08:00
result.AppendWarning("Expressions should be quoted if they contain "
"spaces or other special characters.");
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
return false;
}
[Expression] Add PersistentExpressionState::GetCompilerTypeFromPersistentDecl Summary: PersistentStateExpressions (e.g. ClangPersistentVariables) have the ability to define types using expressions that persist throughout the debugging session. GetCompilerTypeFromPersistentDecl is a useful operation to have if you need to use any of those persistently declared types, like in CommandObjectMemory. This decouples clang from CommandObjectMemory and decouples Plugins from Commands in general. Differential Revision: https://reviews.llvm.org/D62797 llvm-svn: 363183
2019-06-13 01:47:06 +08:00
CompilerType compiler_type;
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;
*** 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 a new OptionValue subclass for lldb::Format: OptionValueFormat. Added new OptionGroup subclasses for: - output file for use with options: long opts: --outfile <path> --append--output short opts: -o <path> -A - format for use with options: long opts: --format <format> - variable object display controls for depth, pointer depth, wether to show types, show summary, show location, flat output, use objc "po" style summary. Modified ValueObjectMemory to be able to be created either with a TypeSP or a ClangASTType. Switched "memory read" over to use OptionGroup subclasses: one for the outfile options, one for the command specific options, and one for the format. llvm-svn: 130334
2011-04-28 06:04:39 +08:00
const char *view_as_type_cstr =
m_memory_options.m_view_as_type.GetCurrentValue();
if (view_as_type_cstr && view_as_type_cstr[0]) {
// We are viewing memory as a type
*** 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/11113279> Fixed type lookups to "do the right thing". Prior to this fix, looking up a type using "foo::bar" would result in a type list that contains all types that had "bar" as a basename unless the symbol file was able to match fully qualified names (which our DWARF parser does not). This fix will allow type matches to be made based on the basename and then have the types that don't match filtered out. Types by name can be fully qualified, or partially qualified with the new "bool exact_match" parameter to the Module::FindTypes() method. This fixes some issue that we discovered with dynamic type resolution as well as improves the overall type lookups in LLDB. llvm-svn: 153482
2012-03-27 07:03:23 +08:00
const bool exact_match = false;
Added a new OptionValue subclass for lldb::Format: OptionValueFormat. Added new OptionGroup subclasses for: - output file for use with options: long opts: --outfile <path> --append--output short opts: -o <path> -A - format for use with options: long opts: --format <format> - variable object display controls for depth, pointer depth, wether to show types, show summary, show location, flat output, use objc "po" style summary. Modified ValueObjectMemory to be able to be created either with a TypeSP or a ClangASTType. Switched "memory read" over to use OptionGroup subclasses: one for the outfile options, one for the command specific options, and one for the format. llvm-svn: 130334
2011-04-28 06:04:39 +08:00
TypeList type_list;
uint32_t reference_count = 0;
uint32_t pointer_count = 0;
size_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
Fixed a hang which causes LLDB to enter an infinite loop if "memory read" is run with the -t option and the type name contains a keyword like "struct" that isn't followed by a space. Now if a keyword isn't followed by a space we continue searching after it, instead of at the beginning of the type name. Also optimized the code to not call strlen() on a fixed set of statically-declared constant strings. llvm-svn: 160016
2012-07-11 05:24:26 +08:00
#define ALL_KEYWORDS \
KEYWORD("const") \
KEYWORD("volatile") \
KEYWORD("restrict") \
KEYWORD("struct") \
KEYWORD("class") \
KEYWORD("union")
Added the ability to specify dumping options (show types, show location, depth control, pointer depth, and more) when dumping memory and viewing as a type. llvm-svn: 130436
2011-04-29 04:55:26 +08:00
Fixed a hang which causes LLDB to enter an infinite loop if "memory read" is run with the -t option and the type name contains a keyword like "struct" that isn't followed by a space. Now if a keyword isn't followed by a space we continue searching after it, instead of at the beginning of the type name. Also optimized the code to not call strlen() on a fixed set of statically-declared constant strings. llvm-svn: 160016
2012-07-11 05:24:26 +08:00
#define KEYWORD(s) s,
static const char *g_keywords[] = {ALL_KEYWORDS};
#undef KEYWORD
#define KEYWORD(s) (sizeof(s) - 1),
static const int g_keyword_lengths[] = {ALL_KEYWORDS};
#undef KEYWORD
*** 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 a hang which causes LLDB to enter an infinite loop if "memory read" is run with the -t option and the type name contains a keyword like "struct" that isn't followed by a space. Now if a keyword isn't followed by a space we continue searching after it, instead of at the beginning of the type name. Also optimized the code to not call strlen() on a fixed set of statically-declared constant strings. llvm-svn: 160016
2012-07-11 05:24:26 +08:00
#undef ALL_KEYWORDS
Silence -Wqual-cast warnings from GCC 5.2 There were a number of const qualifiers being cast away which caused warnings. This cluttered the output hiding real errors. Silence them by explicit casting. NFC. llvm-svn: 250662
2015-10-19 03:34:38 +08:00
<rdar://problem/13779789> Allow memory read -t to take persistent types (those defined with expression struct $....) llvm-svn: 183766
2013-06-12 02:47:55 +08:00
static size_t g_num_keywords = sizeof(g_keywords) / sizeof(const char *);
std::string type_str(view_as_type_cstr);
*** 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/13779789> Allow memory read -t to take persistent types (those defined with expression struct $....) llvm-svn: 183766
2013-06-12 02:47:55 +08:00
// Remove all instances of g_keywords that are followed by spaces
for (size_t i = 0; i < g_num_keywords; ++i) {
Added a new OptionValue subclass for lldb::Format: OptionValueFormat. Added new OptionGroup subclasses for: - output file for use with options: long opts: --outfile <path> --append--output short opts: -o <path> -A - format for use with options: long opts: --format <format> - variable object display controls for depth, pointer depth, wether to show types, show summary, show location, flat output, use objc "po" style summary. Modified ValueObjectMemory to be able to be created either with a TypeSP or a ClangASTType. Switched "memory read" over to use OptionGroup subclasses: one for the outfile options, one for the command specific options, and one for the format. llvm-svn: 130334
2011-04-28 06:04:39 +08:00
const char *keyword = g_keywords[i];
<rdar://problem/13779789> Allow memory read -t to take persistent types (those defined with expression struct $....) llvm-svn: 183766
2013-06-12 02:47:55 +08:00
int keyword_len = g_keyword_lengths[i];
*** 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
idx = 0;
<rdar://problem/13779789> Allow memory read -t to take persistent types (those defined with expression struct $....) llvm-svn: 183766
2013-06-12 02:47:55 +08:00
while ((idx = type_str.find(keyword, idx)) != std::string::npos) {
if (type_str[idx + keyword_len] == ' ' ||
type_str[idx + keyword_len] == '\t') {
Added a new OptionValue subclass for lldb::Format: OptionValueFormat. Added new OptionGroup subclasses for: - output file for use with options: long opts: --outfile <path> --append--output short opts: -o <path> -A - format for use with options: long opts: --format <format> - variable object display controls for depth, pointer depth, wether to show types, show summary, show location, flat output, use objc "po" style summary. Modified ValueObjectMemory to be able to be created either with a TypeSP or a ClangASTType. Switched "memory read" over to use OptionGroup subclasses: one for the outfile options, one for the command specific options, and one for the format. llvm-svn: 130334
2011-04-28 06:04:39 +08:00
type_str.erase(idx, keyword_len + 1);
*** 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
idx = 0;
} else {
Fixed a hang which causes LLDB to enter an infinite loop if "memory read" is run with the -t option and the type name contains a keyword like "struct" that isn't followed by a space. Now if a keyword isn't followed by a space we continue searching after it, instead of at the beginning of the type name. Also optimized the code to not call strlen() on a fixed set of statically-declared constant strings. llvm-svn: 160016
2012-07-11 05:24:26 +08:00
idx += keyword_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
}
}
}
<rdar://problem/13779789> Allow memory read -t to take persistent types (those defined with expression struct $....) llvm-svn: 183766
2013-06-12 02:47:55 +08:00
bool done = type_str.empty();
*** 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 a new OptionValue subclass for lldb::Format: OptionValueFormat. Added new OptionGroup subclasses for: - output file for use with options: long opts: --outfile <path> --append--output short opts: -o <path> -A - format for use with options: long opts: --format <format> - variable object display controls for depth, pointer depth, wether to show types, show summary, show location, flat output, use objc "po" style summary. Modified ValueObjectMemory to be able to be created either with a TypeSP or a ClangASTType. Switched "memory read" over to use OptionGroup subclasses: one for the outfile options, one for the command specific options, and one for the format. llvm-svn: 130334
2011-04-28 06:04:39 +08:00
idx = type_str.find_first_not_of(" \t");
<rdar://problem/13779789> Allow memory read -t to take persistent types (those defined with expression struct $....) llvm-svn: 183766
2013-06-12 02:47:55 +08:00
if (idx > 0 && idx != std::string::npos)
Added a new OptionValue subclass for lldb::Format: OptionValueFormat. Added new OptionGroup subclasses for: - output file for use with options: long opts: --outfile <path> --append--output short opts: -o <path> -A - format for use with options: long opts: --format <format> - variable object display controls for depth, pointer depth, wether to show types, show summary, show location, flat output, use objc "po" style summary. Modified ValueObjectMemory to be able to be created either with a TypeSP or a ClangASTType. Switched "memory read" over to use OptionGroup subclasses: one for the outfile options, one for the command specific options, and one for the format. llvm-svn: 130334
2011-04-28 06:04:39 +08:00
type_str.erase(0, idx);
while (!done) {
<rdar://problem/13779789> Allow memory read -t to take persistent types (those defined with expression struct $....) llvm-svn: 183766
2013-06-12 02:47:55 +08:00
// Strip trailing spaces
if (type_str.empty())
Added a new OptionValue subclass for lldb::Format: OptionValueFormat. Added new OptionGroup subclasses for: - output file for use with options: long opts: --outfile <path> --append--output short opts: -o <path> -A - format for use with options: long opts: --format <format> - variable object display controls for depth, pointer depth, wether to show types, show summary, show location, flat output, use objc "po" style summary. Modified ValueObjectMemory to be able to be created either with a TypeSP or a ClangASTType. Switched "memory read" over to use OptionGroup subclasses: one for the outfile options, one for the command specific options, and one for the format. llvm-svn: 130334
2011-04-28 06:04:39 +08:00
done = true;
*** 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 {
<rdar://problem/13779789> Allow memory read -t to take persistent types (those defined with expression struct $....) llvm-svn: 183766
2013-06-12 02:47:55 +08:00
switch (type_str[type_str.size() - 1]) {
Made Target hold a map of languages to TypeSystems, and added some accessors. Also added some target-level search functions so that persistent variables and symbols can be searched for without hand-iterating across the map of TypeSystems. llvm-svn: 249027
2015-10-02 00:28:02 +08:00
case '*':
++pointer_count;
LLVM_FALLTHROUGH;
Added a new OptionValue subclass for lldb::Format: OptionValueFormat. Added new OptionGroup subclasses for: - output file for use with options: long opts: --outfile <path> --append--output short opts: -o <path> -A - format for use with options: long opts: --format <format> - variable object display controls for depth, pointer depth, wether to show types, show summary, show location, flat output, use objc "po" style summary. Modified ValueObjectMemory to be able to be created either with a TypeSP or a ClangASTType. Switched "memory read" over to use OptionGroup subclasses: one for the outfile options, one for the command specific options, and one for the format. llvm-svn: 130334
2011-04-28 06:04:39 +08:00
case ' ':
case '\t':
Made Target hold a map of languages to TypeSystems, and added some accessors. Also added some target-level search functions so that persistent variables and symbols can be searched for without hand-iterating across the map of TypeSystems. llvm-svn: 249027
2015-10-02 00:28:02 +08:00
type_str.erase(type_str.size() - 1);
*** 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
break;
Added a new OptionValue subclass for lldb::Format: OptionValueFormat. Added new OptionGroup subclasses for: - output file for use with options: long opts: --outfile <path> --append--output short opts: -o <path> -A - format for use with options: long opts: --format <format> - variable object display controls for depth, pointer depth, wether to show types, show summary, show location, flat output, use objc "po" style summary. Modified ValueObjectMemory to be able to be created either with a TypeSP or a ClangASTType. Switched "memory read" over to use OptionGroup subclasses: one for the outfile options, one for the command specific options, and one for the format. llvm-svn: 130334
2011-04-28 06:04:39 +08:00
case '&':
Made Target hold a map of languages to TypeSystems, and added some accessors. Also added some target-level search functions so that persistent variables and symbols can be searched for without hand-iterating across the map of TypeSystems. llvm-svn: 249027
2015-10-02 00:28:02 +08:00
if (reference_count == 0) {
reference_count = 1;
type_str.erase(type_str.size() - 1);
} else {
result.AppendErrorWithFormat("invalid type string: '%s'\n",
Handle any persistent Decl in the Clang expression parser, not just types. Persistent decls have traditionally only been types. However, we want to be able to persist more things, like functions and global variables. This changes some of the nomenclature and the lookup rules to make this possible. <rdar://problem/22864976> llvm-svn: 263864
2016-03-19 08:51:43 +08:00
view_as_type_cstr);
Added a new OptionValue subclass for lldb::Format: OptionValueFormat. Added new OptionGroup subclasses for: - output file for use with options: long opts: --outfile <path> --append--output short opts: -o <path> -A - format for use with options: long opts: --format <format> - variable object display controls for depth, pointer depth, wether to show types, show summary, show location, flat output, use objc "po" style summary. Modified ValueObjectMemory to be able to be created either with a TypeSP or a ClangASTType. Switched "memory read" over to use OptionGroup subclasses: one for the outfile options, one for the command specific options, and one for the format. llvm-svn: 130334
2011-04-28 06:04:39 +08:00
return false;
}
*** 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
break;
Silence -Wqual-cast warnings from GCC 5.2 There were a number of const qualifiers being cast away which caused warnings. This cluttered the output hiding real errors. Silence them by explicit casting. NFC. llvm-svn: 250662
2015-10-19 03:34:38 +08:00
<rdar://problem/13779789> Allow memory read -t to take persistent types (those defined with expression struct $....) llvm-svn: 183766
2013-06-12 02:47:55 +08:00
default:
Final bit of type system cleanup that abstracts declaration contexts into lldb_private::CompilerDeclContext and renames ClangType to CompilerType in many accessors and functions. Create a new "lldb_private::CompilerDeclContext" class that will replace all direct uses of "clang::DeclContext" when used in compiler agnostic code, yet still allow for conversion to clang::DeclContext subclasses by clang specific code. This completes the abstraction of type parsing by removing all "clang::" references from the SymbolFileDWARF. The new "lldb_private::CompilerDeclContext" class abstracts decl contexts found in compiler type systems so they can be used in internal API calls. The TypeSystem is required to support CompilerDeclContexts with new pure virtual functions that start with "DeclContext" in the member function names. Converted all code that used lldb_private::ClangNamespaceDecl over to use the new CompilerDeclContext class and removed the ClangNamespaceDecl.cpp and ClangNamespaceDecl.h files. Removed direct use of clang APIs from SBType and now use the abstract type systems to correctly explore types. Bulk renames for things that used to return a ClangASTType which is now CompilerType: "Type::GetClangFullType()" to "Type::GetFullCompilerType()" "Type::GetClangLayoutType()" to "Type::GetLayoutCompilerType()" "Type::GetClangForwardType()" to "Type::GetForwardCompilerType()" "Value::GetClangType()" to "Value::GetCompilerType()" "Value::SetClangType (const CompilerType &)" to "Value::SetCompilerType (const CompilerType &)" "ValueObject::GetClangType ()" to "ValueObject::GetCompilerType()" many more renames that are similar. llvm-svn: 245905
2015-08-25 07:46:31 +08:00
done = true;
*** 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
break;
<rdar://problem/13779789> Allow memory read -t to take persistent types (those defined with expression struct $....) llvm-svn: 183766
2013-06-12 02:47:55 +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
}
Added a new OptionValue subclass for lldb::Format: OptionValueFormat. Added new OptionGroup subclasses for: - output file for use with options: long opts: --outfile <path> --append--output short opts: -o <path> -A - format for use with options: long opts: --format <format> - variable object display controls for depth, pointer depth, wether to show types, show summary, show location, flat output, use objc "po" style summary. Modified ValueObjectMemory to be able to be created either with a TypeSP or a ClangASTType. Switched "memory read" over to use OptionGroup subclasses: one for the outfile options, one for the command specific options, and one for the format. llvm-svn: 130334
2011-04-28 06:04:39 +08:00
}
Preparatory infrastructural work to support dynamically determining sizes of ObjC types via the runtime This is necessary because the byte size of an ObjC class type is not reliably statically knowable (e.g. because superclasses sit deep in frameworks that we have no debug info for) The lack of reliable size info is a problem when trying to freeze-dry an ObjC instance (not the pointer, the pointee) This commit lays the foundation for having language runtimes help in figuring out byte sizes, and having ClangASTType ask for runtime help No feature change as no runtime actually implements the logic, and nowhere is an ExecutionContext passed in yet llvm-svn: 227274
2015-01-28 08:07:51 +08:00
llvm::DenseSet<lldb_private::SymbolFile *> searched_symbol_files;
ConstString lookup_type_name(type_str.c_str());
Updated all commands that use a "--format" / "-f" options to use the new OptionGroupFormat. Updated OptionGroupFormat to be able to also use the "--size" and "--count" options. Commands that use a OptionGroupFormat instance can choose which of the options they want by initializing OptionGroupFormat accordingly. Clients can either get only the "--format", "--format" + "--size", or "--format" + "--size" + "--count". This is in preparation for upcoming chnages where there are alternate ways (GDB format specification) to set a format. llvm-svn: 142911
2011-10-25 14:44:01 +08:00
StackFrame *frame = m_exe_ctx.GetFramePtr();
[SymbolFile] Remove SymbolContext parameter from FindTypes. This parameter was only ever used with the Module set, and since a SymbolFile is tied to a module, the parameter turns out to be entirely unnecessary. Furthermore, it doesn't make a lot of sense to ask a caller to ask SymbolFile which is tied to Module X to find types for Module Y, but that possibility was open with the previous interface. By removing this parameter from the API, it makes it harder to use incorrectly as well as easier for an implementor to understand what it needs to do. llvm-svn: 351133
2019-01-15 06:41:21 +08:00
ModuleSP search_first;
Updated all commands that use a "--format" / "-f" options to use the new OptionGroupFormat. Updated OptionGroupFormat to be able to also use the "--size" and "--count" options. Commands that use a OptionGroupFormat instance can choose which of the options they want by initializing OptionGroupFormat accordingly. Clients can either get only the "--format", "--format" + "--size", or "--format" + "--size" + "--count". This is in preparation for upcoming chnages where there are alternate ways (GDB format specification) to set a format. llvm-svn: 142911
2011-10-25 14:44:01 +08:00
if (frame) {
[SymbolFile] Remove SymbolContext parameter from FindTypes. This parameter was only ever used with the Module set, and since a SymbolFile is tied to a module, the parameter turns out to be entirely unnecessary. Furthermore, it doesn't make a lot of sense to ask a caller to ask SymbolFile which is tied to Module X to find types for Module Y, but that possibility was open with the previous interface. By removing this parameter from the API, it makes it harder to use incorrectly as well as easier for an implementor to understand what it needs to do. llvm-svn: 351133
2019-01-15 06:41:21 +08:00
search_first = frame->GetSymbolContext(eSymbolContextModule).module_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
}
[SymbolFile] Remove SymbolContext parameter from FindTypes. This parameter was only ever used with the Module set, and since a SymbolFile is tied to a module, the parameter turns out to be entirely unnecessary. Furthermore, it doesn't make a lot of sense to ask a caller to ask SymbolFile which is tied to Module X to find types for Module Y, but that possibility was open with the previous interface. By removing this parameter from the API, it makes it harder to use incorrectly as well as easier for an implementor to understand what it needs to do. llvm-svn: 351133
2019-01-15 06:41:21 +08:00
target->GetImages().FindTypes(search_first.get(), lookup_type_name,
exact_match, 1, searched_symbol_files,
type_list);
*** 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
[Expression] Add PersistentExpressionState::GetCompilerTypeFromPersistentDecl Summary: PersistentStateExpressions (e.g. ClangPersistentVariables) have the ability to define types using expressions that persist throughout the debugging session. GetCompilerTypeFromPersistentDecl is a useful operation to have if you need to use any of those persistently declared types, like in CommandObjectMemory. This decouples clang from CommandObjectMemory and decouples Plugins from Commands in general. Differential Revision: https://reviews.llvm.org/D62797 llvm-svn: 363183
2019-06-13 01:47:06 +08:00
if (type_list.GetSize() == 0 && lookup_type_name.GetCString()) {
LanguageType language_for_type =
m_memory_options.m_language_for_type.GetCurrentValue();
std::set<LanguageType> languages_to_check;
if (language_for_type != eLanguageTypeUnknown) {
languages_to_check.insert(language_for_type);
} else {
languages_to_check = Language::GetSupportedLanguages();
}
std::set<CompilerType> user_defined_types;
for (auto lang : languages_to_check) {
if (auto *persistent_vars =
target->GetPersistentExpressionStateForLanguage(lang)) {
if (llvm::Optional<CompilerType> type =
persistent_vars->GetCompilerTypeFromPersistentDecl(
lookup_type_name)) {
user_defined_types.emplace(*type);
}
*** 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
}
[Expression] Add PersistentExpressionState::GetCompilerTypeFromPersistentDecl Summary: PersistentStateExpressions (e.g. ClangPersistentVariables) have the ability to define types using expressions that persist throughout the debugging session. GetCompilerTypeFromPersistentDecl is a useful operation to have if you need to use any of those persistently declared types, like in CommandObjectMemory. This decouples clang from CommandObjectMemory and decouples Plugins from Commands in general. Differential Revision: https://reviews.llvm.org/D62797 llvm-svn: 363183
2019-06-13 01:47:06 +08:00
if (user_defined_types.size() > 1) {
result.AppendErrorWithFormat(
"Mutiple types found matching raw type '%s', please disambiguate "
"by specifying the language with -x",
lookup_type_name.GetCString());
return false;
}
if (user_defined_types.size() == 1) {
compiler_type = *user_defined_types.begin();
}
*** 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
[Expression] Add PersistentExpressionState::GetCompilerTypeFromPersistentDecl Summary: PersistentStateExpressions (e.g. ClangPersistentVariables) have the ability to define types using expressions that persist throughout the debugging session. GetCompilerTypeFromPersistentDecl is a useful operation to have if you need to use any of those persistently declared types, like in CommandObjectMemory. This decouples clang from CommandObjectMemory and decouples Plugins from Commands in general. Differential Revision: https://reviews.llvm.org/D62797 llvm-svn: 363183
2019-06-13 01:47:06 +08:00
if (!compiler_type.IsValid()) {
Added the ability to specify dumping options (show types, show location, depth control, pointer depth, and more) when dumping memory and viewing as a type. llvm-svn: 130436
2011-04-29 04:55:26 +08:00
if (type_list.GetSize() == 0) {
<rdar://problem/12820334> I modified the "Args::StringtoAddress(...)" function to be able to evaluate address expressions. This is now used for any command line arguments or options that takes addresses like: memory read <addr> [<end-addr>] memory write <addr> breakpoint set --address <addr> disassemble --start-address <addr> --end-address <addr> It calls the expression parser to evaluate the address expression and will also work around the issue where the compiler doesn't like to add offsets to function pointers (which is what happens when you try to evaluate "main + 12"). So there is a temp fix in the Args::StringtoAddress() to work around this until we can get special compiler support for debug expressions with function pointers. llvm-svn: 169556
2012-12-07 06:49:16 +08:00
result.AppendErrorWithFormat("unable to find any types that match "
<rdar://problem/13779789> Allow memory read -t to take persistent types (those defined with expression struct $....) llvm-svn: 183766
2013-06-12 02:47:55 +08:00
"the raw type '%s' for full type '%s'\n",
<rdar://problem/12820334> I modified the "Args::StringtoAddress(...)" function to be able to evaluate address expressions. This is now used for any command line arguments or options that takes addresses like: memory read <addr> [<end-addr>] memory write <addr> breakpoint set --address <addr> disassemble --start-address <addr> --end-address <addr> It calls the expression parser to evaluate the address expression and will also work around the issue where the compiler doesn't like to add offsets to function pointers (which is what happens when you try to evaluate "main + 12"). So there is a temp fix in the Args::StringtoAddress() to work around this until we can get special compiler support for debug expressions with function pointers. llvm-svn: 169556
2012-12-07 06:49:16 +08:00
lookup_type_name.GetCString(),
view_as_type_cstr);
Added the ability to specify dumping options (show types, show location, depth control, pointer depth, and more) when dumping memory and viewing as a type. llvm-svn: 130436
2011-04-29 04:55:26 +08:00
return false;
*** 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 {
<rdar://problem/13779789> Allow memory read -t to take persistent types (those defined with expression struct $....) llvm-svn: 183766
2013-06-12 02:47:55 +08:00
TypeSP type_sp(type_list.GetTypeAtIndex(0));
[Expression] Add PersistentExpressionState::GetCompilerTypeFromPersistentDecl Summary: PersistentStateExpressions (e.g. ClangPersistentVariables) have the ability to define types using expressions that persist throughout the debugging session. GetCompilerTypeFromPersistentDecl is a useful operation to have if you need to use any of those persistently declared types, like in CommandObjectMemory. This decouples clang from CommandObjectMemory and decouples Plugins from Commands in general. Differential Revision: https://reviews.llvm.org/D62797 llvm-svn: 363183
2019-06-13 01:47:06 +08:00
compiler_type = type_sp->GetFullCompilerType();
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +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
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
A simple fix for the GDB format strings so the byte size parameter gets properly marked as valid. Also modified the "memory read" command to be able to intelligently repeat subsequent memory requests, so now you can do: (lldb) memory read --format hex --count 32 0x1000 Then hit enter to keep viewing the memory that follows the last valid request. llvm-svn: 143015
2011-10-26 12:32:38 +08:00
while (pointer_count > 0) {
[Expression] Add PersistentExpressionState::GetCompilerTypeFromPersistentDecl Summary: PersistentStateExpressions (e.g. ClangPersistentVariables) have the ability to define types using expressions that persist throughout the debugging session. GetCompilerTypeFromPersistentDecl is a useful operation to have if you need to use any of those persistently declared types, like in CommandObjectMemory. This decouples clang from CommandObjectMemory and decouples Plugins from Commands in general. Differential Revision: https://reviews.llvm.org/D62797 llvm-svn: 363183
2019-06-13 01:47:06 +08:00
CompilerType pointer_type = compiler_type.GetPointerType();
Huge change to clean up types. A long time ago we start with clang types that were created by the symbol files and there were many functions in lldb_private::ClangASTContext that helped. Later we create ClangASTType which contains a clang::ASTContext and an opauque QualType, but we didn't switch over to fully using it. There were a lot of places where we would pass around a raw clang_type_t and also pass along a clang::ASTContext separately. This left room for error. This checkin change all type code over to use ClangASTType everywhere and I cleaned up the interfaces quite a bit. Any code that was in ClangASTContext that was type related, was moved over into ClangASTType. All code that used these types was switched over to use all of the new goodness. llvm-svn: 186130
2013-07-12 06:46:58 +08:00
if (pointer_type.IsValid())
[Expression] Add PersistentExpressionState::GetCompilerTypeFromPersistentDecl Summary: PersistentStateExpressions (e.g. ClangPersistentVariables) have the ability to define types using expressions that persist throughout the debugging session. GetCompilerTypeFromPersistentDecl is a useful operation to have if you need to use any of those persistently declared types, like in CommandObjectMemory. This decouples clang from CommandObjectMemory and decouples Plugins from Commands in general. Differential Revision: https://reviews.llvm.org/D62797 llvm-svn: 363183
2019-06-13 01:47:06 +08:00
compiler_type = pointer_type;
A simple fix for the GDB format strings so the byte size parameter gets properly marked as valid. Also modified the "memory read" command to be able to intelligently repeat subsequent memory requests, so now you can do: (lldb) memory read --format hex --count 32 0x1000 Then hit enter to keep viewing the memory that follows the last valid request. llvm-svn: 143015
2011-10-26 12:32:38 +08:00
else {
result.AppendError("unable make a pointer type\n");
return false;
}
Added a new OptionValue subclass for lldb::Format: OptionValueFormat. Added new OptionGroup subclasses for: - output file for use with options: long opts: --outfile <path> --append--output short opts: -o <path> -A - format for use with options: long opts: --format <format> - variable object display controls for depth, pointer depth, wether to show types, show summary, show location, flat output, use objc "po" style summary. Modified ValueObjectMemory to be able to be created either with a TypeSP or a ClangASTType. Switched "memory read" over to use OptionGroup subclasses: one for the outfile options, one for the command specific options, and one for the format. llvm-svn: 130334
2011-04-28 06:04:39 +08:00
--pointer_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
}
A simple fix for the GDB format strings so the byte size parameter gets properly marked as valid. Also modified the "memory read" command to be able to intelligently repeat subsequent memory requests, so now you can do: (lldb) memory read --format hex --count 32 0x1000 Then hit enter to keep viewing the memory that follows the last valid request. llvm-svn: 143015
2011-10-26 12:32:38 +08:00
[Expression] Add PersistentExpressionState::GetCompilerTypeFromPersistentDecl Summary: PersistentStateExpressions (e.g. ClangPersistentVariables) have the ability to define types using expressions that persist throughout the debugging session. GetCompilerTypeFromPersistentDecl is a useful operation to have if you need to use any of those persistently declared types, like in CommandObjectMemory. This decouples clang from CommandObjectMemory and decouples Plugins from Commands in general. Differential Revision: https://reviews.llvm.org/D62797 llvm-svn: 363183
2019-06-13 01:47:06 +08:00
llvm::Optional<uint64_t> size = compiler_type.GetByteSize(nullptr);
Make CompilerType::getBitSize() / getByteSize() return an optional result. NFC The code in LLDB assumes that CompilerType and friends use the size 0 as a sentinel value to signal an error. This works for C++, where no zero-sized type exists, but in many other programming languages (including I believe C) types of size zero are possible and even common. This is a particular pain point in swift-lldb, where extra code exists to double-check that a type is *really* of size zero and not an error at various locations. To remedy this situation, this patch starts by converting CompilerType::getBitSize() and getByteSize() to return an optional result. To avoid wasting space, I hand-rolled my own optional data type assuming that no type is larger than what fits into 63 bits. Follow-up patches would make similar changes to the ValueObject hierarchy. rdar://problem/47178964 Differential Revision: https://reviews.llvm.org/D56688 llvm-svn: 351214
2019-01-16 02:07:52 +08:00
if (!size) {
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
result.AppendErrorWithFormat(
"unable to get the byte size of the type '%s'\n",
<rdar://problem/13779789> Allow memory read -t to take persistent types (those defined with expression struct $....) llvm-svn: 183766
2013-06-12 02:47:55 +08:00
view_as_type_cstr);
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
return false;
*** 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
}
Make CompilerType::getBitSize() / getByteSize() return an optional result. NFC The code in LLDB assumes that CompilerType and friends use the size 0 as a sentinel value to signal an error. This works for C++, where no zero-sized type exists, but in many other programming languages (including I believe C) types of size zero are possible and even common. This is a particular pain point in swift-lldb, where extra code exists to double-check that a type is *really* of size zero and not an error at various locations. To remedy this situation, this patch starts by converting CompilerType::getBitSize() and getByteSize() to return an optional result. To avoid wasting space, I hand-rolled my own optional data type assuming that no type is larger than what fits into 63 bits. Follow-up patches would make similar changes to the ValueObject hierarchy. rdar://problem/47178964 Differential Revision: https://reviews.llvm.org/D56688 llvm-svn: 351214
2019-01-16 02:07:52 +08:00
m_format_options.GetByteSizeValue() = *size;
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
Added the ability to specify dumping options (show types, show location, depth control, pointer depth, and more) when dumping memory and viewing as a type. llvm-svn: 130436
2011-04-29 04:55:26 +08:00
if (!m_format_options.GetCountValue().OptionWasSet())
m_format_options.GetCountValue() = 1;
} else {
error = m_memory_options.FinalizeSettings(target, m_format_options);
*** 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 specify dumping options (show types, show location, depth control, pointer depth, and more) when dumping memory and viewing as a type. llvm-svn: 130436
2011-04-29 04:55:26 +08:00
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
// Look for invalid combinations of settings
if (error.Fail()) {
<rdar://problem/12820334> I modified the "Args::StringtoAddress(...)" function to be able to evaluate address expressions. This is now used for any command line arguments or options that takes addresses like: memory read <addr> [<end-addr>] memory write <addr> breakpoint set --address <addr> disassemble --start-address <addr> --end-address <addr> It calls the expression parser to evaluate the address expression and will also work around the issue where the compiler doesn't like to add offsets to function pointers (which is what happens when you try to evaluate "main + 12"). So there is a temp fix in the Args::StringtoAddress() to work around this until we can get special compiler support for debug expressions with function pointers. llvm-svn: 169556
2012-12-07 06:49:16 +08:00
result.AppendError(error.AsCString());
A simple fix for the GDB format strings so the byte size parameter gets properly marked as valid. Also modified the "memory read" command to be able to intelligently repeat subsequent memory requests, so now you can do: (lldb) memory read --format hex --count 32 0x1000 Then hit enter to keep viewing the memory that follows the last valid request. llvm-svn: 143015
2011-10-26 12:32:38 +08:00
return false;
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
Expanded the flags that can be set for a command object in lldb_private::CommandObject. This list of available flags are: enum { //---------------------------------------------------------------------- // eFlagRequiresTarget // // Ensures a valid target is contained in m_exe_ctx prior to executing // the command. If a target doesn't exist or is invalid, the command // will fail and CommandObject::GetInvalidTargetDescription() will be // returned as the error. CommandObject subclasses can override the // virtual function for GetInvalidTargetDescription() to provide custom // strings when needed. //---------------------------------------------------------------------- eFlagRequiresTarget = (1u << 0), //---------------------------------------------------------------------- // eFlagRequiresProcess // // Ensures a valid process is contained in m_exe_ctx prior to executing // the command. If a process doesn't exist or is invalid, the command // will fail and CommandObject::GetInvalidProcessDescription() will be // returned as the error. CommandObject subclasses can override the // virtual function for GetInvalidProcessDescription() to provide custom // strings when needed. //---------------------------------------------------------------------- eFlagRequiresProcess = (1u << 1), //---------------------------------------------------------------------- // eFlagRequiresThread // // Ensures a valid thread is contained in m_exe_ctx prior to executing // the command. If a thread doesn't exist or is invalid, the command // will fail and CommandObject::GetInvalidThreadDescription() will be // returned as the error. CommandObject subclasses can override the // virtual function for GetInvalidThreadDescription() to provide custom // strings when needed. //---------------------------------------------------------------------- eFlagRequiresThread = (1u << 2), //---------------------------------------------------------------------- // eFlagRequiresFrame // // Ensures a valid frame is contained in m_exe_ctx prior to executing // the command. If a frame doesn't exist or is invalid, the command // will fail and CommandObject::GetInvalidFrameDescription() will be // returned as the error. CommandObject subclasses can override the // virtual function for GetInvalidFrameDescription() to provide custom // strings when needed. //---------------------------------------------------------------------- eFlagRequiresFrame = (1u << 3), //---------------------------------------------------------------------- // eFlagRequiresRegContext // // Ensures a valid register context (from the selected frame if there // is a frame in m_exe_ctx, or from the selected thread from m_exe_ctx) // is availble from m_exe_ctx prior to executing the command. If a // target doesn't exist or is invalid, the command will fail and // CommandObject::GetInvalidRegContextDescription() will be returned as // the error. CommandObject subclasses can override the virtual function // for GetInvalidRegContextDescription() to provide custom strings when // needed. //---------------------------------------------------------------------- eFlagRequiresRegContext = (1u << 4), //---------------------------------------------------------------------- // eFlagTryTargetAPILock // // Attempts to acquire the target lock if a target is selected in the // command interpreter. If the command object fails to acquire the API // lock, the command will fail with an appropriate error message. //---------------------------------------------------------------------- eFlagTryTargetAPILock = (1u << 5), //---------------------------------------------------------------------- // eFlagProcessMustBeLaunched // // Verifies that there is a launched process in m_exe_ctx, if there // isn't, the command will fail with an appropriate error message. //---------------------------------------------------------------------- eFlagProcessMustBeLaunched = (1u << 6), //---------------------------------------------------------------------- // eFlagProcessMustBePaused // // Verifies that there is a paused process in m_exe_ctx, if there // isn't, the command will fail with an appropriate error message. //---------------------------------------------------------------------- eFlagProcessMustBePaused = (1u << 7) }; Now each command object contains a "ExecutionContext m_exe_ctx;" member variable that gets initialized prior to running the command. The validity of the target objects in m_exe_ctx are checked to ensure that any target/process/thread/frame/reg context that are required are valid prior to executing the command. Each command object also contains a Mutex::Locker m_api_locker which gets used if eFlagTryTargetAPILock is set. This centralizes a lot of checking code that was previously and inconsistently implemented across many commands. llvm-svn: 171990
2013-01-10 03:44:40 +08:00
lldb::addr_t addr;
size_t total_byte_size = 0;
if (argc == 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
// Use the last address and byte size and all options as they were if no
// options have been set
Expanded the flags that can be set for a command object in lldb_private::CommandObject. This list of available flags are: enum { //---------------------------------------------------------------------- // eFlagRequiresTarget // // Ensures a valid target is contained in m_exe_ctx prior to executing // the command. If a target doesn't exist or is invalid, the command // will fail and CommandObject::GetInvalidTargetDescription() will be // returned as the error. CommandObject subclasses can override the // virtual function for GetInvalidTargetDescription() to provide custom // strings when needed. //---------------------------------------------------------------------- eFlagRequiresTarget = (1u << 0), //---------------------------------------------------------------------- // eFlagRequiresProcess // // Ensures a valid process is contained in m_exe_ctx prior to executing // the command. If a process doesn't exist or is invalid, the command // will fail and CommandObject::GetInvalidProcessDescription() will be // returned as the error. CommandObject subclasses can override the // virtual function for GetInvalidProcessDescription() to provide custom // strings when needed. //---------------------------------------------------------------------- eFlagRequiresProcess = (1u << 1), //---------------------------------------------------------------------- // eFlagRequiresThread // // Ensures a valid thread is contained in m_exe_ctx prior to executing // the command. If a thread doesn't exist or is invalid, the command // will fail and CommandObject::GetInvalidThreadDescription() will be // returned as the error. CommandObject subclasses can override the // virtual function for GetInvalidThreadDescription() to provide custom // strings when needed. //---------------------------------------------------------------------- eFlagRequiresThread = (1u << 2), //---------------------------------------------------------------------- // eFlagRequiresFrame // // Ensures a valid frame is contained in m_exe_ctx prior to executing // the command. If a frame doesn't exist or is invalid, the command // will fail and CommandObject::GetInvalidFrameDescription() will be // returned as the error. CommandObject subclasses can override the // virtual function for GetInvalidFrameDescription() to provide custom // strings when needed. //---------------------------------------------------------------------- eFlagRequiresFrame = (1u << 3), //---------------------------------------------------------------------- // eFlagRequiresRegContext // // Ensures a valid register context (from the selected frame if there // is a frame in m_exe_ctx, or from the selected thread from m_exe_ctx) // is availble from m_exe_ctx prior to executing the command. If a // target doesn't exist or is invalid, the command will fail and // CommandObject::GetInvalidRegContextDescription() will be returned as // the error. CommandObject subclasses can override the virtual function // for GetInvalidRegContextDescription() to provide custom strings when // needed. //---------------------------------------------------------------------- eFlagRequiresRegContext = (1u << 4), //---------------------------------------------------------------------- // eFlagTryTargetAPILock // // Attempts to acquire the target lock if a target is selected in the // command interpreter. If the command object fails to acquire the API // lock, the command will fail with an appropriate error message. //---------------------------------------------------------------------- eFlagTryTargetAPILock = (1u << 5), //---------------------------------------------------------------------- // eFlagProcessMustBeLaunched // // Verifies that there is a launched process in m_exe_ctx, if there // isn't, the command will fail with an appropriate error message. //---------------------------------------------------------------------- eFlagProcessMustBeLaunched = (1u << 6), //---------------------------------------------------------------------- // eFlagProcessMustBePaused // // Verifies that there is a paused process in m_exe_ctx, if there // isn't, the command will fail with an appropriate error message. //---------------------------------------------------------------------- eFlagProcessMustBePaused = (1u << 7) }; Now each command object contains a "ExecutionContext m_exe_ctx;" member variable that gets initialized prior to running the command. The validity of the target objects in m_exe_ctx are checked to ensure that any target/process/thread/frame/reg context that are required are valid prior to executing the command. Each command object also contains a Mutex::Locker m_api_locker which gets used if eFlagTryTargetAPILock is set. This centralizes a lot of checking code that was previously and inconsistently implemented across many commands. llvm-svn: 171990
2013-01-10 03:44:40 +08:00
addr = m_next_addr;
total_byte_size = m_prev_byte_size;
[Expression] Add PersistentExpressionState::GetCompilerTypeFromPersistentDecl Summary: PersistentStateExpressions (e.g. ClangPersistentVariables) have the ability to define types using expressions that persist throughout the debugging session. GetCompilerTypeFromPersistentDecl is a useful operation to have if you need to use any of those persistently declared types, like in CommandObjectMemory. This decouples clang from CommandObjectMemory and decouples Plugins from Commands in general. Differential Revision: https://reviews.llvm.org/D62797 llvm-svn: 363183
2019-06-13 01:47:06 +08:00
compiler_type = m_prev_compiler_type;
Expanded the flags that can be set for a command object in lldb_private::CommandObject. This list of available flags are: enum { //---------------------------------------------------------------------- // eFlagRequiresTarget // // Ensures a valid target is contained in m_exe_ctx prior to executing // the command. If a target doesn't exist or is invalid, the command // will fail and CommandObject::GetInvalidTargetDescription() will be // returned as the error. CommandObject subclasses can override the // virtual function for GetInvalidTargetDescription() to provide custom // strings when needed. //---------------------------------------------------------------------- eFlagRequiresTarget = (1u << 0), //---------------------------------------------------------------------- // eFlagRequiresProcess // // Ensures a valid process is contained in m_exe_ctx prior to executing // the command. If a process doesn't exist or is invalid, the command // will fail and CommandObject::GetInvalidProcessDescription() will be // returned as the error. CommandObject subclasses can override the // virtual function for GetInvalidProcessDescription() to provide custom // strings when needed. //---------------------------------------------------------------------- eFlagRequiresProcess = (1u << 1), //---------------------------------------------------------------------- // eFlagRequiresThread // // Ensures a valid thread is contained in m_exe_ctx prior to executing // the command. If a thread doesn't exist or is invalid, the command // will fail and CommandObject::GetInvalidThreadDescription() will be // returned as the error. CommandObject subclasses can override the // virtual function for GetInvalidThreadDescription() to provide custom // strings when needed. //---------------------------------------------------------------------- eFlagRequiresThread = (1u << 2), //---------------------------------------------------------------------- // eFlagRequiresFrame // // Ensures a valid frame is contained in m_exe_ctx prior to executing // the command. If a frame doesn't exist or is invalid, the command // will fail and CommandObject::GetInvalidFrameDescription() will be // returned as the error. CommandObject subclasses can override the // virtual function for GetInvalidFrameDescription() to provide custom // strings when needed. //---------------------------------------------------------------------- eFlagRequiresFrame = (1u << 3), //---------------------------------------------------------------------- // eFlagRequiresRegContext // // Ensures a valid register context (from the selected frame if there // is a frame in m_exe_ctx, or from the selected thread from m_exe_ctx) // is availble from m_exe_ctx prior to executing the command. If a // target doesn't exist or is invalid, the command will fail and // CommandObject::GetInvalidRegContextDescription() will be returned as // the error. CommandObject subclasses can override the virtual function // for GetInvalidRegContextDescription() to provide custom strings when // needed. //---------------------------------------------------------------------- eFlagRequiresRegContext = (1u << 4), //---------------------------------------------------------------------- // eFlagTryTargetAPILock // // Attempts to acquire the target lock if a target is selected in the // command interpreter. If the command object fails to acquire the API // lock, the command will fail with an appropriate error message. //---------------------------------------------------------------------- eFlagTryTargetAPILock = (1u << 5), //---------------------------------------------------------------------- // eFlagProcessMustBeLaunched // // Verifies that there is a launched process in m_exe_ctx, if there // isn't, the command will fail with an appropriate error message. //---------------------------------------------------------------------- eFlagProcessMustBeLaunched = (1u << 6), //---------------------------------------------------------------------- // eFlagProcessMustBePaused // // Verifies that there is a paused process in m_exe_ctx, if there // isn't, the command will fail with an appropriate error message. //---------------------------------------------------------------------- eFlagProcessMustBePaused = (1u << 7) }; Now each command object contains a "ExecutionContext m_exe_ctx;" member variable that gets initialized prior to running the command. The validity of the target objects in m_exe_ctx are checked to ensure that any target/process/thread/frame/reg context that are required are valid prior to executing the command. Each command object also contains a Mutex::Locker m_api_locker which gets used if eFlagTryTargetAPILock is set. This centralizes a lot of checking code that was previously and inconsistently implemented across many commands. llvm-svn: 171990
2013-01-10 03:44:40 +08:00
if (!m_format_options.AnyOptionWasSet() &&
!m_memory_options.AnyOptionWasSet() &&
A simple fix for the GDB format strings so the byte size parameter gets properly marked as valid. Also modified the "memory read" command to be able to intelligently repeat subsequent memory requests, so now you can do: (lldb) memory read --format hex --count 32 0x1000 Then hit enter to keep viewing the memory that follows the last valid request. llvm-svn: 143015
2011-10-26 12:32:38 +08:00
!m_outfile_options.AnyOptionWasSet() &&
[lldb] Change implementation of memory read --show-tags option This does 2 things: * Moves it after the short options. Which makes sense given it's a niche, default off option. (if 2 files for one option seems a bit much, I am going to reuse them for "memory find" later) * Fixes the use of repeated commands. For example: memory read buf --show-tags <shows tags> memory read <shows tags> Added tests for the repetition and updated existing help tests. Reviewed By: omjavaid Differential Revision: https://reviews.llvm.org/D125089
2022-04-14 18:56:44 +08:00
!m_varobj_options.AnyOptionWasSet() &&
!m_memory_tag_options.AnyOptionWasSet()) {
<rdar://problem/11990131> Memory read's "repeat" behavior forgets "-t" option. It also formatted the type as hex bytes + ASCII. Now we revert to the default format when displaying types unless the user sets the format option manually. llvm-svn: 170265
2012-12-15 10:08:17 +08:00
m_format_options = m_prev_format_options;
A simple fix for the GDB format strings so the byte size parameter gets properly marked as valid. Also modified the "memory read" command to be able to intelligently repeat subsequent memory requests, so now you can do: (lldb) memory read --format hex --count 32 0x1000 Then hit enter to keep viewing the memory that follows the last valid request. llvm-svn: 143015
2011-10-26 12:32:38 +08:00
m_memory_options = m_prev_memory_options;
<rdar://problem/11990131> Memory read's "repeat" behavior forgets "-t" option. It also formatted the type as hex bytes + ASCII. Now we revert to the default format when displaying types unless the user sets the format option manually. llvm-svn: 170265
2012-12-15 10:08:17 +08:00
m_outfile_options = m_prev_outfile_options;
m_varobj_options = m_prev_varobj_options;
[lldb] Change implementation of memory read --show-tags option This does 2 things: * Moves it after the short options. Which makes sense given it's a niche, default off option. (if 2 files for one option seems a bit much, I am going to reuse them for "memory find" later) * Fixes the use of repeated commands. For example: memory read buf --show-tags <shows tags> memory read <shows tags> Added tests for the repetition and updated existing help tests. Reviewed By: omjavaid Differential Revision: https://reviews.llvm.org/D125089
2022-04-14 18:56:44 +08:00
m_memory_tag_options = m_prev_memory_tag_options;
*** 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
<rdar://problem/12820334> I modified the "Args::StringtoAddress(...)" function to be able to evaluate address expressions. This is now used for any command line arguments or options that takes addresses like: memory read <addr> [<end-addr>] memory write <addr> breakpoint set --address <addr> disassemble --start-address <addr> --end-address <addr> It calls the expression parser to evaluate the address expression and will also work around the issue where the compiler doesn't like to add offsets to function pointers (which is what happens when you try to evaluate "main + 12"). So there is a temp fix in the Args::StringtoAddress() to work around this until we can get special compiler support for debug expressions with function pointers. llvm-svn: 169556
2012-12-07 06:49:16 +08:00
size_t item_count = m_format_options.GetCountValue().GetCurrentValue();
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
Fix Clang-tidy modernize-use-nullptr and modernize-use-default warnings in some files in source/Commands; other minor fixes. llvm-svn: 261389
2016-02-20 08:58:29 +08:00
// TODO For non-8-bit byte addressable architectures this needs to be
// revisited to fully support all lldb's range of formatting options.
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
// Furthermore code memory reads (for those architectures) will not be
// correctly formatted even w/o formatting options.
Resolve printf formatting warnings on Linux: - use macros from inttypes.h for format strings instead of OS-specific types Patch from Matt Kopec! llvm-svn: 168945
2012-11-30 05:49:15 +08:00
size_t item_byte_size =
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
target->GetArchitecture().GetDataByteSize() > 1
? target->GetArchitecture().GetDataByteSize()
Updated all commands that use a "--format" / "-f" options to use the new OptionGroupFormat. Updated OptionGroupFormat to be able to also use the "--size" and "--count" options. Commands that use a OptionGroupFormat instance can choose which of the options they want by initializing OptionGroupFormat accordingly. Clients can either get only the "--format", "--format" + "--size", or "--format" + "--size" + "--count". This is in preparation for upcoming chnages where there are alternate ways (GDB format specification) to set a format. llvm-svn: 142911
2011-10-25 14:44:01 +08:00
: m_format_options.GetByteSizeValue().GetCurrentValue();
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
const size_t num_per_line =
m_memory_options.m_num_per_line.GetCurrentValue();
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
<rdar://problem/13239809> Two things: 1) fixing a bug where memory read was not clearing the m_force flag after it was passed, so that subsequent memory reads would not need to be forced even if over boundary 2) adding a setting target.max-memory-read-size that you can set instead of the hardcoded 1024 bytes limit we had before llvm-svn: 183276
2013-06-05 06:54:16 +08:00
if (total_byte_size == 0) {
Preparatory infrastructural work to support dynamically determining sizes of ObjC types via the runtime This is necessary because the byte size of an ObjC class type is not reliably statically knowable (e.g. because superclasses sit deep in frameworks that we have no debug info for) The lack of reliable size info is a problem when trying to freeze-dry an ObjC instance (not the pointer, the pointee) This commit lays the foundation for having language runtimes help in figuring out byte sizes, and having ClangASTType ask for runtime help No feature change as no runtime actually implements the logic, and nowhere is an ExecutionContext passed in yet llvm-svn: 227274
2015-01-28 08:07:51 +08:00
total_byte_size = item_count * item_byte_size;
Added a new OptionValue subclass for lldb::Format: OptionValueFormat. Added new OptionGroup subclasses for: - output file for use with options: long opts: --outfile <path> --append--output short opts: -o <path> -A - format for use with options: long opts: --format <format> - variable object display controls for depth, pointer depth, wether to show types, show summary, show location, flat output, use objc "po" style summary. Modified ValueObjectMemory to be able to be created either with a TypeSP or a ClangASTType. Switched "memory read" over to use OptionGroup subclasses: one for the outfile options, one for the command specific options, and one for the format. llvm-svn: 130334
2011-04-28 06:04:39 +08:00
if (total_byte_size == 0)
Remove %zx in printf (only GCC supports it, not MSVC). llvm-svn: 203349
2014-03-09 01:15:35 +08:00
total_byte_size = 32;
<rdar://problem/14521548> Fixed a crasher where if you accidentally specify a size that is too large when reading memory, LLDB would crash. llvm-svn: 187060
2013-07-25 02:17:35 +08:00
}
Added a new OptionValue subclass for lldb::Format: OptionValueFormat. Added new OptionGroup subclasses for: - output file for use with options: long opts: --outfile <path> --append--output short opts: -o <path> -A - format for use with options: long opts: --format <format> - variable object display controls for depth, pointer depth, wether to show types, show summary, show location, flat output, use objc "po" style summary. Modified ValueObjectMemory to be able to be created either with a TypeSP or a ClangASTType. Switched "memory read" over to use OptionGroup subclasses: one for the outfile options, one for the command specific options, and one for the format. llvm-svn: 130334
2011-04-28 06:04:39 +08:00
if (argc > 0)
[lldb][NFC] Remove ArgEntry::ref member The StringRef should always be identical to the C string, so we might as well just create the StringRef from the C-string. This might be slightly slower until we implement the storage of ArgEntry with a string instead of a std::unique_ptr<char[]>. Until then we have to do the additional strlen on the C string to construct the StringRef. llvm-svn: 371842
2019-09-13 19:26:48 +08:00
addr = OptionArgParser::ToAddress(&m_exe_ctx, command[0].ref(),
Move Args::StringTo*** functions to a new OptionArgParser class Summary: The idea behind this is to move the functionality which depend on other lldb classes into a separate class. This way, the Args class can be turned into a lightweight arc+argv wrapper and moved into the lower lldb layers. Reviewers: jingham, zturner Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D44306 llvm-svn: 329677
2018-04-10 17:03:59 +08:00
LLDB_INVALID_ADDRESS, &error);
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
<rdar://problem/11990131> Memory read's "repeat" behavior forgets "-t" option. It also formatted the type as hex bytes + ASCII. Now we revert to the default format when displaying types unless the user sets the format option manually. llvm-svn: 170265
2012-12-15 10:08:17 +08:00
if (addr == LLDB_INVALID_ADDRESS) {
result.AppendError("invalid start address expression.");
result.AppendError(error.AsCString());
Added a new OptionValue subclass for lldb::Format: OptionValueFormat. Added new OptionGroup subclasses for: - output file for use with options: long opts: --outfile <path> --append--output short opts: -o <path> -A - format for use with options: long opts: --format <format> - variable object display controls for depth, pointer depth, wether to show types, show summary, show location, flat output, use objc "po" style summary. Modified ValueObjectMemory to be able to be created either with a TypeSP or a ClangASTType. Switched "memory read" over to use OptionGroup subclasses: one for the outfile options, one for the command specific options, and one for the format. llvm-svn: 130334
2011-04-28 06:04:39 +08:00
return false;
*** 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
}
[lldb] Remove non address bits from memory read arguments Addresses on AArch64 can have top byte tags, memory tags and pointer authentication signatures in the upper bits. While testing memory tagging I found that memory read couldn't read a range if the two addresses had different tags. The same could apply to signed pointers given the right circumstance. (lldb) memory read mte_buf_alt_tag mte_buf+16 error: end address (0x900fffff7ff8010) must be greater than the start address (0xa00fffff7ff8000). Or it would try to read a lot more memory than expected. (lldb) memory read mte_buf mte_buf_alt_tag+16 error: Normally, 'memory read' will not read over 1024 bytes of data. error: Please use --force to override this restriction just once. error: or set target.max-memory-read-size if you will often need a larger limit. Fix this by removing non address bits before we calculate the read range. A test is added for AArch64 Linux that confirms this by using the top byte ignore feature. This means that if you do read with a tagged pointer the output does not include those tags. This is potentially confusing but I think overall it's better that we don't pretend that we're reading memory from a range that the process is unable to map. (lldb) p ptr1 (char *) $4 = 0x3400fffffffff140 "\x80\xf1\xff\xff\xff\xff" (lldb) p ptr2 (char *) $5 = 0x5600fffffffff140 "\x80\xf1\xff\xff\xff\xff" (lldb) memory read ptr1 ptr2+16 0xfffffffff140: 80 f1 ff ff ff ff 00 00 38 70 bc f7 ff ff 00 00 ........8p...... Reviewed By: omjavaid, danielkiss Differential Revision: https://reviews.llvm.org/D103626
2021-11-03 20:10:40 +08:00
ABISP abi = m_exe_ctx.GetProcessPtr()->GetABI();
if (abi)
addr = abi->FixDataAddress(addr);
Added a new OptionValue subclass for lldb::Format: OptionValueFormat. Added new OptionGroup subclasses for: - output file for use with options: long opts: --outfile <path> --append--output short opts: -o <path> -A - format for use with options: long opts: --format <format> - variable object display controls for depth, pointer depth, wether to show types, show summary, show location, flat output, use objc "po" style summary. Modified ValueObjectMemory to be able to be created either with a TypeSP or a ClangASTType. Switched "memory read" over to use OptionGroup subclasses: one for the outfile options, one for the command specific options, and one for the format. llvm-svn: 130334
2011-04-28 06:04:39 +08:00
if (argc == 2) {
Move Args::StringTo*** functions to a new OptionArgParser class Summary: The idea behind this is to move the functionality which depend on other lldb classes into a separate class. This way, the Args class can be turned into a lightweight arc+argv wrapper and moved into the lower lldb layers. Reviewers: jingham, zturner Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D44306 llvm-svn: 329677
2018-04-10 17:03:59 +08:00
lldb::addr_t end_addr = OptionArgParser::ToAddress(
[lldb][NFC] Remove ArgEntry::ref member The StringRef should always be identical to the C string, so we might as well just create the StringRef from the C-string. This might be slightly slower until we implement the storage of ArgEntry with a string instead of a std::unique_ptr<char[]>. Until then we have to do the additional strlen on the C string to construct the StringRef. llvm-svn: 371842
2019-09-13 19:26:48 +08:00
&m_exe_ctx, command[1].ref(), LLDB_INVALID_ADDRESS, nullptr);
[lldb] Remove non address bits from memory read arguments Addresses on AArch64 can have top byte tags, memory tags and pointer authentication signatures in the upper bits. While testing memory tagging I found that memory read couldn't read a range if the two addresses had different tags. The same could apply to signed pointers given the right circumstance. (lldb) memory read mte_buf_alt_tag mte_buf+16 error: end address (0x900fffff7ff8010) must be greater than the start address (0xa00fffff7ff8000). Or it would try to read a lot more memory than expected. (lldb) memory read mte_buf mte_buf_alt_tag+16 error: Normally, 'memory read' will not read over 1024 bytes of data. error: Please use --force to override this restriction just once. error: or set target.max-memory-read-size if you will often need a larger limit. Fix this by removing non address bits before we calculate the read range. A test is added for AArch64 Linux that confirms this by using the top byte ignore feature. This means that if you do read with a tagged pointer the output does not include those tags. This is potentially confusing but I think overall it's better that we don't pretend that we're reading memory from a range that the process is unable to map. (lldb) p ptr1 (char *) $4 = 0x3400fffffffff140 "\x80\xf1\xff\xff\xff\xff" (lldb) p ptr2 (char *) $5 = 0x5600fffffffff140 "\x80\xf1\xff\xff\xff\xff" (lldb) memory read ptr1 ptr2+16 0xfffffffff140: 80 f1 ff ff ff ff 00 00 38 70 bc f7 ff ff 00 00 ........8p...... Reviewed By: omjavaid, danielkiss Differential Revision: https://reviews.llvm.org/D103626
2021-11-03 20:10:40 +08:00
if (end_addr != LLDB_INVALID_ADDRESS && abi)
end_addr = abi->FixDataAddress(end_addr);
Added a new OptionValue subclass for lldb::Format: OptionValueFormat. Added new OptionGroup subclasses for: - output file for use with options: long opts: --outfile <path> --append--output short opts: -o <path> -A - format for use with options: long opts: --format <format> - variable object display controls for depth, pointer depth, wether to show types, show summary, show location, flat output, use objc "po" style summary. Modified ValueObjectMemory to be able to be created either with a TypeSP or a ClangASTType. Switched "memory read" over to use OptionGroup subclasses: one for the outfile options, one for the command specific options, and one for the format. llvm-svn: 130334
2011-04-28 06:04:39 +08:00
if (end_addr == LLDB_INVALID_ADDRESS) {
result.AppendError("invalid end address expression.");
<rdar://problem/12820334> I modified the "Args::StringtoAddress(...)" function to be able to evaluate address expressions. This is now used for any command line arguments or options that takes addresses like: memory read <addr> [<end-addr>] memory write <addr> breakpoint set --address <addr> disassemble --start-address <addr> --end-address <addr> It calls the expression parser to evaluate the address expression and will also work around the issue where the compiler doesn't like to add offsets to function pointers (which is what happens when you try to evaluate "main + 12"). So there is a temp fix in the Args::StringtoAddress() to work around this until we can get special compiler support for debug expressions with function pointers. llvm-svn: 169556
2012-12-07 06:49:16 +08:00
result.AppendError(error.AsCString());
Added a new OptionValue subclass for lldb::Format: OptionValueFormat. Added new OptionGroup subclasses for: - output file for use with options: long opts: --outfile <path> --append--output short opts: -o <path> -A - format for use with options: long opts: --format <format> - variable object display controls for depth, pointer depth, wether to show types, show summary, show location, flat output, use objc "po" style summary. Modified ValueObjectMemory to be able to be created either with a TypeSP or a ClangASTType. Switched "memory read" over to use OptionGroup subclasses: one for the outfile options, one for the command specific options, and one for the format. llvm-svn: 130334
2011-04-28 06:04:39 +08:00
return false;
} else if (end_addr <= addr) {
result.AppendErrorWithFormat(
"size_t" isn't always 64 bit, it is 32 bit on 32 bit systems. All printf style statements that were assuming size_t were 64 bit were changed, and they were also changed to display them as unsigned values as "size_t" isn't signed. If you print anything with 'size_t', please cast it to "uint64_t" in the printf and use PRIu64 or PRIx64. llvm-svn: 202738
2014-03-04 03:15:20 +08:00
"end address (0x%" PRIx64
[lldb] Correct typo in memory read error Reviewed By: teemperor Differential Revision: https://reviews.llvm.org/D98770
2021-03-17 17:43:06 +08:00
") must be greater than the start address (0x%" PRIx64 ").\n",
Resolve printf formatting warnings on Linux: - use macros from inttypes.h for format strings instead of OS-specific types Patch from Matt Kopec! llvm-svn: 168945
2012-11-30 05:49:15 +08:00
end_addr, addr);
Added a new OptionValue subclass for lldb::Format: OptionValueFormat. Added new OptionGroup subclasses for: - output file for use with options: long opts: --outfile <path> --append--output short opts: -o <path> -A - format for use with options: long opts: --format <format> - variable object display controls for depth, pointer depth, wether to show types, show summary, show location, flat output, use objc "po" style summary. Modified ValueObjectMemory to be able to be created either with a TypeSP or a ClangASTType. Switched "memory read" over to use OptionGroup subclasses: one for the outfile options, one for the command specific options, and one for the format. llvm-svn: 130334
2011-04-28 06:04:39 +08:00
return false;
} else if (m_format_options.GetCountValue().OptionWasSet()) {
result.AppendErrorWithFormat(
"specify either the end address (0x%" PRIx64
<rdar://problem/13069948> Major fixed to allow reading files that are over 4GB. The main problems were that the DataExtractor was using 32 bit offsets as a data cursor, and since we mmap all of our object files we could run into cases where if we had a very large core file that was over 4GB, we were running into the 4GB boundary. So I defined a new "lldb::offset_t" which should be used for all file offsets. After making this change, I enabled warnings for data loss and for enexpected implicit conversions temporarily and found a ton of things that I fixed. Any functions that take an index internally, should use "size_t" for any indexes and also should return "size_t" for any sizes of collections. llvm-svn: 173463
2013-01-26 02:06:21 +08:00
") or the count (--count %" PRIu64 "), not both.\n",
end_addr, (uint64_t)item_count);
return false;
*** 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/13069948> Major fixed to allow reading files that are over 4GB. The main problems were that the DataExtractor was using 32 bit offsets as a data cursor, and since we mmap all of our object files we could run into cases where if we had a very large core file that was over 4GB, we were running into the 4GB boundary. So I defined a new "lldb::offset_t" which should be used for all file offsets. After making this change, I enabled warnings for data loss and for enexpected implicit conversions temporarily and found a ton of things that I fixed. Any functions that take an index internally, should use "size_t" for any indexes and also should return "size_t" for any sizes of collections. llvm-svn: 173463
2013-01-26 02:06:21 +08:00
total_byte_size = end_addr - addr;
item_count = total_byte_size / item_byte_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
}
<rdar://problem/13069948> Major fixed to allow reading files that are over 4GB. The main problems were that the DataExtractor was using 32 bit offsets as a data cursor, and since we mmap all of our object files we could run into cases where if we had a very large core file that was over 4GB, we were running into the 4GB boundary. So I defined a new "lldb::offset_t" which should be used for all file offsets. After making this change, I enabled warnings for data loss and for enexpected implicit conversions temporarily and found a ton of things that I fixed. Any functions that take an index internally, should use "size_t" for any indexes and also should return "size_t" for any sizes of collections. llvm-svn: 173463
2013-01-26 02:06:21 +08:00
uint32_t max_unforced_size = target->GetMaximumMemReadSize();
*** 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 new options to memory read to allow saving memory to disk as binary bytes or as an ASCII text dump. - The output file is specified with the "--outfile FILE" option. - The memory can be appended to an existing file using the "--append" option. - The memory will be written as an ASCII text dump by default, or as binary with the "--binary" option. Added new options to memory write to allow writing all or part of a file on disk to target memory: - The input file is specified using the "--infile FILE" option - The offset at which to start in the file defaults to zero, but can be overridden using the "--offset OFFSET" option. If the size is not specified, the remaining number of bytes in the file will be used as the default byte size. - The number of bytes to write defaults to the entire file byte size, but can be changed with the "--size COUNT" option. llvm-svn: 116172
2010-10-11 04:52:20 +08:00
if (total_byte_size > max_unforced_size && !m_memory_options.m_force) {
<rdar://problem/13069948> Major fixed to allow reading files that are over 4GB. The main problems were that the DataExtractor was using 32 bit offsets as a data cursor, and since we mmap all of our object files we could run into cases where if we had a very large core file that was over 4GB, we were running into the 4GB boundary. So I defined a new "lldb::offset_t" which should be used for all file offsets. After making this change, I enabled warnings for data loss and for enexpected implicit conversions temporarily and found a ton of things that I fixed. Any functions that take an index internally, should use "size_t" for any indexes and also should return "size_t" for any sizes of collections. llvm-svn: 173463
2013-01-26 02:06:21 +08:00
result.AppendErrorWithFormat(
"Normally, \'memory read\' will not read over %" PRIu32
Resolve printf formatting warnings on Linux: - use macros from inttypes.h for format strings instead of OS-specific types Patch from Matt Kopec! llvm-svn: 168945
2012-11-30 05:49:15 +08:00
" bytes of data.\n",
max_unforced_size);
result.AppendErrorWithFormat(
"Please use --force to override this restriction just once.\n");
result.AppendErrorWithFormat("or set target.max-memory-read-size if you "
"will often need a larger limit.\n");
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
return false;
*** 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
}
[lldb] Refactor DataBuffer so we can map files as read-only Currently, all data buffers are assumed to be writable. This is a problem on macOS where it's not allowed to load unsigned binaries in memory as writable. To be more precise, MAP_RESILIENT_CODESIGN and MAP_RESILIENT_MEDIA need to be set for mapped (unsigned) binaries on our platform. Binaries are mapped through FileSystem::CreateDataBuffer which returns a DataBufferLLVM. The latter is backed by a llvm::WritableMemoryBuffer because every DataBuffer in LLDB is considered to be writable. In order to use a read-only llvm::MemoryBuffer I had to split our abstraction around it. This patch distinguishes between a DataBuffer (read-only) and WritableDataBuffer (read-write) and updates LLDB to use the appropriate one. rdar://74890607 Differential revision: https://reviews.llvm.org/D122856
2022-04-02 06:59:18 +08:00
WritableDataBufferSP data_sp;
Added a new OptionValue subclass for lldb::Format: OptionValueFormat. Added new OptionGroup subclasses for: - output file for use with options: long opts: --outfile <path> --append--output short opts: -o <path> -A - format for use with options: long opts: --format <format> - variable object display controls for depth, pointer depth, wether to show types, show summary, show location, flat output, use objc "po" style summary. Modified ValueObjectMemory to be able to be created either with a TypeSP or a ClangASTType. Switched "memory read" over to use OptionGroup subclasses: one for the outfile options, one for the command specific options, and one for the format. llvm-svn: 130334
2011-04-28 06:04:39 +08:00
size_t bytes_read = 0;
[Expression] Add PersistentExpressionState::GetCompilerTypeFromPersistentDecl Summary: PersistentStateExpressions (e.g. ClangPersistentVariables) have the ability to define types using expressions that persist throughout the debugging session. GetCompilerTypeFromPersistentDecl is a useful operation to have if you need to use any of those persistently declared types, like in CommandObjectMemory. This decouples clang from CommandObjectMemory and decouples Plugins from Commands in general. Differential Revision: https://reviews.llvm.org/D62797 llvm-svn: 363183
2019-06-13 01:47:06 +08:00
if (compiler_type.GetOpaqueQualType()) {
Resolve printf formatting warnings on Linux: - use macros from inttypes.h for format strings instead of OS-specific types Patch from Matt Kopec! llvm-svn: 168945
2012-11-30 05:49:15 +08:00
// Make sure we don't display our type as ASCII bytes like the default
<rdar://problem/11990131> Memory read's "repeat" behavior forgets "-t" option. It also formatted the type as hex bytes + ASCII. Now we revert to the default format when displaying types unless the user sets the format option manually. llvm-svn: 170265
2012-12-15 10:08:17 +08:00
// memory read
Fix Clang-tidy modernize-use-nullptr and modernize-use-default warnings in some files in source/Commands; other minor fixes. llvm-svn: 261389
2016-02-20 08:58:29 +08:00
if (!m_format_options.GetFormatValue().OptionWasSet())
<rdar://problem/11990131> Memory read's "repeat" behavior forgets "-t" option. It also formatted the type as hex bytes + ASCII. Now we revert to the default format when displaying types unless the user sets the format option manually. llvm-svn: 170265
2012-12-15 10:08:17 +08:00
m_format_options.GetFormatValue().SetCurrentValue(eFormatDefault);
*** 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
[Expression] Add PersistentExpressionState::GetCompilerTypeFromPersistentDecl Summary: PersistentStateExpressions (e.g. ClangPersistentVariables) have the ability to define types using expressions that persist throughout the debugging session. GetCompilerTypeFromPersistentDecl is a useful operation to have if you need to use any of those persistently declared types, like in CommandObjectMemory. This decouples clang from CommandObjectMemory and decouples Plugins from Commands in general. Differential Revision: https://reviews.llvm.org/D62797 llvm-svn: 363183
2019-06-13 01:47:06 +08:00
llvm::Optional<uint64_t> size = compiler_type.GetByteSize(nullptr);
Make CompilerType::getBitSize() / getByteSize() return an optional result. NFC The code in LLDB assumes that CompilerType and friends use the size 0 as a sentinel value to signal an error. This works for C++, where no zero-sized type exists, but in many other programming languages (including I believe C) types of size zero are possible and even common. This is a particular pain point in swift-lldb, where extra code exists to double-check that a type is *really* of size zero and not an error at various locations. To remedy this situation, this patch starts by converting CompilerType::getBitSize() and getByteSize() to return an optional result. To avoid wasting space, I hand-rolled my own optional data type assuming that no type is larger than what fits into 63 bits. Follow-up patches would make similar changes to the ValueObject hierarchy. rdar://problem/47178964 Differential Revision: https://reviews.llvm.org/D56688 llvm-svn: 351214
2019-01-16 02:07:52 +08:00
if (!size) {
result.AppendError("can't get size of type");
return false;
}
bytes_read = *size * m_format_options.GetCountValue().GetCurrentValue();
*** 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
A simple fix for the GDB format strings so the byte size parameter gets properly marked as valid. Also modified the "memory read" command to be able to intelligently repeat subsequent memory requests, so now you can do: (lldb) memory read --format hex --count 32 0x1000 Then hit enter to keep viewing the memory that follows the last valid request. llvm-svn: 143015
2011-10-26 12:32:38 +08:00
if (argc > 0)
Make CompilerType::getBitSize() / getByteSize() return an optional result. NFC The code in LLDB assumes that CompilerType and friends use the size 0 as a sentinel value to signal an error. This works for C++, where no zero-sized type exists, but in many other programming languages (including I believe C) types of size zero are possible and even common. This is a particular pain point in swift-lldb, where extra code exists to double-check that a type is *really* of size zero and not an error at various locations. To remedy this situation, this patch starts by converting CompilerType::getBitSize() and getByteSize() to return an optional result. To avoid wasting space, I hand-rolled my own optional data type assuming that no type is larger than what fits into 63 bits. Follow-up patches would make similar changes to the ValueObject hierarchy. rdar://problem/47178964 Differential Revision: https://reviews.llvm.org/D56688 llvm-svn: 351214
2019-01-16 02:07:52 +08:00
addr = addr + (*size * m_memory_options.m_offset.GetCurrentValue());
<rdar://problem/12437929> Providing a special mode of operator for "memory read -f c-str" which actually works in most common cases Where the old behavior would provide: (lldb) mem read --format s `foo` 0x100000f5d: NULL Now we do: (lldb) mem read --format s `foo` 0x100000f5d: "hello world" You can also specify a count and that many strings will be showed starting at the initial address: (lldb) mem read -c 2 -f c-str `foo` 0x100000f1d: "hello world" 0x100000f29: "short" llvm-svn: 173076
2013-01-22 03:20:50 +08:00
} else if (m_format_options.GetFormatValue().GetCurrentValue() !=
eFormatCString) {
Use std::make_shared in LLDB (NFC) Unlike std::make_unique, which is only available since C++14, std::make_shared is available since C++11. Not only is std::make_shared a lot more readable compared to ::reset(new), it also performs a single heap allocation for the object and control block. Differential revision: https://reviews.llvm.org/D57990 llvm-svn: 353764
2019-02-12 07:13:08 +08:00
data_sp = std::make_shared<DataBufferHeap>(total_byte_size, '\0');
Fix Clang-tidy modernize-use-nullptr and modernize-use-default warnings in some files in source/Commands; other minor fixes. llvm-svn: 261389
2016-02-20 08:58:29 +08:00
if (data_sp->GetBytes() == nullptr) {
"size_t" isn't always 64 bit, it is 32 bit on 32 bit systems. All printf style statements that were assuming size_t were 64 bit were changed, and they were also changed to display them as unsigned values as "size_t" isn't signed. If you print anything with 'size_t', please cast it to "uint64_t" in the printf and use PRIu64 or PRIx64. llvm-svn: 202738
2014-03-04 03:15:20 +08:00
result.AppendErrorWithFormat(
Resolve printf formatting warnings on Linux: - use macros from inttypes.h for format strings instead of OS-specific types Patch from Matt Kopec! llvm-svn: 168945
2012-11-30 05:49:15 +08:00
"can't allocate 0x%" PRIx32
" bytes for the memory read buffer, specify a smaller size to read",
(uint32_t)total_byte_size);
Added new options to memory read to allow saving memory to disk as binary bytes or as an ASCII text dump. - The output file is specified with the "--outfile FILE" option. - The memory can be appended to an existing file using the "--append" option. - The memory will be written as an ASCII text dump by default, or as binary with the "--binary" option. Added new options to memory write to allow writing all or part of a file on disk to target memory: - The input file is specified using the "--infile FILE" option - The offset at which to start in the file defaults to zero, but can be overridden using the "--offset OFFSET" option. If the size is not specified, the remaining number of bytes in the file will be used as the default byte size. - The number of bytes to write defaults to the entire file byte size, but can be changed with the "--size COUNT" option. llvm-svn: 116172
2010-10-11 04:52:20 +08:00
return false;
}
*** 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 new options to memory read to allow saving memory to disk as binary bytes or as an ASCII text dump. - The output file is specified with the "--outfile FILE" option. - The memory can be appended to an existing file using the "--append" option. - The memory will be written as an ASCII text dump by default, or as binary with the "--binary" option. Added new options to memory write to allow writing all or part of a file on disk to target memory: - The input file is specified using the "--infile FILE" option - The offset at which to start in the file defaults to zero, but can be overridden using the "--offset OFFSET" option. If the size is not specified, the remaining number of bytes in the file will be used as the default byte size. - The number of bytes to write defaults to the entire file byte size, but can be changed with the "--size COUNT" option. llvm-svn: 116172
2010-10-11 04:52:20 +08:00
Address address(addr, nullptr);
Target::ReadMemory read from read-only binary file Section, not memory Commiting this patch for Augusto Noronha who is getting set up still. This patch changes Target::ReadMemory so the default behavior when a read is in a Section that is read-only is to fetch the data from the local binary image, instead of reading it from memory. Update all callers to use their old preferences (the old prefer_file_cache bool) using the new API; we should revisit these calls and see if they really intend to read live memory, or if reading from a read-only Section would be equivalent and important for performance-sensitive cases. rdar://30634422 Differential revision: https://reviews.llvm.org/D100338
2021-04-17 07:10:16 +08:00
bytes_read = target->ReadMemory(address, data_sp->GetBytes(),
data_sp->GetByteSize(), error, true);
Added a new OptionValue subclass for lldb::Format: OptionValueFormat. Added new OptionGroup subclasses for: - output file for use with options: long opts: --outfile <path> --append--output short opts: -o <path> -A - format for use with options: long opts: --format <format> - variable object display controls for depth, pointer depth, wether to show types, show summary, show location, flat output, use objc "po" style summary. Modified ValueObjectMemory to be able to be created either with a TypeSP or a ClangASTType. Switched "memory read" over to use OptionGroup subclasses: one for the outfile options, one for the command specific options, and one for the format. llvm-svn: 130334
2011-04-28 06:04:39 +08:00
if (bytes_read == 0) {
const char *error_cstr = error.AsCString();
<rdar://problem/11534686> Reading memory from a file when the section is encrypted doesn't show an error. No we do. llvm-svn: 157484
2012-05-26 01:05:55 +08:00
if (error_cstr && error_cstr[0]) {
Added a new OptionValue subclass for lldb::Format: OptionValueFormat. Added new OptionGroup subclasses for: - output file for use with options: long opts: --outfile <path> --append--output short opts: -o <path> -A - format for use with options: long opts: --format <format> - variable object display controls for depth, pointer depth, wether to show types, show summary, show location, flat output, use objc "po" style summary. Modified ValueObjectMemory to be able to be created either with a TypeSP or a ClangASTType. Switched "memory read" over to use OptionGroup subclasses: one for the outfile options, one for the command specific options, and one for the format. llvm-svn: 130334
2011-04-28 06:04:39 +08:00
result.AppendError(error_cstr);
} else {
result.AppendErrorWithFormat(
"failed to read memory from 0x%" PRIx64 ".\n", addr);
Added new options to memory read to allow saving memory to disk as binary bytes or as an ASCII text dump. - The output file is specified with the "--outfile FILE" option. - The memory can be appended to an existing file using the "--append" option. - The memory will be written as an ASCII text dump by default, or as binary with the "--binary" option. Added new options to memory write to allow writing all or part of a file on disk to target memory: - The input file is specified using the "--infile FILE" option - The offset at which to start in the file defaults to zero, but can be overridden using the "--offset OFFSET" option. If the size is not specified, the remaining number of bytes in the file will be used as the default byte size. - The number of bytes to write defaults to the entire file byte size, but can be changed with the "--size COUNT" option. llvm-svn: 116172
2010-10-11 04:52:20 +08:00
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
return false;
*** 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 a new OptionValue subclass for lldb::Format: OptionValueFormat. Added new OptionGroup subclasses for: - output file for use with options: long opts: --outfile <path> --append--output short opts: -o <path> -A - format for use with options: long opts: --format <format> - variable object display controls for depth, pointer depth, wether to show types, show summary, show location, flat output, use objc "po" style summary. Modified ValueObjectMemory to be able to be created either with a TypeSP or a ClangASTType. Switched "memory read" over to use OptionGroup subclasses: one for the outfile options, one for the command specific options, and one for the format. llvm-svn: 130334
2011-04-28 06:04:39 +08:00
if (bytes_read < total_byte_size)
"size_t" isn't always 64 bit, it is 32 bit on 32 bit systems. All printf style statements that were assuming size_t were 64 bit were changed, and they were also changed to display them as unsigned values as "size_t" isn't signed. If you print anything with 'size_t', please cast it to "uint64_t" in the printf and use PRIu64 or PRIx64. llvm-svn: 202738
2014-03-04 03:15:20 +08:00
result.AppendWarningWithFormat(
"Not all bytes (%" PRIu64 "/%" PRIu64
") were able to be read from 0x%" PRIx64 ".\n",
(uint64_t)bytes_read, (uint64_t)total_byte_size, addr);
*** 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 {
<rdar://problem/12437929> Providing a special mode of operator for "memory read -f c-str" which actually works in most common cases Where the old behavior would provide: (lldb) mem read --format s `foo` 0x100000f5d: NULL Now we do: (lldb) mem read --format s `foo` 0x100000f5d: "hello world" You can also specify a count and that many strings will be showed starting at the initial address: (lldb) mem read -c 2 -f c-str `foo` 0x100000f1d: "hello world" 0x100000f29: "short" llvm-svn: 173076
2013-01-22 03:20:50 +08:00
// we treat c-strings as a special case because they do not have a fixed
*** 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
// size
<rdar://problem/12437929> Providing a special mode of operator for "memory read -f c-str" which actually works in most common cases Where the old behavior would provide: (lldb) mem read --format s `foo` 0x100000f5d: NULL Now we do: (lldb) mem read --format s `foo` 0x100000f5d: "hello world" You can also specify a count and that many strings will be showed starting at the initial address: (lldb) mem read -c 2 -f c-str `foo` 0x100000f1d: "hello world" 0x100000f29: "short" llvm-svn: 173076
2013-01-22 03:20:50 +08:00
if (m_format_options.GetByteSizeValue().OptionWasSet() &&
!m_format_options.HasGDBFormat())
item_byte_size = m_format_options.GetByteSizeValue().GetCurrentValue();
Added new options to memory read to allow saving memory to disk as binary bytes or as an ASCII text dump. - The output file is specified with the "--outfile FILE" option. - The memory can be appended to an existing file using the "--append" option. - The memory will be written as an ASCII text dump by default, or as binary with the "--binary" option. Added new options to memory write to allow writing all or part of a file on disk to target memory: - The input file is specified using the "--infile FILE" option - The offset at which to start in the file defaults to zero, but can be overridden using the "--offset OFFSET" option. If the size is not specified, the remaining number of bytes in the file will be used as the default byte size. - The number of bytes to write defaults to the entire file byte size, but can be changed with the "--size COUNT" option. llvm-svn: 116172
2010-10-11 04:52:20 +08:00
else
item_byte_size = target->GetMaximumSizeOfStringSummary();
if (!m_format_options.GetCountValue().OptionWasSet())
<rdar://problem/12437929> Providing a special mode of operator for "memory read -f c-str" which actually works in most common cases Where the old behavior would provide: (lldb) mem read --format s `foo` 0x100000f5d: NULL Now we do: (lldb) mem read --format s `foo` 0x100000f5d: "hello world" You can also specify a count and that many strings will be showed starting at the initial address: (lldb) mem read -c 2 -f c-str `foo` 0x100000f1d: "hello world" 0x100000f29: "short" llvm-svn: 173076
2013-01-22 03:20:50 +08:00
item_count = 1;
Use std::make_shared in LLDB (NFC) Unlike std::make_unique, which is only available since C++14, std::make_shared is available since C++11. Not only is std::make_shared a lot more readable compared to ::reset(new), it also performs a single heap allocation for the object and control block. Differential revision: https://reviews.llvm.org/D57990 llvm-svn: 353764
2019-02-12 07:13:08 +08:00
data_sp = std::make_shared<DataBufferHeap>(
(item_byte_size + 1) * item_count,
'\0'); // account for NULLs as necessary
Fix Clang-tidy modernize-use-nullptr and modernize-use-default warnings in some files in source/Commands; other minor fixes. llvm-svn: 261389
2016-02-20 08:58:29 +08:00
if (data_sp->GetBytes() == nullptr) {
<rdar://problem/13239809> Two things: 1) fixing a bug where memory read was not clearing the m_force flag after it was passed, so that subsequent memory reads would not need to be forced even if over boundary 2) adding a setting target.max-memory-read-size that you can set instead of the hardcoded 1024 bytes limit we had before llvm-svn: 183276
2013-06-05 06:54:16 +08:00
result.AppendErrorWithFormat(
<rdar://problem/14521548> Fixed a crasher where if you accidentally specify a size that is too large when reading memory, LLDB would crash. llvm-svn: 187060
2013-07-25 02:17:35 +08:00
"can't allocate 0x%" PRIx64
" bytes for the memory read buffer, specify a smaller size to read",
(uint64_t)((item_byte_size + 1) * item_count));
Added a --force option to "memory read," disallowing reads over 1KiB in total size unless the user explicitly allows them. llvm-svn: 155750
2012-04-28 09:27:38 +08:00
return false;
*** 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/12437929> Providing a special mode of operator for "memory read -f c-str" which actually works in most common cases Where the old behavior would provide: (lldb) mem read --format s `foo` 0x100000f5d: NULL Now we do: (lldb) mem read --format s `foo` 0x100000f5d: "hello world" You can also specify a count and that many strings will be showed starting at the initial address: (lldb) mem read -c 2 -f c-str `foo` 0x100000f1d: "hello world" 0x100000f29: "short" llvm-svn: 173076
2013-01-22 03:20:50 +08:00
uint8_t *data_ptr = data_sp->GetBytes();
Added new options to memory read to allow saving memory to disk as binary bytes or as an ASCII text dump. - The output file is specified with the "--outfile FILE" option. - The memory can be appended to an existing file using the "--append" option. - The memory will be written as an ASCII text dump by default, or as binary with the "--binary" option. Added new options to memory write to allow writing all or part of a file on disk to target memory: - The input file is specified using the "--infile FILE" option - The offset at which to start in the file defaults to zero, but can be overridden using the "--offset OFFSET" option. If the size is not specified, the remaining number of bytes in the file will be used as the default byte size. - The number of bytes to write defaults to the entire file byte size, but can be changed with the "--size COUNT" option. llvm-svn: 116172
2010-10-11 04:52:20 +08:00
auto data_addr = addr;
auto count = item_count;
<rdar://problem/12437929> Providing a special mode of operator for "memory read -f c-str" which actually works in most common cases Where the old behavior would provide: (lldb) mem read --format s `foo` 0x100000f5d: NULL Now we do: (lldb) mem read --format s `foo` 0x100000f5d: "hello world" You can also specify a count and that many strings will be showed starting at the initial address: (lldb) mem read -c 2 -f c-str `foo` 0x100000f1d: "hello world" 0x100000f29: "short" llvm-svn: 173076
2013-01-22 03:20:50 +08:00
item_count = 0;
If memory read does not find a NULL terminator, still print whatever it gathered instead of just NOP'ing out However, remark that this is an incomplete chunk of data by still emitting the "no NULL found" warning rdar://20330073 llvm-svn: 234194
2015-04-07 02:41:17 +08:00
bool break_on_no_NULL = false;
<rdar://problem/12437929> Providing a special mode of operator for "memory read -f c-str" which actually works in most common cases Where the old behavior would provide: (lldb) mem read --format s `foo` 0x100000f5d: NULL Now we do: (lldb) mem read --format s `foo` 0x100000f5d: "hello world" You can also specify a count and that many strings will be showed starting at the initial address: (lldb) mem read -c 2 -f c-str `foo` 0x100000f1d: "hello world" 0x100000f29: "short" llvm-svn: 173076
2013-01-22 03:20:50 +08:00
while (item_count < count) {
std::string buffer;
buffer.resize(item_byte_size + 1, 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;
Added new options to memory read to allow saving memory to disk as binary bytes or as an ASCII text dump. - The output file is specified with the "--outfile FILE" option. - The memory can be appended to an existing file using the "--append" option. - The memory will be written as an ASCII text dump by default, or as binary with the "--binary" option. Added new options to memory write to allow writing all or part of a file on disk to target memory: - The input file is specified using the "--infile FILE" option - The offset at which to start in the file defaults to zero, but can be overridden using the "--offset OFFSET" option. If the size is not specified, the remaining number of bytes in the file will be used as the default byte size. - The number of bytes to write defaults to the entire file byte size, but can be changed with the "--size COUNT" option. llvm-svn: 116172
2010-10-11 04:52:20 +08:00
size_t read = target->ReadCStringFromMemory(data_addr, &buffer[0],
<rdar://problem/12437929> Providing a special mode of operator for "memory read -f c-str" which actually works in most common cases Where the old behavior would provide: (lldb) mem read --format s `foo` 0x100000f5d: NULL Now we do: (lldb) mem read --format s `foo` 0x100000f5d: "hello world" You can also specify a count and that many strings will be showed starting at the initial address: (lldb) mem read -c 2 -f c-str `foo` 0x100000f1d: "hello world" 0x100000f29: "short" llvm-svn: 173076
2013-01-22 03:20:50 +08:00
item_byte_size + 1, error);
if (error.Fail()) {
Resolve printf formatting warnings on Linux: - use macros from inttypes.h for format strings instead of OS-specific types Patch from Matt Kopec! llvm-svn: 168945
2012-11-30 05:49:15 +08:00
result.AppendErrorWithFormat(
Added new options to memory read to allow saving memory to disk as binary bytes or as an ASCII text dump. - The output file is specified with the "--outfile FILE" option. - The memory can be appended to an existing file using the "--append" option. - The memory will be written as an ASCII text dump by default, or as binary with the "--binary" option. Added new options to memory write to allow writing all or part of a file on disk to target memory: - The input file is specified using the "--infile FILE" option - The offset at which to start in the file defaults to zero, but can be overridden using the "--offset OFFSET" option. If the size is not specified, the remaining number of bytes in the file will be used as the default byte size. - The number of bytes to write defaults to the entire file byte size, but can be changed with the "--size COUNT" option. llvm-svn: 116172
2010-10-11 04:52:20 +08:00
"failed to read memory from 0x%" PRIx64 ".\n", addr);
<rdar://problem/14521548> Fixed a crasher where if you accidentally specify a size that is too large when reading memory, LLDB would crash. llvm-svn: 187060
2013-07-25 02:17:35 +08:00
return false;
Added new options to memory read to allow saving memory to disk as binary bytes or as an ASCII text dump. - The output file is specified with the "--outfile FILE" option. - The memory can be appended to an existing file using the "--append" option. - The memory will be written as an ASCII text dump by default, or as binary with the "--binary" option. Added new options to memory write to allow writing all or part of a file on disk to target memory: - The input file is specified using the "--infile FILE" option - The offset at which to start in the file defaults to zero, but can be overridden using the "--offset OFFSET" option. If the size is not specified, the remaining number of bytes in the file will be used as the default byte size. - The number of bytes to write defaults to the entire file byte size, but can be changed with the "--size COUNT" option. llvm-svn: 116172
2010-10-11 04:52:20 +08:00
}
Added a new OptionValue subclass for lldb::Format: OptionValueFormat. Added new OptionGroup subclasses for: - output file for use with options: long opts: --outfile <path> --append--output short opts: -o <path> -A - format for use with options: long opts: --format <format> - variable object display controls for depth, pointer depth, wether to show types, show summary, show location, flat output, use objc "po" style summary. Modified ValueObjectMemory to be able to be created either with a TypeSP or a ClangASTType. Switched "memory read" over to use OptionGroup subclasses: one for the outfile options, one for the command specific options, and one for the format. llvm-svn: 130334
2011-04-28 06:04:39 +08:00
if (item_byte_size == read) {
result.AppendWarningWithFormat(
Resolve printf formatting warnings on Linux: - use macros from inttypes.h for format strings instead of OS-specific types Patch from Matt Kopec! llvm-svn: 168945
2012-11-30 05:49:15 +08:00
"unable to find a NULL terminated string at 0x%" PRIx64
[lldb] Add missing space in C string format memory read warning Also add tests to check that we print the warning in the right circumstances. Reviewed By: labath Differential Revision: https://reviews.llvm.org/D114877
2021-12-01 22:56:18 +08:00
". Consider increasing the maximum read length.\n",
Resolve printf formatting warnings on Linux: - use macros from inttypes.h for format strings instead of OS-specific types Patch from Matt Kopec! llvm-svn: 168945
2012-11-30 05:49:15 +08:00
data_addr);
*** 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
--read;
If memory read does not find a NULL terminator, still print whatever it gathered instead of just NOP'ing out However, remark that this is an incomplete chunk of data by still emitting the "no NULL found" warning rdar://20330073 llvm-svn: 234194
2015-04-07 02:41:17 +08:00
break_on_no_NULL = true;
*** 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
If memory read does not find a NULL terminator, still print whatever it gathered instead of just NOP'ing out However, remark that this is an incomplete chunk of data by still emitting the "no NULL found" warning rdar://20330073 llvm-svn: 234194
2015-04-07 02:41:17 +08:00
++read; // account for final NULL byte
*** 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
Resolve printf formatting warnings on Linux: - use macros from inttypes.h for format strings instead of OS-specific types Patch from Matt Kopec! llvm-svn: 168945
2012-11-30 05:49:15 +08:00
memcpy(data_ptr, &buffer[0], read);
<rdar://problem/12437929> Providing a special mode of operator for "memory read -f c-str" which actually works in most common cases Where the old behavior would provide: (lldb) mem read --format s `foo` 0x100000f5d: NULL Now we do: (lldb) mem read --format s `foo` 0x100000f5d: "hello world" You can also specify a count and that many strings will be showed starting at the initial address: (lldb) mem read -c 2 -f c-str `foo` 0x100000f1d: "hello world" 0x100000f29: "short" llvm-svn: 173076
2013-01-22 03:20:50 +08:00
data_ptr += read;
data_addr += read;
bytes_read += read;
Resolve printf formatting warnings on Linux: - use macros from inttypes.h for format strings instead of OS-specific types Patch from Matt Kopec! llvm-svn: 168945
2012-11-30 05:49:15 +08:00
item_count++; // if we break early we know we only read item_count
<rdar://problem/12437929> Providing a special mode of operator for "memory read -f c-str" which actually works in most common cases Where the old behavior would provide: (lldb) mem read --format s `foo` 0x100000f5d: NULL Now we do: (lldb) mem read --format s `foo` 0x100000f5d: "hello world" You can also specify a count and that many strings will be showed starting at the initial address: (lldb) mem read -c 2 -f c-str `foo` 0x100000f1d: "hello world" 0x100000f29: "short" llvm-svn: 173076
2013-01-22 03:20:50 +08:00
// strings
*** 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 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
if (break_on_no_NULL)
*** 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
break;
}
Use std::make_shared in LLDB (NFC) Unlike std::make_unique, which is only available since C++14, std::make_shared is available since C++11. Not only is std::make_shared a lot more readable compared to ::reset(new), it also performs a single heap allocation for the object and control block. Differential revision: https://reviews.llvm.org/D57990 llvm-svn: 353764
2019-02-12 07:13:08 +08:00
data_sp =
std::make_shared<DataBufferHeap>(data_sp->GetBytes(), bytes_read + 1);
*** 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 a new OptionValue subclass for lldb::Format: OptionValueFormat. Added new OptionGroup subclasses for: - output file for use with options: long opts: --outfile <path> --append--output short opts: -o <path> -A - format for use with options: long opts: --format <format> - variable object display controls for depth, pointer depth, wether to show types, show summary, show location, flat output, use objc "po" style summary. Modified ValueObjectMemory to be able to be created either with a TypeSP or a ClangASTType. Switched "memory read" over to use OptionGroup subclasses: one for the outfile options, one for the command specific options, and one for the format. llvm-svn: 130334
2011-04-28 06:04:39 +08:00
m_next_addr = addr + bytes_read;
m_prev_byte_size = bytes_read;
<rdar://problem/11990131> Memory read's "repeat" behavior forgets "-t" option. It also formatted the type as hex bytes + ASCII. Now we revert to the default format when displaying types unless the user sets the format option manually. llvm-svn: 170265
2012-12-15 10:08:17 +08:00
m_prev_format_options = m_format_options;
<rdar://problem/14393032> DumpValueObject() 2.0 This checkin restores pre-Xcode5 functionality to the "po" (expr -O) command: - expr now has a new --description-verbosity (-v) argument, which takes either compact or full as a value (-v is the same as -vfull) When the full mode is on, "po" will show the extended output with type name, persistent variable name and value, as in (lldb) expr -O -v -- foo (id) $0 = 0x000000010010baf0 { 1 = 2; 2 = 3; } When -v is omitted, or -vcompact is passed, the Xcode5-style output will be shown, as in (lldb) expr -O -- foo { 1 = 2; 2 = 3; } - for a non-ObjectiveC object, LLDB will still try to retrieve a summary and/or value to display (lldb) po 5 5 -v also works in this mode (lldb) expr -O -vfull -- 5 (int) $4 = 5 On top of that, this is a major refactoring of the ValueObject printing code. The functionality is now factored into a ValueObjectPrinter class for easier maintenance in the future DumpValueObject() was turned into an instance method ValueObject::Dump() which simply calls through to the printer code, Dump_Impl has been removed Test case to follow llvm-svn: 191694
2013-10-01 03:11:51 +08:00
m_prev_memory_options = m_memory_options;
m_prev_outfile_options = m_outfile_options;
m_prev_varobj_options = m_varobj_options;
[lldb] Change implementation of memory read --show-tags option This does 2 things: * Moves it after the short options. Which makes sense given it's a niche, default off option. (if 2 files for one option seems a bit much, I am going to reuse them for "memory find" later) * Fixes the use of repeated commands. For example: memory read buf --show-tags <shows tags> memory read <shows tags> Added tests for the repetition and updated existing help tests. Reviewed By: omjavaid Differential Revision: https://reviews.llvm.org/D125089
2022-04-14 18:56:44 +08:00
m_prev_memory_tag_options = m_memory_tag_options;
[Expression] Add PersistentExpressionState::GetCompilerTypeFromPersistentDecl Summary: PersistentStateExpressions (e.g. ClangPersistentVariables) have the ability to define types using expressions that persist throughout the debugging session. GetCompilerTypeFromPersistentDecl is a useful operation to have if you need to use any of those persistently declared types, like in CommandObjectMemory. This decouples clang from CommandObjectMemory and decouples Plugins from Commands in general. Differential Revision: https://reviews.llvm.org/D62797 llvm-svn: 363183
2019-06-13 01:47:06 +08:00
m_prev_compiler_type = compiler_type;
*** 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
Convert FileSystem::Open() to return Expected<FileUP> Summary: This patch converts FileSystem::Open from this prototype: Status Open(File &File, const FileSpec &file_spec, ...); to this one: llvm::Expected<std::unique_ptr<File>> Open(const FileSpec &file_spec, ...); This is beneficial on its own, as llvm::Expected is a more modern and recommended error type than Status. It is also a necessary step towards https://reviews.llvm.org/D67891, and further developments for lldb_private::File. Reviewers: JDevlieghere, jasonmolenda, labath Reviewed By: labath Subscribers: mgorny, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D67996 llvm-svn: 373003
2019-09-27 01:54:59 +08:00
std::unique_ptr<Stream> output_stream_storage;
Stream *output_stream_p = nullptr;
<rdar://problem/14393032> DumpValueObject() 2.0 This checkin restores pre-Xcode5 functionality to the "po" (expr -O) command: - expr now has a new --description-verbosity (-v) argument, which takes either compact or full as a value (-v is the same as -vfull) When the full mode is on, "po" will show the extended output with type name, persistent variable name and value, as in (lldb) expr -O -v -- foo (id) $0 = 0x000000010010baf0 { 1 = 2; 2 = 3; } When -v is omitted, or -vcompact is passed, the Xcode5-style output will be shown, as in (lldb) expr -O -- foo { 1 = 2; 2 = 3; } - for a non-ObjectiveC object, LLDB will still try to retrieve a summary and/or value to display (lldb) po 5 5 -v also works in this mode (lldb) expr -O -vfull -- 5 (int) $4 = 5 On top of that, this is a major refactoring of the ValueObject printing code. The functionality is now factored into a ValueObjectPrinter class for easier maintenance in the future DumpValueObject() was turned into an instance method ValueObject::Dump() which simply calls through to the printer code, Dump_Impl has been removed Test case to follow llvm-svn: 191694
2013-10-01 03:11:51 +08:00
const FileSpec &outfile_spec =
m_outfile_options.GetFile().GetCurrentValue();
[FileSystem] Open File instances through the FileSystem. This patch modifies how we open File instances in LLDB. Rather than passing a path or FileSpec to the constructor, we now go through the virtual file system. This is needed in order to make things work with the VFS in the future. Differential revision: https://reviews.llvm.org/D54020 llvm-svn: 346049
2018-11-03 06:34:51 +08:00
std::string path = outfile_spec.GetPath();
Added a new OptionValue subclass for lldb::Format: OptionValueFormat. Added new OptionGroup subclasses for: - output file for use with options: long opts: --outfile <path> --append--output short opts: -o <path> -A - format for use with options: long opts: --format <format> - variable object display controls for depth, pointer depth, wether to show types, show summary, show location, flat output, use objc "po" style summary. Modified ValueObjectMemory to be able to be created either with a TypeSP or a ClangASTType. Switched "memory read" over to use OptionGroup subclasses: one for the outfile options, one for the command specific options, and one for the format. llvm-svn: 130334
2011-04-28 06:04:39 +08:00
if (outfile_spec) {
*** 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
[lldb] Fix bug where memory read --outfile is not truncating the file The memory read --outfile command should truncate the output when unless --append-outfile. Fix the bug and add a test. rdar://76062318 Differential revision: https://reviews.llvm.org/D99890
2021-04-06 23:39:03 +08:00
File::OpenOptions open_options =
[lldb] [gdb-remote] Add eOpenOptionReadWrite for future gdb compat Modify OpenOptions enum to open the future path into synchronizing vFile:open bits with GDB. Currently, LLDB and GDB use different flag models effectively making it impossible to match bits. Notably, LLDB uses two bits to indicate read and write status, and uses union of both for read/write. GDB uses a value of 0 for read-only, 1 for write-only and 2 for read/write. In order to future-proof the code for the GDB variant: 1. Add a distinct eOpenOptionReadWrite constant to be used instead of (eOpenOptionRead | eOpenOptionWrite) when R/W access is required. 2. Rename eOpenOptionRead and eOpenOptionWrite to eOpenOptionReadOnly and eOpenOptionWriteOnly respectively, to make it clear that they do not mean to be combined and require update to all call sites. 3. Use the intersection of all three flags when matching against the three possible values. This commit does not change the actual bits used by LLDB. Differential Revision: https://reviews.llvm.org/D106984
2021-07-29 02:07:03 +08:00
File::eOpenOptionWriteOnly | File::eOpenOptionCanCreate;
Added a new OptionValue subclass for lldb::Format: OptionValueFormat. Added new OptionGroup subclasses for: - output file for use with options: long opts: --outfile <path> --append--output short opts: -o <path> -A - format for use with options: long opts: --format <format> - variable object display controls for depth, pointer depth, wether to show types, show summary, show location, flat output, use objc "po" style summary. Modified ValueObjectMemory to be able to be created either with a TypeSP or a ClangASTType. Switched "memory read" over to use OptionGroup subclasses: one for the outfile options, one for the command specific options, and one for the format. llvm-svn: 130334
2011-04-28 06:04:39 +08:00
const bool append = m_outfile_options.GetAppend().GetCurrentValue();
[lldb] Fix bug where memory read --outfile is not truncating the file The memory read --outfile command should truncate the output when unless --append-outfile. Fix the bug and add a test. rdar://76062318 Differential revision: https://reviews.llvm.org/D99890
2021-04-06 23:39:03 +08:00
open_options |=
append ? File::eOpenOptionAppend : File::eOpenOptionTruncate;
*** 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
Convert FileSystem::Open() to return Expected<FileUP> Summary: This patch converts FileSystem::Open from this prototype: Status Open(File &File, const FileSpec &file_spec, ...); to this one: llvm::Expected<std::unique_ptr<File>> Open(const FileSpec &file_spec, ...); This is beneficial on its own, as llvm::Expected is a more modern and recommended error type than Status. It is also a necessary step towards https://reviews.llvm.org/D67891, and further developments for lldb_private::File. Reviewers: JDevlieghere, jasonmolenda, labath Reviewed By: labath Subscribers: mgorny, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D67996 llvm-svn: 373003
2019-09-27 01:54:59 +08:00
auto outfile = FileSystem::Instance().Open(outfile_spec, open_options);
if (outfile) {
auto outfile_stream_up =
std::make_unique<StreamFile>(std::move(outfile.get()));
Added a new OptionValue subclass for lldb::Format: OptionValueFormat. Added new OptionGroup subclasses for: - output file for use with options: long opts: --outfile <path> --append--output short opts: -o <path> -A - format for use with options: long opts: --format <format> - variable object display controls for depth, pointer depth, wether to show types, show summary, show location, flat output, use objc "po" style summary. Modified ValueObjectMemory to be able to be created either with a TypeSP or a ClangASTType. Switched "memory read" over to use OptionGroup subclasses: one for the outfile options, one for the command specific options, and one for the format. llvm-svn: 130334
2011-04-28 06:04:39 +08:00
if (m_memory_options.m_output_as_binary) {
Added new options to memory read to allow saving memory to disk as binary bytes or as an ASCII text dump. - The output file is specified with the "--outfile FILE" option. - The memory can be appended to an existing file using the "--append" option. - The memory will be written as an ASCII text dump by default, or as binary with the "--binary" option. Added new options to memory write to allow writing all or part of a file on disk to target memory: - The input file is specified using the "--infile FILE" option - The offset at which to start in the file defaults to zero, but can be overridden using the "--offset OFFSET" option. If the size is not specified, the remaining number of bytes in the file will be used as the default byte size. - The number of bytes to write defaults to the entire file byte size, but can be changed with the "--size COUNT" option. llvm-svn: 116172
2010-10-11 04:52:20 +08:00
const size_t bytes_written =
Convert FileSystem::Open() to return Expected<FileUP> Summary: This patch converts FileSystem::Open from this prototype: Status Open(File &File, const FileSpec &file_spec, ...); to this one: llvm::Expected<std::unique_ptr<File>> Open(const FileSpec &file_spec, ...); This is beneficial on its own, as llvm::Expected is a more modern and recommended error type than Status. It is also a necessary step towards https://reviews.llvm.org/D67891, and further developments for lldb_private::File. Reviewers: JDevlieghere, jasonmolenda, labath Reviewed By: labath Subscribers: mgorny, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D67996 llvm-svn: 373003
2019-09-27 01:54:59 +08:00
outfile_stream_up->Write(data_sp->GetBytes(), bytes_read);
Added new options to memory read to allow saving memory to disk as binary bytes or as an ASCII text dump. - The output file is specified with the "--outfile FILE" option. - The memory can be appended to an existing file using the "--append" option. - The memory will be written as an ASCII text dump by default, or as binary with the "--binary" option. Added new options to memory write to allow writing all or part of a file on disk to target memory: - The input file is specified using the "--infile FILE" option - The offset at which to start in the file defaults to zero, but can be overridden using the "--offset OFFSET" option. If the size is not specified, the remaining number of bytes in the file will be used as the default byte size. - The number of bytes to write defaults to the entire file byte size, but can be changed with the "--size COUNT" option. llvm-svn: 116172
2010-10-11 04:52:20 +08:00
if (bytes_written > 0) {
Added a new OptionValue subclass for lldb::Format: OptionValueFormat. Added new OptionGroup subclasses for: - output file for use with options: long opts: --outfile <path> --append--output short opts: -o <path> -A - format for use with options: long opts: --format <format> - variable object display controls for depth, pointer depth, wether to show types, show summary, show location, flat output, use objc "po" style summary. Modified ValueObjectMemory to be able to be created either with a TypeSP or a ClangASTType. Switched "memory read" over to use OptionGroup subclasses: one for the outfile options, one for the command specific options, and one for the format. llvm-svn: 130334
2011-04-28 06:04:39 +08:00
result.GetOutputStream().Printf(
"%zi bytes %s to '%s'\n", bytes_written,
[FileSystem] Open File instances through the FileSystem. This patch modifies how we open File instances in LLDB. Rather than passing a path or FileSpec to the constructor, we now go through the virtual file system. This is needed in order to make things work with the VFS in the future. Differential revision: https://reviews.llvm.org/D54020 llvm-svn: 346049
2018-11-03 06:34:51 +08:00
append ? "appended" : "written", path.c_str());
Added a new OptionValue subclass for lldb::Format: OptionValueFormat. Added new OptionGroup subclasses for: - output file for use with options: long opts: --outfile <path> --append--output short opts: -o <path> -A - format for use with options: long opts: --format <format> - variable object display controls for depth, pointer depth, wether to show types, show summary, show location, flat output, use objc "po" style summary. Modified ValueObjectMemory to be able to be created either with a TypeSP or a ClangASTType. Switched "memory read" over to use OptionGroup subclasses: one for the outfile options, one for the command specific options, and one for the format. llvm-svn: 130334
2011-04-28 06:04:39 +08:00
return true;
*** 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 {
Resolve printf formatting warnings on Linux: - use macros from inttypes.h for format strings instead of OS-specific types Patch from Matt Kopec! llvm-svn: 168945
2012-11-30 05:49:15 +08:00
result.AppendErrorWithFormat("Failed to write %" PRIu64
"size_t" isn't always 64 bit, it is 32 bit on 32 bit systems. All printf style statements that were assuming size_t were 64 bit were changed, and they were also changed to display them as unsigned values as "size_t" isn't signed. If you print anything with 'size_t', please cast it to "uint64_t" in the printf and use PRIu64 or PRIx64. llvm-svn: 202738
2014-03-04 03:15:20 +08:00
" bytes to '%s'.\n",
[FileSystem] Open File instances through the FileSystem. This patch modifies how we open File instances in LLDB. Rather than passing a path or FileSpec to the constructor, we now go through the virtual file system. This is needed in order to make things work with the VFS in the future. Differential revision: https://reviews.llvm.org/D54020 llvm-svn: 346049
2018-11-03 06:34:51 +08:00
(uint64_t)bytes_read, path.c_str());
<rdar://problem/12437929> Providing a special mode of operator for "memory read -f c-str" which actually works in most common cases Where the old behavior would provide: (lldb) mem read --format s `foo` 0x100000f5d: NULL Now we do: (lldb) mem read --format s `foo` 0x100000f5d: "hello world" You can also specify a count and that many strings will be showed starting at the initial address: (lldb) mem read -c 2 -f c-str `foo` 0x100000f1d: "hello world" 0x100000f29: "short" llvm-svn: 173076
2013-01-22 03:20:50 +08:00
return false;
*** 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 {
Added new options to memory read to allow saving memory to disk as binary bytes or as an ASCII text dump. - The output file is specified with the "--outfile FILE" option. - The memory can be appended to an existing file using the "--append" option. - The memory will be written as an ASCII text dump by default, or as binary with the "--binary" option. Added new options to memory write to allow writing all or part of a file on disk to target memory: - The input file is specified using the "--infile FILE" option - The offset at which to start in the file defaults to zero, but can be overridden using the "--offset OFFSET" option. If the size is not specified, the remaining number of bytes in the file will be used as the default byte size. - The number of bytes to write defaults to the entire file byte size, but can be changed with the "--size COUNT" option. llvm-svn: 116172
2010-10-11 04:52:20 +08:00
// We are going to write ASCII to the file just point the
// output_stream to our outfile_stream...
Convert FileSystem::Open() to return Expected<FileUP> Summary: This patch converts FileSystem::Open from this prototype: Status Open(File &File, const FileSpec &file_spec, ...); to this one: llvm::Expected<std::unique_ptr<File>> Open(const FileSpec &file_spec, ...); This is beneficial on its own, as llvm::Expected is a more modern and recommended error type than Status. It is also a necessary step towards https://reviews.llvm.org/D67891, and further developments for lldb_private::File. Reviewers: JDevlieghere, jasonmolenda, labath Reviewed By: labath Subscribers: mgorny, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D67996 llvm-svn: 373003
2019-09-27 01:54:59 +08:00
output_stream_storage = std::move(outfile_stream_up);
output_stream_p = output_stream_storage.get();
Added a new OptionValue subclass for lldb::Format: OptionValueFormat. Added new OptionGroup subclasses for: - output file for use with options: long opts: --outfile <path> --append--output short opts: -o <path> -A - format for use with options: long opts: --format <format> - variable object display controls for depth, pointer depth, wether to show types, show summary, show location, flat output, use objc "po" style summary. Modified ValueObjectMemory to be able to be created either with a TypeSP or a ClangASTType. Switched "memory read" over to use OptionGroup subclasses: one for the outfile options, one for the command specific options, and one for the format. llvm-svn: 130334
2011-04-28 06:04:39 +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
} else {
Convert FileSystem::Open() to return Expected<FileUP> Summary: This patch converts FileSystem::Open from this prototype: Status Open(File &File, const FileSpec &file_spec, ...); to this one: llvm::Expected<std::unique_ptr<File>> Open(const FileSpec &file_spec, ...); This is beneficial on its own, as llvm::Expected is a more modern and recommended error type than Status. It is also a necessary step towards https://reviews.llvm.org/D67891, and further developments for lldb_private::File. Reviewers: JDevlieghere, jasonmolenda, labath Reviewed By: labath Subscribers: mgorny, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D67996 llvm-svn: 373003
2019-09-27 01:54:59 +08:00
result.AppendErrorWithFormat("Failed to open file '%s' for %s:\n",
[FileSystem] Open File instances through the FileSystem. This patch modifies how we open File instances in LLDB. Rather than passing a path or FileSpec to the constructor, we now go through the virtual file system. This is needed in order to make things work with the VFS in the future. Differential revision: https://reviews.llvm.org/D54020 llvm-svn: 346049
2018-11-03 06:34:51 +08:00
path.c_str(), append ? "append" : "write");
Convert FileSystem::Open() to return Expected<FileUP> Summary: This patch converts FileSystem::Open from this prototype: Status Open(File &File, const FileSpec &file_spec, ...); to this one: llvm::Expected<std::unique_ptr<File>> Open(const FileSpec &file_spec, ...); This is beneficial on its own, as llvm::Expected is a more modern and recommended error type than Status. It is also a necessary step towards https://reviews.llvm.org/D67891, and further developments for lldb_private::File. Reviewers: JDevlieghere, jasonmolenda, labath Reviewed By: labath Subscribers: mgorny, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D67996 llvm-svn: 373003
2019-09-27 01:54:59 +08:00
result.AppendError(llvm::toString(outfile.takeError()));
<rdar://problem/12437929> Providing a special mode of operator for "memory read -f c-str" which actually works in most common cases Where the old behavior would provide: (lldb) mem read --format s `foo` 0x100000f5d: NULL Now we do: (lldb) mem read --format s `foo` 0x100000f5d: "hello world" You can also specify a count and that many strings will be showed starting at the initial address: (lldb) mem read -c 2 -f c-str `foo` 0x100000f1d: "hello world" 0x100000f29: "short" llvm-svn: 173076
2013-01-22 03:20:50 +08:00
return false;
*** 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 {
Convert FileSystem::Open() to return Expected<FileUP> Summary: This patch converts FileSystem::Open from this prototype: Status Open(File &File, const FileSpec &file_spec, ...); to this one: llvm::Expected<std::unique_ptr<File>> Open(const FileSpec &file_spec, ...); This is beneficial on its own, as llvm::Expected is a more modern and recommended error type than Status. It is also a necessary step towards https://reviews.llvm.org/D67891, and further developments for lldb_private::File. Reviewers: JDevlieghere, jasonmolenda, labath Reviewed By: labath Subscribers: mgorny, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D67996 llvm-svn: 373003
2019-09-27 01:54:59 +08:00
output_stream_p = &result.GetOutputStream();
*** 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 a new OptionValue subclass for lldb::Format: OptionValueFormat. Added new OptionGroup subclasses for: - output file for use with options: long opts: --outfile <path> --append--output short opts: -o <path> -A - format for use with options: long opts: --format <format> - variable object display controls for depth, pointer depth, wether to show types, show summary, show location, flat output, use objc "po" style summary. Modified ValueObjectMemory to be able to be created either with a TypeSP or a ClangASTType. Switched "memory read" over to use OptionGroup subclasses: one for the outfile options, one for the command specific options, and one for the format. llvm-svn: 130334
2011-04-28 06:04:39 +08:00
ExecutionContextScope *exe_scope = m_exe_ctx.GetBestExecutionContextScope();
[Expression] Add PersistentExpressionState::GetCompilerTypeFromPersistentDecl Summary: PersistentStateExpressions (e.g. ClangPersistentVariables) have the ability to define types using expressions that persist throughout the debugging session. GetCompilerTypeFromPersistentDecl is a useful operation to have if you need to use any of those persistently declared types, like in CommandObjectMemory. This decouples clang from CommandObjectMemory and decouples Plugins from Commands in general. Differential Revision: https://reviews.llvm.org/D62797 llvm-svn: 363183
2019-06-13 01:47:06 +08:00
if (compiler_type.GetOpaqueQualType()) {
Added a new OptionValue subclass for lldb::Format: OptionValueFormat. Added new OptionGroup subclasses for: - output file for use with options: long opts: --outfile <path> --append--output short opts: -o <path> -A - format for use with options: long opts: --format <format> - variable object display controls for depth, pointer depth, wether to show types, show summary, show location, flat output, use objc "po" style summary. Modified ValueObjectMemory to be able to be created either with a TypeSP or a ClangASTType. Switched "memory read" over to use OptionGroup subclasses: one for the outfile options, one for the command specific options, and one for the format. llvm-svn: 130334
2011-04-28 06:04:39 +08:00
for (uint32_t i = 0; i < item_count; ++i) {
<rdar://problem/14521548> Fixed a crasher where if you accidentally specify a size that is too large when reading memory, LLDB would crash. llvm-svn: 187060
2013-07-25 02:17:35 +08:00
addr_t item_addr = addr + (i * item_byte_size);
Added a new OptionValue subclass for lldb::Format: OptionValueFormat. Added new OptionGroup subclasses for: - output file for use with options: long opts: --outfile <path> --append--output short opts: -o <path> -A - format for use with options: long opts: --format <format> - variable object display controls for depth, pointer depth, wether to show types, show summary, show location, flat output, use objc "po" style summary. Modified ValueObjectMemory to be able to be created either with a TypeSP or a ClangASTType. Switched "memory read" over to use OptionGroup subclasses: one for the outfile options, one for the command specific options, and one for the format. llvm-svn: 130334
2011-04-28 06:04:39 +08:00
Address address(item_addr);
StreamString name_strm;
Converted the lldb_private::Process over to use the intrusive shared pointers. Changed the ExecutionContext over to use shared pointers for the target, process, thread and frame since these objects can easily go away at any time and any object that was holding onto an ExecutionContext was running the risk of using a bad object. Now that the shared pointers for target, process, thread and frame are just a single pointer (they all use the instrusive shared pointers) the execution context is much safer and still the same size. Made the shared pointers in the the ExecutionContext class protected and made accessors for all of the various ways to get at the pointers, references, and shared pointers. llvm-svn: 140298
2011-09-22 12:58:26 +08:00
name_strm.Printf("0x%" PRIx64, item_addr);
ValueObjectSP valobj_sp(ValueObjectMemory::Create(
[Expression] Add PersistentExpressionState::GetCompilerTypeFromPersistentDecl Summary: PersistentStateExpressions (e.g. ClangPersistentVariables) have the ability to define types using expressions that persist throughout the debugging session. GetCompilerTypeFromPersistentDecl is a useful operation to have if you need to use any of those persistently declared types, like in CommandObjectMemory. This decouples clang from CommandObjectMemory and decouples Plugins from Commands in general. Differential Revision: https://reviews.llvm.org/D62797 llvm-svn: 363183
2019-06-13 01:47:06 +08:00
exe_scope, name_strm.GetString(), address, compiler_type));
Added a new OptionValue subclass for lldb::Format: OptionValueFormat. Added new OptionGroup subclasses for: - output file for use with options: long opts: --outfile <path> --append--output short opts: -o <path> -A - format for use with options: long opts: --format <format> - variable object display controls for depth, pointer depth, wether to show types, show summary, show location, flat output, use objc "po" style summary. Modified ValueObjectMemory to be able to be created either with a TypeSP or a ClangASTType. Switched "memory read" over to use OptionGroup subclasses: one for the outfile options, one for the command specific options, and one for the format. llvm-svn: 130334
2011-04-28 06:04:39 +08:00
if (valobj_sp) {
<rdar://problem/13925432> A user request such as: memory read -fc -s10 -c1 *charPtrPtr would cause us to crash upon trying to read 1 char of size 10 from memory This request is now translated into: memory read -fc -s1 -c10 *charPtrPtr (i.e. read 10 chars of size 1 from memory) which is probably also what the user originally wanted llvm-svn: 182398
2013-05-22 01:39:04 +08:00
Format format = m_format_options.GetFormat();
if (format != eFormatDefault)
valobj_sp->SetFormat(format);
*** 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
Fix Clang-tidy modernize-use-nullptr and modernize-use-default warnings in some files in source/Commands; other minor fixes. llvm-svn: 261389
2016-02-20 08:58:29 +08:00
DumpValueObjectOptions options(m_varobj_options.GetAsDumpOptions(
"size_t" isn't always 64 bit, it is 32 bit on 32 bit systems. All printf style statements that were assuming size_t were 64 bit were changed, and they were also changed to display them as unsigned values as "size_t" isn't signed. If you print anything with 'size_t', please cast it to "uint64_t" in the printf and use PRIu64 or PRIx64. llvm-svn: 202738
2014-03-04 03:15:20 +08:00
eLanguageRuntimeDescriptionDisplayVerbosityFull, format));
*** 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
Convert FileSystem::Open() to return Expected<FileUP> Summary: This patch converts FileSystem::Open from this prototype: Status Open(File &File, const FileSpec &file_spec, ...); to this one: llvm::Expected<std::unique_ptr<File>> Open(const FileSpec &file_spec, ...); This is beneficial on its own, as llvm::Expected is a more modern and recommended error type than Status. It is also a necessary step towards https://reviews.llvm.org/D67891, and further developments for lldb_private::File. Reviewers: JDevlieghere, jasonmolenda, labath Reviewed By: labath Subscribers: mgorny, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D67996 llvm-svn: 373003
2019-09-27 01:54:59 +08:00
valobj_sp->Dump(*output_stream_p, options);
"size_t" isn't always 64 bit, it is 32 bit on 32 bit systems. All printf style statements that were assuming size_t were 64 bit were changed, and they were also changed to display them as unsigned values as "size_t" isn't signed. If you print anything with 'size_t', please cast it to "uint64_t" in the printf and use PRIu64 or PRIx64. llvm-svn: 202738
2014-03-04 03:15:20 +08:00
} else {
result.AppendErrorWithFormat(
"failed to create a value object for: (%s) %s\n",
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
view_as_type_cstr, name_strm.GetData());
<rdar://problem/15296388> Fix a crasher that would occur if one tried to read memory as characters of some size != 1, e.g. x -f c -s 10 buffer This commit tries to do the right thing and uses the byte-size as the number of elements, unless both are specified and the number of elements is != 1 In this latter case (e.g. x -f c -s 10 -c 3 buffer) one could multiply the two and read 30 characters, but it seems a stretch in mind reading. llvm-svn: 193659
2013-10-30 07:04:29 +08:00
return false;
<rdar://problem/13925432> A user request such as: memory read -fc -s10 -c1 *charPtrPtr would cause us to crash upon trying to read 1 char of size 10 from memory This request is now translated into: memory read -fc -s1 -c10 *charPtrPtr (i.e. read 10 chars of size 1 from memory) which is probably also what the user originally wanted llvm-svn: 182398
2013-05-22 01:39:04 +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
}
Added new options to memory read to allow saving memory to disk as binary bytes or as an ASCII text dump. - The output file is specified with the "--outfile FILE" option. - The memory can be appended to an existing file using the "--append" option. - The memory will be written as an ASCII text dump by default, or as binary with the "--binary" option. Added new options to memory write to allow writing all or part of a file on disk to target memory: - The input file is specified using the "--infile FILE" option - The offset at which to start in the file defaults to zero, but can be overridden using the "--offset OFFSET" option. If the size is not specified, the remaining number of bytes in the file will be used as the default byte size. - The number of bytes to write defaults to the entire file byte size, but can be changed with the "--size COUNT" option. llvm-svn: 116172
2010-10-11 04:52:20 +08:00
return true;
*** 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 a new OptionValue subclass for lldb::Format: OptionValueFormat. Added new OptionGroup subclasses for: - output file for use with options: long opts: --outfile <path> --append--output short opts: -o <path> -A - format for use with options: long opts: --format <format> - variable object display controls for depth, pointer depth, wether to show types, show summary, show location, flat output, use objc "po" style summary. Modified ValueObjectMemory to be able to be created either with a TypeSP or a ClangASTType. Switched "memory read" over to use OptionGroup subclasses: one for the outfile options, one for the command specific options, and one for the format. llvm-svn: 130334
2011-04-28 06:04:39 +08:00
Added new options to memory read to allow saving memory to disk as binary bytes or as an ASCII text dump. - The output file is specified with the "--outfile FILE" option. - The memory can be appended to an existing file using the "--append" option. - The memory will be written as an ASCII text dump by default, or as binary with the "--binary" option. Added new options to memory write to allow writing all or part of a file on disk to target memory: - The input file is specified using the "--infile FILE" option - The offset at which to start in the file defaults to zero, but can be overridden using the "--offset OFFSET" option. If the size is not specified, the remaining number of bytes in the file will be used as the default byte size. - The number of bytes to write defaults to the entire file byte size, but can be changed with the "--size COUNT" option. llvm-svn: 116172
2010-10-11 04:52:20 +08:00
result.SetStatus(eReturnStatusSuccessFinishResult);
<rdar://problem/13069948> Major fixed to allow reading files that are over 4GB. The main problems were that the DataExtractor was using 32 bit offsets as a data cursor, and since we mmap all of our object files we could run into cases where if we had a very large core file that was over 4GB, we were running into the 4GB boundary. So I defined a new "lldb::offset_t" which should be used for all file offsets. After making this change, I enabled warnings for data loss and for enexpected implicit conversions temporarily and found a ton of things that I fixed. Any functions that take an index internally, should use "size_t" for any indexes and also should return "size_t" for any sizes of collections. llvm-svn: 173463
2013-01-26 02:06:21 +08:00
DataExtractor data(data_sp, target->GetArchitecture().GetByteOrder(),
target->GetArchitecture().GetAddressByteSize(),
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
target->GetArchitecture().GetDataByteSize());
*** 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
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
Format format = m_format_options.GetFormat();
if (((format == eFormatChar) || (format == eFormatCharPrintable)) &&
<rdar://problem/15296388> Fix a crasher that would occur if one tried to read memory as characters of some size != 1, e.g. x -f c -s 10 buffer This commit tries to do the right thing and uses the byte-size as the number of elements, unless both are specified and the number of elements is != 1 In this latter case (e.g. x -f c -s 10 -c 3 buffer) one could multiply the two and read 30 characters, but it seems a stretch in mind reading. llvm-svn: 193659
2013-10-30 07:04:29 +08:00
(item_byte_size != 1)) {
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
// if a count was not passed, or it is 1
<rdar://problem/12437929> Providing a special mode of operator for "memory read -f c-str" which actually works in most common cases Where the old behavior would provide: (lldb) mem read --format s `foo` 0x100000f5d: NULL Now we do: (lldb) mem read --format s `foo` 0x100000f5d: "hello world" You can also specify a count and that many strings will be showed starting at the initial address: (lldb) mem read -c 2 -f c-str `foo` 0x100000f1d: "hello world" 0x100000f29: "short" llvm-svn: 173076
2013-01-22 03:20:50 +08:00
if (!m_format_options.GetCountValue().OptionWasSet() || item_count == 1) {
<rdar://problem/15296388> Fix a crasher that would occur if one tried to read memory as characters of some size != 1, e.g. x -f c -s 10 buffer This commit tries to do the right thing and uses the byte-size as the number of elements, unless both are specified and the number of elements is != 1 In this latter case (e.g. x -f c -s 10 -c 3 buffer) one could multiply the two and read 30 characters, but it seems a stretch in mind reading. llvm-svn: 193659
2013-10-30 07:04:29 +08:00
// this turns requests such as
// memory read -fc -s10 -c1 *charPtrPtr
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
// which make no sense (what is a char of size 10?) into a request for
// fetching 10 chars of size 1 from the same memory location
<rdar://problem/13069948> Major fixed to allow reading files that are over 4GB. The main problems were that the DataExtractor was using 32 bit offsets as a data cursor, and since we mmap all of our object files we could run into cases where if we had a very large core file that was over 4GB, we were running into the 4GB boundary. So I defined a new "lldb::offset_t" which should be used for all file offsets. After making this change, I enabled warnings for data loss and for enexpected implicit conversions temporarily and found a ton of things that I fixed. Any functions that take an index internally, should use "size_t" for any indexes and also should return "size_t" for any sizes of collections. llvm-svn: 173463
2013-01-26 02:06:21 +08:00
format = eFormatCharArray;
item_count = item_byte_size;
Fixed the continuation dumping of instructions to properly advance the previous address only by the number of bytes consumed by the disassembly: (lldb) x/4i 0x0000000100000ea9 0x100000ea9: 66 c7 45 fa 10 00 movw $16, -6(%rbp) 0x100000eaf: c7 45 f4 20 00 00 00 movl $32, -12(%rbp) 0x100000eb6: e8 47 00 00 00 callq 0x0000000100000f02 ; void f<nullptr_t>(nullptr_t) 0x100000ebb: 8b 45 fc movl -4(%rbp), %eax (lldb) 0x100000ebe: 48 83 c4 10 addq $16, %rsp 0x100000ec2: 5d popq %rbp 0x100000ec3: c3 ret 0x100000ec4: 90 nop (lldb) 0x100000ec5: 90 nop 0x100000ec6: 90 nop 0x100000ec7: 90 nop 0x100000ec8: 90 nop (lldb) 0x100000ec9: 90 nop 0x100000eca: 90 nop 0x100000ecb: 90 nop 0x100000ecc: 90 nop (lldb) 0x100000ecd: 90 nop 0x100000ece: 90 nop 0x100000ecf: 90 nop 0x100000ed0: 55 pushq %rbp llvm-svn: 143254
2011-10-29 07:44:55 +08:00
item_byte_size = 1;
*** 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
// here we passed a count, and it was not 1 so we have a byte_size and
// a count we could well multiply those, but instead let's just fail
Fixed the continuation dumping of instructions to properly advance the previous address only by the number of bytes consumed by the disassembly: (lldb) x/4i 0x0000000100000ea9 0x100000ea9: 66 c7 45 fa 10 00 movw $16, -6(%rbp) 0x100000eaf: c7 45 f4 20 00 00 00 movl $32, -12(%rbp) 0x100000eb6: e8 47 00 00 00 callq 0x0000000100000f02 ; void f<nullptr_t>(nullptr_t) 0x100000ebb: 8b 45 fc movl -4(%rbp), %eax (lldb) 0x100000ebe: 48 83 c4 10 addq $16, %rsp 0x100000ec2: 5d popq %rbp 0x100000ec3: c3 ret 0x100000ec4: 90 nop (lldb) 0x100000ec5: 90 nop 0x100000ec6: 90 nop 0x100000ec7: 90 nop 0x100000ec8: 90 nop (lldb) 0x100000ec9: 90 nop 0x100000eca: 90 nop 0x100000ecb: 90 nop 0x100000ecc: 90 nop (lldb) 0x100000ecd: 90 nop 0x100000ece: 90 nop 0x100000ecf: 90 nop 0x100000ed0: 55 pushq %rbp llvm-svn: 143254
2011-10-29 07:44:55 +08:00
result.AppendErrorWithFormat(
"reading memory as characters of size %" PRIu64 " is not supported",
Added new options to memory read to allow saving memory to disk as binary bytes or as an ASCII text dump. - The output file is specified with the "--outfile FILE" option. - The memory can be appended to an existing file using the "--append" option. - The memory will be written as an ASCII text dump by default, or as binary with the "--binary" option. Added new options to memory write to allow writing all or part of a file on disk to target memory: - The input file is specified using the "--infile FILE" option - The offset at which to start in the file defaults to zero, but can be overridden using the "--offset OFFSET" option. If the size is not specified, the remaining number of bytes in the file will be used as the default byte size. - The number of bytes to write defaults to the entire file byte size, but can be changed with the "--size COUNT" option. llvm-svn: 116172
2010-10-11 04:52:20 +08:00
(uint64_t)item_byte_size);
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
return false;
*** 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
}
Convert FileSystem::Open() to return Expected<FileUP> Summary: This patch converts FileSystem::Open from this prototype: Status Open(File &File, const FileSpec &file_spec, ...); to this one: llvm::Expected<std::unique_ptr<File>> Open(const FileSpec &file_spec, ...); This is beneficial on its own, as llvm::Expected is a more modern and recommended error type than Status. It is also a necessary step towards https://reviews.llvm.org/D67891, and further developments for lldb_private::File. Reviewers: JDevlieghere, jasonmolenda, labath Reviewed By: labath Subscribers: mgorny, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D67996 llvm-svn: 373003
2019-09-27 01:54:59 +08:00
assert(output_stream_p);
Isolate Target-specific functionality of DataExtractor. In an effort to move the various DataBuffer / DataExtractor classes from Core -> Utility, we have to separate the low-level functionality from the higher level functionality. Only a few functions required anything other than reading/writing raw bytes, so those functions are separated out into a more appropriate area. Specifically, Dump() and DumpHexBytes() are moved into free functions in Core/DumpDataExtractor.cpp, and GetGNUEHPointer is moved into a static function in the only file that it's referenced from. Differential Revision: https://reviews.llvm.org/D30560 llvm-svn: 296910
2017-03-04 04:57:05 +08:00
size_t bytes_dumped = DumpDataExtractor(
Convert FileSystem::Open() to return Expected<FileUP> Summary: This patch converts FileSystem::Open from this prototype: Status Open(File &File, const FileSpec &file_spec, ...); to this one: llvm::Expected<std::unique_ptr<File>> Open(const FileSpec &file_spec, ...); This is beneficial on its own, as llvm::Expected is a more modern and recommended error type than Status. It is also a necessary step towards https://reviews.llvm.org/D67891, and further developments for lldb_private::File. Reviewers: JDevlieghere, jasonmolenda, labath Reviewed By: labath Subscribers: mgorny, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D67996 llvm-svn: 373003
2019-09-27 01:54:59 +08:00
data, output_stream_p, 0, format, item_byte_size, item_count,
Isolate Target-specific functionality of DataExtractor. In an effort to move the various DataBuffer / DataExtractor classes from Core -> Utility, we have to separate the low-level functionality from the higher level functionality. Only a few functions required anything other than reading/writing raw bytes, so those functions are separated out into a more appropriate area. Specifically, Dump() and DumpHexBytes() are moved into free functions in Core/DumpDataExtractor.cpp, and GetGNUEHPointer is moved into a static function in the only file that it's referenced from. Differential Revision: https://reviews.llvm.org/D30560 llvm-svn: 296910
2017-03-04 04:57:05 +08:00
num_per_line / target->GetArchitecture().GetDataByteSize(), addr, 0, 0,
[lldb] Change implementation of memory read --show-tags option This does 2 things: * Moves it after the short options. Which makes sense given it's a niche, default off option. (if 2 files for one option seems a bit much, I am going to reuse them for "memory find" later) * Fixes the use of repeated commands. For example: memory read buf --show-tags <shows tags> memory read <shows tags> Added tests for the repetition and updated existing help tests. Reviewed By: omjavaid Differential Revision: https://reviews.llvm.org/D125089
2022-04-14 18:56:44 +08:00
exe_scope, m_memory_tag_options.GetShowTags().GetCurrentValue());
Add a --offset option to memory read that allows one to specify, given a type, how many sizeof(type) bytes to speak before starting to read memory llvm-svn: 251668
2015-10-30 07:40:24 +08:00
m_next_addr = addr + bytes_dumped;
Convert FileSystem::Open() to return Expected<FileUP> Summary: This patch converts FileSystem::Open from this prototype: Status Open(File &File, const FileSpec &file_spec, ...); to this one: llvm::Expected<std::unique_ptr<File>> Open(const FileSpec &file_spec, ...); This is beneficial on its own, as llvm::Expected is a more modern and recommended error type than Status. It is also a necessary step towards https://reviews.llvm.org/D67891, and further developments for lldb_private::File. Reviewers: JDevlieghere, jasonmolenda, labath Reviewed By: labath Subscribers: mgorny, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D67996 llvm-svn: 373003
2019-09-27 01:54:59 +08:00
output_stream_p->EOL();
Added a new OptionValue subclass for lldb::Format: OptionValueFormat. Added new OptionGroup subclasses for: - output file for use with options: long opts: --outfile <path> --append--output short opts: -o <path> -A - format for use with options: long opts: --format <format> - variable object display controls for depth, pointer depth, wether to show types, show summary, show location, flat output, use objc "po" style summary. Modified ValueObjectMemory to be able to be created either with a TypeSP or a ClangASTType. Switched "memory read" over to use OptionGroup subclasses: one for the outfile options, one for the command specific options, and one for the format. llvm-svn: 130334
2011-04-28 06:04:39 +08:00
return true;
*** 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 a new OptionValue subclass for lldb::Format: OptionValueFormat. Added new OptionGroup subclasses for: - output file for use with options: long opts: --outfile <path> --append--output short opts: -o <path> -A - format for use with options: long opts: --format <format> - variable object display controls for depth, pointer depth, wether to show types, show summary, show location, flat output, use objc "po" style summary. Modified ValueObjectMemory to be able to be created either with a TypeSP or a ClangASTType. Switched "memory read" over to use OptionGroup subclasses: one for the outfile options, one for the command specific options, and one for the format. llvm-svn: 130334
2011-04-28 06:04:39 +08:00
OptionGroupOptions m_option_group;
OptionGroupFormat m_format_options;
OptionGroupReadMemory m_memory_options;
OptionGroupOutputFile m_outfile_options;
Added the ability to specify dumping options (show types, show location, depth control, pointer depth, and more) when dumping memory and viewing as a type. llvm-svn: 130436
2011-04-29 04:55:26 +08:00
OptionGroupValueObjectDisplay m_varobj_options;
[lldb] Change implementation of memory read --show-tags option This does 2 things: * Moves it after the short options. Which makes sense given it's a niche, default off option. (if 2 files for one option seems a bit much, I am going to reuse them for "memory find" later) * Fixes the use of repeated commands. For example: memory read buf --show-tags <shows tags> memory read <shows tags> Added tests for the repetition and updated existing help tests. Reviewed By: omjavaid Differential Revision: https://reviews.llvm.org/D125089
2022-04-14 18:56:44 +08:00
OptionGroupMemoryTag m_memory_tag_options;
[LLDB] Applying clang-tidy modernize-use-default-member-init over LLDB Applied modernize-use-default-member-init clang-tidy check over LLDB. It appears in many files we had already switched to in class member init but never updated the constructors to reflect that. This check is already present in the lldb/.clang-tidy config. Differential Revision: https://reviews.llvm.org/D121481
2022-03-15 04:32:03 +08:00
lldb::addr_t m_next_addr = LLDB_INVALID_ADDRESS;
lldb::addr_t m_prev_byte_size = 0;
A simple fix for the GDB format strings so the byte size parameter gets properly marked as valid. Also modified the "memory read" command to be able to intelligently repeat subsequent memory requests, so now you can do: (lldb) memory read --format hex --count 32 0x1000 Then hit enter to keep viewing the memory that follows the last valid request. llvm-svn: 143015
2011-10-26 12:32:38 +08:00
OptionGroupFormat m_prev_format_options;
OptionGroupReadMemory m_prev_memory_options;
OptionGroupOutputFile m_prev_outfile_options;
OptionGroupValueObjectDisplay m_prev_varobj_options;
[lldb] Change implementation of memory read --show-tags option This does 2 things: * Moves it after the short options. Which makes sense given it's a niche, default off option. (if 2 files for one option seems a bit much, I am going to reuse them for "memory find" later) * Fixes the use of repeated commands. For example: memory read buf --show-tags <shows tags> memory read <shows tags> Added tests for the repetition and updated existing help tests. Reviewed By: omjavaid Differential Revision: https://reviews.llvm.org/D125089
2022-04-14 18:56:44 +08:00
OptionGroupMemoryTag m_prev_memory_tag_options;
[Expression] Add PersistentExpressionState::GetCompilerTypeFromPersistentDecl Summary: PersistentStateExpressions (e.g. ClangPersistentVariables) have the ability to define types using expressions that persist throughout the debugging session. GetCompilerTypeFromPersistentDecl is a useful operation to have if you need to use any of those persistently declared types, like in CommandObjectMemory. This decouples clang from CommandObjectMemory and decouples Plugins from Commands in general. Differential Revision: https://reviews.llvm.org/D62797 llvm-svn: 363183
2019-06-13 01:47:06 +08:00
CompilerType m_prev_compiler_type;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
};
[lldb] Tablegenify expr/frame/log/register/memory llvm-svn: 367009
2019-07-25 19:22:46 +08:00
#define LLDB_OPTIONS_memory_find
#include "CommandOptions.inc"
<rdar://problem/14322677> Implement a "memory find" command for LLDB This is still fairly rough around the edges but works well enough for simple scenarios where a chunk of text or a number are to be found within a certain range of memory, as in mem find `buffer` `buffer+0x1000` -s "me" -c 5 -r llvm-svn: 194544
2013-11-13 10:18:44 +08:00
// Find the specified data in memory
class CommandObjectMemoryFind : public CommandObjectParsed {
public:
class OptionGroupFindMemory : public OptionGroup {
public:
[Commands] Remove redundant member initialization (NFC) Identified with readability-redundant-member-init.
2022-01-24 03:07:14 +08:00
OptionGroupFindMemory() : m_count(1), m_offset(0) {}
Fix Clang-tidy modernize-use-nullptr and modernize-use-default warnings in some files in source/Commands; other minor fixes. llvm-svn: 261389
2016-02-20 08:58:29 +08:00
~OptionGroupFindMemory() override = default;
Convert option tables to ArrayRefs. This change is very mechanical. All it does is change the signature of `Options::GetDefinitions()` and `OptionGroup:: GetDefinitions()` to return an `ArrayRef<OptionDefinition>` instead of a `const OptionDefinition *`. In the case of the former, it deletes the sentinel entry from every table, and in the case of the latter, it removes the `GetNumDefinitions()` method from the interface. These are no longer necessary as `ArrayRef` carries its own length. In the former case, iteration was done by using a sentinel entry, so there was no knowledge of length. Because of this the individual option tables were allowed to be defined below the corresponding class (after all, only a pointer was needed). Now, however, the length must be known at compile time to construct the `ArrayRef`, and as a result it is necessary to move every option table before its corresponding class. This results in this CL looking very big, but in terms of substance there is not much here. Differential revision: https://reviews.llvm.org/D24834 llvm-svn: 282188
2016-09-23 04:22:55 +08:00
llvm::ArrayRef<OptionDefinition> GetDefinitions() override {
[lldb] Also include the array definition in CommandOptions.inc Summary: Right now our CommandOptions.inc only generates the initializer for the options list but not the array declaration boilerplate around it. As the array definition is identical for all arrays, we might as well also let the CommandOptions.inc generate it alongside the initializers. This patch will also allow us to generate additional declarations related to that option list in the future (e.g. a enum class representing the specific options which would make our handling code less prone). This patch also fixes a few option tables that didn't follow our naming style. Reviewers: JDevlieghere Reviewed By: JDevlieghere Subscribers: abidh, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D65331 llvm-svn: 367186
2019-07-28 14:24:07 +08:00
return llvm::makeArrayRef(g_memory_find_options);
<rdar://problem/14322677> Implement a "memory find" command for LLDB This is still fairly rough around the edges but works well enough for simple scenarios where a chunk of text or a number are to be found within a certain range of memory, as in mem find `buffer` `buffer+0x1000` -s "me" -c 5 -r llvm-svn: 194544
2013-11-13 10:18:44 +08:00
}
Minor improvement to the "memory find" command Remove the --do-read option, and always provide a small dump of memory at each match spot Add a --dump-offset (-o) option, to specify a byte offset from which to start dumping relative to the matching address The real solution is to actually provide the format options found on "memory read" and use those as the key to actually printing memory upon each find That, however, requires a little refactoring work, so put this in for now until I get a chance to do the required shuffling around of moving parts llvm-svn: 194600
2013-11-14 04:08:30 +08:00
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 SetOptionValue(uint32_t option_idx, llvm::StringRef option_value,
ExecutionContext *execution_context) override {
Status error;
[lldb] Also include the array definition in CommandOptions.inc Summary: Right now our CommandOptions.inc only generates the initializer for the options list but not the array declaration boilerplate around it. As the array definition is identical for all arrays, we might as well also let the CommandOptions.inc generate it alongside the initializers. This patch will also allow us to generate additional declarations related to that option list in the future (e.g. a enum class representing the specific options which would make our handling code less prone). This patch also fixes a few option tables that didn't follow our naming style. Reviewers: JDevlieghere Reviewed By: JDevlieghere Subscribers: abidh, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D65331 llvm-svn: 367186
2019-07-28 14:24:07 +08:00
const int short_option = g_memory_find_options[option_idx].short_option;
*** 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/14322677> Implement a "memory find" command for LLDB This is still fairly rough around the edges but works well enough for simple scenarios where a chunk of text or a number are to be found within a certain range of memory, as in mem find `buffer` `buffer+0x1000` -s "me" -c 5 -r llvm-svn: 194544
2013-11-13 10:18:44 +08:00
switch (short_option) {
case 'e':
Update OptionGroup::SetValue to take StringRef. Then deal with all the fallout. Differential Revision: https://reviews.llvm.org/D24847 llvm-svn: 282265
2016-09-24 01:48:13 +08:00
m_expr.SetValueFromString(option_value);
*** 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
break;
<rdar://problem/14322677> Implement a "memory find" command for LLDB This is still fairly rough around the edges but works well enough for simple scenarios where a chunk of text or a number are to be found within a certain range of memory, as in mem find `buffer` `buffer+0x1000` -s "me" -c 5 -r llvm-svn: 194544
2013-11-13 10:18:44 +08:00
case 's':
Update OptionGroup::SetValue to take StringRef. Then deal with all the fallout. Differential Revision: https://reviews.llvm.org/D24847 llvm-svn: 282265
2016-09-24 01:48:13 +08:00
m_string.SetValueFromString(option_value);
*** 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
break;
<rdar://problem/14322677> Implement a "memory find" command for LLDB This is still fairly rough around the edges but works well enough for simple scenarios where a chunk of text or a number are to be found within a certain range of memory, as in mem find `buffer` `buffer+0x1000` -s "me" -c 5 -r llvm-svn: 194544
2013-11-13 10:18:44 +08:00
case 'c':
Update OptionGroup::SetValue to take StringRef. Then deal with all the fallout. Differential Revision: https://reviews.llvm.org/D24847 llvm-svn: 282265
2016-09-24 01:48:13 +08:00
if (m_count.SetValueFromString(option_value).Fail())
<rdar://problem/14322677> Implement a "memory find" command for LLDB This is still fairly rough around the edges but works well enough for simple scenarios where a chunk of text or a number are to be found within a certain range of memory, as in mem find `buffer` `buffer+0x1000` -s "me" -c 5 -r llvm-svn: 194544
2013-11-13 10:18:44 +08:00
error.SetErrorString("unrecognized value for 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
break;
Minor improvement to the "memory find" command Remove the --do-read option, and always provide a small dump of memory at each match spot Add a --dump-offset (-o) option, to specify a byte offset from which to start dumping relative to the matching address The real solution is to actually provide the format options found on "memory read" and use those as the key to actually printing memory upon each find That, however, requires a little refactoring work, so put this in for now until I get a chance to do the required shuffling around of moving parts llvm-svn: 194600
2013-11-14 04:08:30 +08:00
case 'o':
Update OptionGroup::SetValue to take StringRef. Then deal with all the fallout. Differential Revision: https://reviews.llvm.org/D24847 llvm-svn: 282265
2016-09-24 01:48:13 +08:00
if (m_offset.SetValueFromString(option_value).Fail())
Minor improvement to the "memory find" command Remove the --do-read option, and always provide a small dump of memory at each match spot Add a --dump-offset (-o) option, to specify a byte offset from which to start dumping relative to the matching address The real solution is to actually provide the format options found on "memory read" and use those as the key to actually printing memory upon each find That, however, requires a little refactoring work, so put this in for now until I get a chance to do the required shuffling around of moving parts llvm-svn: 194600
2013-11-14 04:08:30 +08:00
error.SetErrorString("unrecognized value for dump-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
break;
default:
[lldb][NFC] Remove dead code that is supposed to handle invalid command options Summary: We currently have a bunch of code that is supposed to handle invalid command options, but all this code is unreachable because invalid options are already handled in `Options::Parse`. The only way we can reach this code is when we declare but then not implement an option (which will be made impossible with D65386, which is also when we can completely remove the `default` cases). This patch replaces all this code with `llvm_unreachable` to make clear this is dead code that can't be reached. Reviewers: JDevlieghere Reviewed By: JDevlieghere Subscribers: lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D66522 llvm-svn: 369625
2019-08-22 16:08:05 +08:00
llvm_unreachable("Unimplemented option");
<rdar://problem/14322677> Implement a "memory find" command for LLDB This is still fairly rough around the edges but works well enough for simple scenarios where a chunk of text or a number are to be found within a certain range of memory, as in mem find `buffer` `buffer+0x1000` -s "me" -c 5 -r llvm-svn: 194544
2013-11-13 10:18:44 +08:00
}
return error;
}
*** 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
Decoupled Options from CommandInterpreter. Options used to store a reference to the CommandInterpreter instance in the base Options class. This made it impossible to parse options independent of a CommandInterpreter. This change removes the reference from the base class. Instead, it modifies the options-parsing-related methods to take an ExecutionContext pointer, which the options may inspect if they need to do so. Closes https://reviews.llvm.org/D23416 Reviewers: clayborg, jingham llvm-svn: 278440
2016-08-12 07:51:28 +08:00
void OptionParsingStarting(ExecutionContext *execution_context) override {
<rdar://problem/14322677> Implement a "memory find" command for LLDB This is still fairly rough around the edges but works well enough for simple scenarios where a chunk of text or a number are to be found within a certain range of memory, as in mem find `buffer` `buffer+0x1000` -s "me" -c 5 -r llvm-svn: 194544
2013-11-13 10:18:44 +08:00
m_expr.Clear();
m_string.Clear();
m_count.Clear();
}
*** 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/14322677> Implement a "memory find" command for LLDB This is still fairly rough around the edges but works well enough for simple scenarios where a chunk of text or a number are to be found within a certain range of memory, as in mem find `buffer` `buffer+0x1000` -s "me" -c 5 -r llvm-svn: 194544
2013-11-13 10:18:44 +08:00
OptionValueString m_expr;
OptionValueString m_string;
OptionValueUInt64 m_count;
Minor improvement to the "memory find" command Remove the --do-read option, and always provide a small dump of memory at each match spot Add a --dump-offset (-o) option, to specify a byte offset from which to start dumping relative to the matching address The real solution is to actually provide the format options found on "memory read" and use those as the key to actually printing memory upon each find That, however, requires a little refactoring work, so put this in for now until I get a chance to do the required shuffling around of moving parts llvm-svn: 194600
2013-11-14 04:08:30 +08:00
OptionValueUInt64 m_offset;
<rdar://problem/14322677> Implement a "memory find" command for LLDB This is still fairly rough around the edges but works well enough for simple scenarios where a chunk of text or a number are to be found within a certain range of memory, as in mem find `buffer` `buffer+0x1000` -s "me" -c 5 -r llvm-svn: 194544
2013-11-13 10:18:44 +08:00
};
LLDB help content has accumulated over time without a recent attempt to review it for consistency, accuracy, and clarity. These changes attempt to address all of the above while keeping the text relatively terse. <rdar://problem/24868841> llvm-svn: 275485
2016-07-15 06:03:10 +08:00
CommandObjectMemoryFind(CommandInterpreter &interpreter)
: CommandObjectParsed(
interpreter, "memory find",
"Find a value in the memory of the current target process.",
[Commands] Remove redundant member initialization (NFC) Identified with readability-redundant-member-init.
2022-01-24 03:07:14 +08:00
nullptr, eCommandRequiresProcess | eCommandProcessMustBeLaunched) {
<rdar://problem/14322677> Implement a "memory find" command for LLDB This is still fairly rough around the edges but works well enough for simple scenarios where a chunk of text or a number are to be found within a certain range of memory, as in mem find `buffer` `buffer+0x1000` -s "me" -c 5 -r llvm-svn: 194544
2013-11-13 10:18:44 +08:00
CommandArgumentEntry arg1;
CommandArgumentEntry arg2;
CommandArgumentData addr_arg;
CommandArgumentData value_arg;
*** 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/14322677> Implement a "memory find" command for LLDB This is still fairly rough around the edges but works well enough for simple scenarios where a chunk of text or a number are to be found within a certain range of memory, as in mem find `buffer` `buffer+0x1000` -s "me" -c 5 -r llvm-svn: 194544
2013-11-13 10:18:44 +08:00
// Define the first (and only) variant of this arg.
Jim suggested to use eArgTypeAddressOrExpression for the addresses that 'memory find' takes llvm-svn: 243902
2015-08-04 04:47:19 +08:00
addr_arg.arg_type = eArgTypeAddressOrExpression;
<rdar://problem/14322677> Implement a "memory find" command for LLDB This is still fairly rough around the edges but works well enough for simple scenarios where a chunk of text or a number are to be found within a certain range of memory, as in mem find `buffer` `buffer+0x1000` -s "me" -c 5 -r llvm-svn: 194544
2013-11-13 10:18:44 +08:00
addr_arg.arg_repetition = eArgRepeatPlain;
*** 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/14322677> Implement a "memory find" command for LLDB This is still fairly rough around the edges but works well enough for simple scenarios where a chunk of text or a number are to be found within a certain range of memory, as in mem find `buffer` `buffer+0x1000` -s "me" -c 5 -r llvm-svn: 194544
2013-11-13 10:18:44 +08:00
// There is only one variant this argument could be; put it into the
// argument entry.
arg1.push_back(addr_arg);
*** 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/14322677> Implement a "memory find" command for LLDB This is still fairly rough around the edges but works well enough for simple scenarios where a chunk of text or a number are to be found within a certain range of memory, as in mem find `buffer` `buffer+0x1000` -s "me" -c 5 -r llvm-svn: 194544
2013-11-13 10:18:44 +08:00
// Define the first (and only) variant of this arg.
Jim suggested to use eArgTypeAddressOrExpression for the addresses that 'memory find' takes llvm-svn: 243902
2015-08-04 04:47:19 +08:00
value_arg.arg_type = eArgTypeAddressOrExpression;
value_arg.arg_repetition = eArgRepeatPlain;
*** 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/14322677> Implement a "memory find" command for LLDB This is still fairly rough around the edges but works well enough for simple scenarios where a chunk of text or a number are to be found within a certain range of memory, as in mem find `buffer` `buffer+0x1000` -s "me" -c 5 -r llvm-svn: 194544
2013-11-13 10:18:44 +08:00
// There is only one variant this argument could be; put it into the
// argument entry.
arg2.push_back(value_arg);
*** 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/14322677> Implement a "memory find" command for LLDB This is still fairly rough around the edges but works well enough for simple scenarios where a chunk of text or a number are to be found within a certain range of memory, as in mem find `buffer` `buffer+0x1000` -s "me" -c 5 -r llvm-svn: 194544
2013-11-13 10:18:44 +08:00
// Push the data for the first argument into the m_arguments vector.
m_arguments.push_back(arg1);
m_arguments.push_back(arg2);
*** 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 the arguments for 'memory find' such that the help system reflects the real way to invoke it llvm-svn: 266129
2016-04-13 05:26:48 +08:00
m_option_group.Append(&m_memory_options);
[lldb] Add --show-tags option to "memory find" This is off by default. If you get a result and that memory has memory tags, when --show-tags is given you'll see the tags inline with the memory content. ``` (lldb) memory read mte_buf mte_buf+64 --show-tags <...> 0xfffff7ff8020: 00 00 00 00 00 00 00 00 0d f0 fe ca 00 00 00 00 ................ (tag: 0x2) <...> (lldb) memory find -e 0xcafef00d mte_buf mte_buf+64 --show-tags data found at location: 0xfffff7ff8028 0xfffff7ff8028: 0d f0 fe ca 00 00 00 00 00 00 00 00 00 00 00 00 ................ (tags: 0x2 0x3) 0xfffff7ff8038: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ (tags: 0x3 0x4) ``` The logic for handling alignments is the same as for memory read so in the above example because the line starts misaligned to the granule it covers 2 granules. Depends on D125089 Reviewed By: omjavaid Differential Revision: https://reviews.llvm.org/D125090
2022-04-13 21:32:18 +08:00
m_option_group.Append(&m_memory_tag_options, LLDB_OPT_SET_ALL,
LLDB_OPT_SET_ALL);
<rdar://problem/14322677> Implement a "memory find" command for LLDB This is still fairly rough around the edges but works well enough for simple scenarios where a chunk of text or a number are to be found within a certain range of memory, as in mem find `buffer` `buffer+0x1000` -s "me" -c 5 -r llvm-svn: 194544
2013-11-13 10:18:44 +08:00
m_option_group.Finalize();
}
Fix Clang-tidy modernize-use-nullptr and modernize-use-default warnings in some files in source/Commands; other minor fixes. llvm-svn: 261389
2016-02-20 08:58:29 +08:00
~CommandObjectMemoryFind() override = default;
<rdar://problem/14322677> Implement a "memory find" command for LLDB This is still fairly rough around the edges but works well enough for simple scenarios where a chunk of text or a number are to be found within a certain range of memory, as in mem find `buffer` `buffer+0x1000` -s "me" -c 5 -r llvm-svn: 194544
2013-11-13 10:18:44 +08:00
Options *GetOptions() override { return &m_option_group; }
*** 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/14322677> Implement a "memory find" command for LLDB This is still fairly rough around the edges but works well enough for simple scenarios where a chunk of text or a number are to be found within a certain range of memory, as in mem find `buffer` `buffer+0x1000` -s "me" -c 5 -r llvm-svn: 194544
2013-11-13 10:18:44 +08:00
protected:
Change "memory find" over to using a variation of the Boyer–Moore search algorithm Fixes rdar://15455621 (and adds a test case for this command which - surprisingly and sadly - was not there originally) llvm-svn: 280327
2016-09-01 08:09:59 +08:00
class ProcessMemoryIterator {
public:
ProcessMemoryIterator(ProcessSP process_sp, lldb::addr_t base)
[LLDB] Applying clang-tidy modernize-use-default-member-init over LLDB Applied modernize-use-default-member-init clang-tidy check over LLDB. It appears in many files we had already switched to in class member init but never updated the constructors to reflect that. This check is already present in the lldb/.clang-tidy config. Differential Revision: https://reviews.llvm.org/D121481
2022-03-15 04:32:03 +08:00
: m_process_sp(process_sp), m_base_addr(base) {
Change "memory find" over to using a variation of the Boyer–Moore search algorithm Fixes rdar://15455621 (and adds a test case for this command which - surprisingly and sadly - was not there originally) llvm-svn: 280327
2016-09-01 08:09:59 +08:00
lldbassert(process_sp.get() != nullptr);
}
bool IsValid() { return m_is_valid; }
*** 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 "memory find" over to using a variation of the Boyer–Moore search algorithm Fixes rdar://15455621 (and adds a test case for this command which - surprisingly and sadly - was not there originally) llvm-svn: 280327
2016-09-01 08:09:59 +08:00
uint8_t operator[](lldb::addr_t offset) {
if (!IsValid())
return 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
Change "memory find" over to using a variation of the Boyer–Moore search algorithm Fixes rdar://15455621 (and adds a test case for this command which - surprisingly and sadly - was not there originally) llvm-svn: 280327
2016-09-01 08:09:59 +08:00
uint8_t retval = 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;
*** 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
if (0 ==
Change "memory find" over to using a variation of the Boyer–Moore search algorithm Fixes rdar://15455621 (and adds a test case for this command which - surprisingly and sadly - was not there originally) llvm-svn: 280327
2016-09-01 08:09:59 +08:00
m_process_sp->ReadMemory(m_base_addr + offset, &retval, 1, error)) {
m_is_valid = false;
return 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
Change "memory find" over to using a variation of the Boyer–Moore search algorithm Fixes rdar://15455621 (and adds a test case for this command which - surprisingly and sadly - was not there originally) llvm-svn: 280327
2016-09-01 08:09:59 +08:00
return retval;
*** 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 "memory find" over to using a variation of the Boyer–Moore search algorithm Fixes rdar://15455621 (and adds a test case for this command which - surprisingly and sadly - was not there originally) llvm-svn: 280327
2016-09-01 08:09:59 +08:00
private:
ProcessSP m_process_sp;
lldb::addr_t m_base_addr;
[LLDB] Applying clang-tidy modernize-use-default-member-init over LLDB Applied modernize-use-default-member-init clang-tidy check over LLDB. It appears in many files we had already switched to in class member init but never updated the constructors to reflect that. This check is already present in the lldb/.clang-tidy config. Differential Revision: https://reviews.llvm.org/D121481
2022-03-15 04:32:03 +08:00
bool m_is_valid = true;
Change "memory find" over to using a variation of the Boyer–Moore search algorithm Fixes rdar://15455621 (and adds a test case for this command which - surprisingly and sadly - was not there originally) llvm-svn: 280327
2016-09-01 08:09:59 +08:00
};
commands: Use override instead of virtual. Summary: This removes all uses of virtual on functions where override could be used, including on destructors. It also adds override where virtual was previously missing. Reviewers: clayborg, labath Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D13503 llvm-svn: 249564
2015-10-08 00:56:17 +08:00
bool DoExecute(Args &command, CommandReturnObject &result) override {
Add support for custom commands to set flags on themselves This works for Python commands defined via a class (implement get_flags on your class) and C++ plugin commands (which can call SBCommand::GetFlags()/SetFlags()) Flags allow features such as not letting the command run if there's no target, or if the process is not stopped, ... Commands could always check for these things themselves, but having these accessible via flags makes custom commands more consistent with built-in ones llvm-svn: 238286
2015-05-27 13:04:35 +08:00
// No need to check "process" for validity as eCommandRequiresProcess
// ensures it is valid
<rdar://problem/14322677> Implement a "memory find" command for LLDB This is still fairly rough around the edges but works well enough for simple scenarios where a chunk of text or a number are to be found within a certain range of memory, as in mem find `buffer` `buffer+0x1000` -s "me" -c 5 -r llvm-svn: 194544
2013-11-13 10:18:44 +08:00
Process *process = m_exe_ctx.GetProcessPtr();
const size_t argc = command.GetArgumentCount();
if (argc != 2) {
Small typos in previous commit llvm-svn: 194546
2013-11-13 10:22:24 +08:00
result.AppendError("two addresses needed for memory find");
<rdar://problem/14322677> Implement a "memory find" command for LLDB This is still fairly rough around the edges but works well enough for simple scenarios where a chunk of text or a number are to be found within a certain range of memory, as in mem find `buffer` `buffer+0x1000` -s "me" -c 5 -r llvm-svn: 194544
2013-11-13 10:18:44 +08:00
return false;
}
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;
Move Args::StringTo*** functions to a new OptionArgParser class Summary: The idea behind this is to move the functionality which depend on other lldb classes into a separate class. This way, the Args class can be turned into a lightweight arc+argv wrapper and moved into the lower lldb layers. Reviewers: jingham, zturner Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D44306 llvm-svn: 329677
2018-04-10 17:03:59 +08:00
lldb::addr_t low_addr = OptionArgParser::ToAddress(
[lldb][NFC] Remove ArgEntry::ref member The StringRef should always be identical to the C string, so we might as well just create the StringRef from the C-string. This might be slightly slower until we implement the storage of ArgEntry with a string instead of a std::unique_ptr<char[]>. Until then we have to do the additional strlen on the C string to construct the StringRef. llvm-svn: 371842
2019-09-13 19:26:48 +08:00
&m_exe_ctx, command[0].ref(), LLDB_INVALID_ADDRESS, &error);
<rdar://problem/14322677> Implement a "memory find" command for LLDB This is still fairly rough around the edges but works well enough for simple scenarios where a chunk of text or a number are to be found within a certain range of memory, as in mem find `buffer` `buffer+0x1000` -s "me" -c 5 -r llvm-svn: 194544
2013-11-13 10:18:44 +08:00
if (low_addr == LLDB_INVALID_ADDRESS || error.Fail()) {
result.AppendError("invalid low address");
return false;
*** 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
}
Move Args::StringTo*** functions to a new OptionArgParser class Summary: The idea behind this is to move the functionality which depend on other lldb classes into a separate class. This way, the Args class can be turned into a lightweight arc+argv wrapper and moved into the lower lldb layers. Reviewers: jingham, zturner Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D44306 llvm-svn: 329677
2018-04-10 17:03:59 +08:00
lldb::addr_t high_addr = OptionArgParser::ToAddress(
[lldb][NFC] Remove ArgEntry::ref member The StringRef should always be identical to the C string, so we might as well just create the StringRef from the C-string. This might be slightly slower until we implement the storage of ArgEntry with a string instead of a std::unique_ptr<char[]>. Until then we have to do the additional strlen on the C string to construct the StringRef. llvm-svn: 371842
2019-09-13 19:26:48 +08:00
&m_exe_ctx, command[1].ref(), LLDB_INVALID_ADDRESS, &error);
<rdar://problem/14322677> Implement a "memory find" command for LLDB This is still fairly rough around the edges but works well enough for simple scenarios where a chunk of text or a number are to be found within a certain range of memory, as in mem find `buffer` `buffer+0x1000` -s "me" -c 5 -r llvm-svn: 194544
2013-11-13 10:18:44 +08:00
if (high_addr == LLDB_INVALID_ADDRESS || error.Fail()) {
Correct copied error message Patch by Remco Verhoef. llvm-svn: 217312
2014-09-06 19:29:08 +08:00
result.AppendError("invalid high address");
<rdar://problem/14322677> Implement a "memory find" command for LLDB This is still fairly rough around the edges but works well enough for simple scenarios where a chunk of text or a number are to be found within a certain range of memory, as in mem find `buffer` `buffer+0x1000` -s "me" -c 5 -r llvm-svn: 194544
2013-11-13 10:18:44 +08:00
return false;
*** 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
}
[lldb] Ignore non-address bits in "memory find" arguments This removes the non-address bits before we try to use the addresses. Meaning that when results are shown, those results won't show non-address bits either. This follows what "memory read" has done. On the grounds that non-address bits are a property of a pointer, not the memory pointed to. I've added testing and merged the find and read tests into one file. Note that there are no API side changes because "memory find" does not have an equivalent API call. Reviewed By: omjavaid Differential Revision: https://reviews.llvm.org/D117299
2022-01-14 00:54:04 +08:00
ABISP abi = m_exe_ctx.GetProcessPtr()->GetABI();
if (abi) {
low_addr = abi->FixDataAddress(low_addr);
high_addr = abi->FixDataAddress(high_addr);
}
<rdar://problem/14322677> Implement a "memory find" command for LLDB This is still fairly rough around the edges but works well enough for simple scenarios where a chunk of text or a number are to be found within a certain range of memory, as in mem find `buffer` `buffer+0x1000` -s "me" -c 5 -r llvm-svn: 194544
2013-11-13 10:18:44 +08:00
if (high_addr <= low_addr) {
Correct copied error message Patch by Remco Verhoef. llvm-svn: 217312
2014-09-06 19:29:08 +08:00
result.AppendError(
<rdar://problem/14322677> Implement a "memory find" command for LLDB This is still fairly rough around the edges but works well enough for simple scenarios where a chunk of text or a number are to be found within a certain range of memory, as in mem find `buffer` `buffer+0x1000` -s "me" -c 5 -r llvm-svn: 194544
2013-11-13 10:18:44 +08:00
"starting address must be smaller than ending address");
return false;
*** 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/14322677> Implement a "memory find" command for LLDB This is still fairly rough around the edges but works well enough for simple scenarios where a chunk of text or a number are to be found within a certain range of memory, as in mem find `buffer` `buffer+0x1000` -s "me" -c 5 -r llvm-svn: 194544
2013-11-13 10:18:44 +08:00
lldb::addr_t found_location = LLDB_INVALID_ADDRESS;
*** 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/14322677> Implement a "memory find" command for LLDB This is still fairly rough around the edges but works well enough for simple scenarios where a chunk of text or a number are to be found within a certain range of memory, as in mem find `buffer` `buffer+0x1000` -s "me" -c 5 -r llvm-svn: 194544
2013-11-13 10:18:44 +08:00
DataBufferHeap buffer;
*** 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
[lldb] Handle empty search string in "memory find" Given that you'd never find empty string, just error. Also add a test that an invalid expr generates an error. Reviewed By: JDevlieghere Differential Revision: https://reviews.llvm.org/D123793
2022-04-14 22:06:27 +08:00
if (m_memory_options.m_string.OptionWasSet()) {
llvm::StringRef str = m_memory_options.m_string.GetStringValue();
if (str.empty()) {
result.AppendError("search string must have non-zero length.");
return false;
}
buffer.CopyData(str);
} else if (m_memory_options.m_expr.OptionWasSet()) {
Roll back the changes I made in r193907 which created a new Frame pure virtual base class and made StackFrame a subclass of that. As I started to build on top of that arrangement today, I found that it wasn't working out like I intended. Instead I'll try sticking with the single StackFrame class -- there's too much code duplication to make a more complicated class hierarchy sensible I think. llvm-svn: 193983
2013-11-04 17:33:30 +08:00
StackFrame *frame = m_exe_ctx.GetFramePtr();
<rdar://problem/14322677> Implement a "memory find" command for LLDB This is still fairly rough around the edges but works well enough for simple scenarios where a chunk of text or a number are to be found within a certain range of memory, as in mem find `buffer` `buffer+0x1000` -s "me" -c 5 -r llvm-svn: 194544
2013-11-13 10:18:44 +08:00
ValueObjectSP result_sp;
Fix the memory find command such that it can actually take an expression llvm-svn: 243893
2015-08-04 02:51:39 +08:00
if ((eExpressionCompleted ==
process->GetTarget().EvaluateExpression(
m_memory_options.m_expr.GetStringValue(), frame, result_sp)) &&
result_sp) {
<rdar://problem/14322677> Implement a "memory find" command for LLDB This is still fairly rough around the edges but works well enough for simple scenarios where a chunk of text or a number are to be found within a certain range of memory, as in mem find `buffer` `buffer+0x1000` -s "me" -c 5 -r llvm-svn: 194544
2013-11-13 10:18:44 +08:00
uint64_t value = result_sp->GetValueAsUnsigned(0);
Replace auto -> llvm::Optional<uint64_t> This addresses post-commit feedback for https://reviews.llvm.org/D56688 llvm-svn: 351237
2019-01-16 04:33:58 +08:00
llvm::Optional<uint64_t> size =
result_sp->GetCompilerType().GetByteSize(nullptr);
Make CompilerType::getBitSize() / getByteSize() return an optional result. NFC The code in LLDB assumes that CompilerType and friends use the size 0 as a sentinel value to signal an error. This works for C++, where no zero-sized type exists, but in many other programming languages (including I believe C) types of size zero are possible and even common. This is a particular pain point in swift-lldb, where extra code exists to double-check that a type is *really* of size zero and not an error at various locations. To remedy this situation, this patch starts by converting CompilerType::getBitSize() and getByteSize() to return an optional result. To avoid wasting space, I hand-rolled my own optional data type assuming that no type is larger than what fits into 63 bits. Follow-up patches would make similar changes to the ValueObject hierarchy. rdar://problem/47178964 Differential Revision: https://reviews.llvm.org/D56688 llvm-svn: 351214
2019-01-16 02:07:52 +08:00
if (!size)
return false;
switch (*size) {
<rdar://problem/14322677> Implement a "memory find" command for LLDB This is still fairly rough around the edges but works well enough for simple scenarios where a chunk of text or a number are to be found within a certain range of memory, as in mem find `buffer` `buffer+0x1000` -s "me" -c 5 -r llvm-svn: 194544
2013-11-13 10:18:44 +08:00
case 1: {
uint8_t byte = (uint8_t)value;
buffer.CopyData(&byte, 1);
*** 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
} break;
<rdar://problem/14322677> Implement a "memory find" command for LLDB This is still fairly rough around the edges but works well enough for simple scenarios where a chunk of text or a number are to be found within a certain range of memory, as in mem find `buffer` `buffer+0x1000` -s "me" -c 5 -r llvm-svn: 194544
2013-11-13 10:18:44 +08:00
case 2: {
uint16_t word = (uint16_t)value;
buffer.CopyData(&word, 2);
*** 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
} break;
<rdar://problem/14322677> Implement a "memory find" command for LLDB This is still fairly rough around the edges but works well enough for simple scenarios where a chunk of text or a number are to be found within a certain range of memory, as in mem find `buffer` `buffer+0x1000` -s "me" -c 5 -r llvm-svn: 194544
2013-11-13 10:18:44 +08:00
case 4: {
uint32_t lword = (uint32_t)value;
buffer.CopyData(&lword, 4);
*** 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
} break;
<rdar://problem/14322677> Implement a "memory find" command for LLDB This is still fairly rough around the edges but works well enough for simple scenarios where a chunk of text or a number are to be found within a certain range of memory, as in mem find `buffer` `buffer+0x1000` -s "me" -c 5 -r llvm-svn: 194544
2013-11-13 10:18:44 +08:00
case 8: {
buffer.CopyData(&value, 8);
*** 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
} break;
case 3:
case 5:
case 6:
case 7:
<rdar://problem/14322677> Implement a "memory find" command for LLDB This is still fairly rough around the edges but works well enough for simple scenarios where a chunk of text or a number are to be found within a certain range of memory, as in mem find `buffer` `buffer+0x1000` -s "me" -c 5 -r llvm-svn: 194544
2013-11-13 10:18:44 +08:00
result.AppendError("unknown type. pass a string instead");
return false;
*** 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
default:
<rdar://problem/14322677> Implement a "memory find" command for LLDB This is still fairly rough around the edges but works well enough for simple scenarios where a chunk of text or a number are to be found within a certain range of memory, as in mem find `buffer` `buffer+0x1000` -s "me" -c 5 -r llvm-svn: 194544
2013-11-13 10:18:44 +08:00
result.AppendError(
"result size larger than 8 bytes. pass a string instead");
return false;
*** 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 {
Correct copied error message Patch by Remco Verhoef. llvm-svn: 217312
2014-09-06 19:29:08 +08:00
result.AppendError(
Fix the memory find command such that it can actually take an expression llvm-svn: 243893
2015-08-04 02:51:39 +08:00
"expression evaluation failed. pass a string instead");
<rdar://problem/14322677> Implement a "memory find" command for LLDB This is still fairly rough around the edges but works well enough for simple scenarios where a chunk of text or a number are to be found within a certain range of memory, as in mem find `buffer` `buffer+0x1000` -s "me" -c 5 -r llvm-svn: 194544
2013-11-13 10:18:44 +08:00
return false;
}
*** 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 {
Correct copied error message Patch by Remco Verhoef. llvm-svn: 217312
2014-09-06 19:29:08 +08:00
result.AppendError(
<rdar://problem/14322677> Implement a "memory find" command for LLDB This is still fairly rough around the edges but works well enough for simple scenarios where a chunk of text or a number are to be found within a certain range of memory, as in mem find `buffer` `buffer+0x1000` -s "me" -c 5 -r llvm-svn: 194544
2013-11-13 10:18:44 +08:00
"please pass either a block of text, or an expression to evaluate.");
return false;
*** 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/14322677> Implement a "memory find" command for LLDB This is still fairly rough around the edges but works well enough for simple scenarios where a chunk of text or a number are to be found within a certain range of memory, as in mem find `buffer` `buffer+0x1000` -s "me" -c 5 -r llvm-svn: 194544
2013-11-13 10:18:44 +08:00
size_t count = m_memory_options.m_count.GetCurrentValue();
found_location = low_addr;
bool ever_found = false;
while (count) {
found_location = FastSearch(found_location, high_addr, buffer.GetBytes(),
Change "memory find" over to using a variation of the Boyer–Moore search algorithm Fixes rdar://15455621 (and adds a test case for this command which - surprisingly and sadly - was not there originally) llvm-svn: 280327
2016-09-01 08:09:59 +08:00
buffer.GetByteSize());
<rdar://problem/14322677> Implement a "memory find" command for LLDB This is still fairly rough around the edges but works well enough for simple scenarios where a chunk of text or a number are to be found within a certain range of memory, as in mem find `buffer` `buffer+0x1000` -s "me" -c 5 -r llvm-svn: 194544
2013-11-13 10:18:44 +08:00
if (found_location == LLDB_INVALID_ADDRESS) {
if (!ever_found) {
result.AppendMessage("data not found within the range.\n");
result.SetStatus(lldb::eReturnStatusSuccessFinishNoResult);
} else
result.AppendMessage("no more matches within the range.\n");
break;
}
result.AppendMessageWithFormat("data found at location: 0x%" PRIx64 "\n",
found_location);
*** 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/14322677> Implement a "memory find" command for LLDB This is still fairly rough around the edges but works well enough for simple scenarios where a chunk of text or a number are to be found within a certain range of memory, as in mem find `buffer` `buffer+0x1000` -s "me" -c 5 -r llvm-svn: 194544
2013-11-13 10:18:44 +08:00
DataBufferHeap dumpbuffer(32, 0);
Fix the memory find command such that it can actually take an expression llvm-svn: 243893
2015-08-04 02:51:39 +08:00
process->ReadMemory(
found_location + m_memory_options.m_offset.GetCurrentValue(),
Final bit of type system cleanup that abstracts declaration contexts into lldb_private::CompilerDeclContext and renames ClangType to CompilerType in many accessors and functions. Create a new "lldb_private::CompilerDeclContext" class that will replace all direct uses of "clang::DeclContext" when used in compiler agnostic code, yet still allow for conversion to clang::DeclContext subclasses by clang specific code. This completes the abstraction of type parsing by removing all "clang::" references from the SymbolFileDWARF. The new "lldb_private::CompilerDeclContext" class abstracts decl contexts found in compiler type systems so they can be used in internal API calls. The TypeSystem is required to support CompilerDeclContexts with new pure virtual functions that start with "DeclContext" in the member function names. Converted all code that used lldb_private::ClangNamespaceDecl over to use the new CompilerDeclContext class and removed the ClangNamespaceDecl.cpp and ClangNamespaceDecl.h files. Removed direct use of clang APIs from SBType and now use the abstract type systems to correctly explore types. Bulk renames for things that used to return a ClangASTType which is now CompilerType: "Type::GetClangFullType()" to "Type::GetFullCompilerType()" "Type::GetClangLayoutType()" to "Type::GetLayoutCompilerType()" "Type::GetClangForwardType()" to "Type::GetForwardCompilerType()" "Value::GetClangType()" to "Value::GetCompilerType()" "Value::SetClangType (const CompilerType &)" to "Value::SetCompilerType (const CompilerType &)" "ValueObject::GetClangType ()" to "ValueObject::GetCompilerType()" many more renames that are similar. llvm-svn: 245905
2015-08-25 07:46:31 +08:00
dumpbuffer.GetBytes(), dumpbuffer.GetByteSize(), error);
if (!error.Fail()) {
<rdar://problem/14322677> Implement a "memory find" command for LLDB This is still fairly rough around the edges but works well enough for simple scenarios where a chunk of text or a number are to be found within a certain range of memory, as in mem find `buffer` `buffer+0x1000` -s "me" -c 5 -r llvm-svn: 194544
2013-11-13 10:18:44 +08:00
DataExtractor data(dumpbuffer.GetBytes(), dumpbuffer.GetByteSize(),
process->GetByteOrder(),
Fix the memory find command such that it can actually take an expression llvm-svn: 243893
2015-08-04 02:51:39 +08:00
process->GetAddressByteSize());
Isolate Target-specific functionality of DataExtractor. In an effort to move the various DataBuffer / DataExtractor classes from Core -> Utility, we have to separate the low-level functionality from the higher level functionality. Only a few functions required anything other than reading/writing raw bytes, so those functions are separated out into a more appropriate area. Specifically, Dump() and DumpHexBytes() are moved into free functions in Core/DumpDataExtractor.cpp, and GetGNUEHPointer is moved into a static function in the only file that it's referenced from. Differential Revision: https://reviews.llvm.org/D30560 llvm-svn: 296910
2017-03-04 04:57:05 +08:00
DumpDataExtractor(
data, &result.GetOutputStream(), 0, lldb::eFormatBytesWithASCII, 1,
dumpbuffer.GetByteSize(), 16,
[lldb] Add --show-tags option to "memory find" This is off by default. If you get a result and that memory has memory tags, when --show-tags is given you'll see the tags inline with the memory content. ``` (lldb) memory read mte_buf mte_buf+64 --show-tags <...> 0xfffff7ff8020: 00 00 00 00 00 00 00 00 0d f0 fe ca 00 00 00 00 ................ (tag: 0x2) <...> (lldb) memory find -e 0xcafef00d mte_buf mte_buf+64 --show-tags data found at location: 0xfffff7ff8028 0xfffff7ff8028: 0d f0 fe ca 00 00 00 00 00 00 00 00 00 00 00 00 ................ (tags: 0x2 0x3) 0xfffff7ff8038: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ (tags: 0x3 0x4) ``` The logic for handling alignments is the same as for memory read so in the above example because the line starts misaligned to the granule it covers 2 granules. Depends on D125089 Reviewed By: omjavaid Differential Revision: https://reviews.llvm.org/D125090
2022-04-13 21:32:18 +08:00
found_location + m_memory_options.m_offset.GetCurrentValue(), 0, 0,
m_exe_ctx.GetBestExecutionContextScope(),
m_memory_tag_options.GetShowTags().GetCurrentValue());
Fix the memory find command such that it can actually take an expression llvm-svn: 243893
2015-08-04 02:51:39 +08:00
result.GetOutputStream().EOL();
<rdar://problem/14322677> Implement a "memory find" command for LLDB This is still fairly rough around the edges but works well enough for simple scenarios where a chunk of text or a number are to be found within a certain range of memory, as in mem find `buffer` `buffer+0x1000` -s "me" -c 5 -r llvm-svn: 194544
2013-11-13 10:18:44 +08:00
}
Minor improvement to the "memory find" command Remove the --do-read option, and always provide a small dump of memory at each match spot Add a --dump-offset (-o) option, to specify a byte offset from which to start dumping relative to the matching address The real solution is to actually provide the format options found on "memory read" and use those as the key to actually printing memory upon each find That, however, requires a little refactoring work, so put this in for now until I get a chance to do the required shuffling around of moving parts llvm-svn: 194600
2013-11-14 04:08:30 +08:00
<rdar://problem/14322677> Implement a "memory find" command for LLDB This is still fairly rough around the edges but works well enough for simple scenarios where a chunk of text or a number are to be found within a certain range of memory, as in mem find `buffer` `buffer+0x1000` -s "me" -c 5 -r llvm-svn: 194544
2013-11-13 10:18:44 +08:00
--count;
found_location++;
ever_found = true;
}
*** 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/14322677> Implement a "memory find" command for LLDB This is still fairly rough around the edges but works well enough for simple scenarios where a chunk of text or a number are to be found within a certain range of memory, as in mem find `buffer` `buffer+0x1000` -s "me" -c 5 -r llvm-svn: 194544
2013-11-13 10:18:44 +08:00
result.SetStatus(lldb::eReturnStatusSuccessFinishResult);
return true;
}
*** 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 "memory find" over to using a variation of the Boyer–Moore search algorithm Fixes rdar://15455621 (and adds a test case for this command which - surprisingly and sadly - was not there originally) llvm-svn: 280327
2016-09-01 08:09:59 +08:00
lldb::addr_t FastSearch(lldb::addr_t low, lldb::addr_t high, uint8_t *buffer,
size_t buffer_size) {
const size_t region_size = high - low;
*** 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 "memory find" over to using a variation of the Boyer–Moore search algorithm Fixes rdar://15455621 (and adds a test case for this command which - surprisingly and sadly - was not there originally) llvm-svn: 280327
2016-09-01 08:09:59 +08:00
if (region_size < buffer_size)
return LLDB_INVALID_ADDRESS;
*** 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 "memory find" over to using a variation of the Boyer–Moore search algorithm Fixes rdar://15455621 (and adds a test case for this command which - surprisingly and sadly - was not there originally) llvm-svn: 280327
2016-09-01 08:09:59 +08:00
std::vector<size_t> bad_char_heuristic(256, buffer_size);
ProcessSP process_sp = m_exe_ctx.GetProcessSP();
ProcessMemoryIterator iterator(process_sp, low);
*** 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 "memory find" over to using a variation of the Boyer–Moore search algorithm Fixes rdar://15455621 (and adds a test case for this command which - surprisingly and sadly - was not there originally) llvm-svn: 280327
2016-09-01 08:09:59 +08:00
for (size_t idx = 0; idx < buffer_size - 1; idx++) {
decltype(bad_char_heuristic)::size_type bcu_idx = buffer[idx];
bad_char_heuristic[bcu_idx] = buffer_size - idx - 1;
<rdar://problem/14322677> Implement a "memory find" command for LLDB This is still fairly rough around the edges but works well enough for simple scenarios where a chunk of text or a number are to be found within a certain range of memory, as in mem find `buffer` `buffer+0x1000` -s "me" -c 5 -r llvm-svn: 194544
2013-11-13 10:18:44 +08:00
}
Change "memory find" over to using a variation of the Boyer–Moore search algorithm Fixes rdar://15455621 (and adds a test case for this command which - surprisingly and sadly - was not there originally) llvm-svn: 280327
2016-09-01 08:09:59 +08:00
for (size_t s = 0; s <= (region_size - buffer_size);) {
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
int64_t j = buffer_size - 1;
Change "memory find" over to using a variation of the Boyer–Moore search algorithm Fixes rdar://15455621 (and adds a test case for this command which - surprisingly and sadly - was not there originally) llvm-svn: 280327
2016-09-01 08:09:59 +08:00
while (j >= 0 && buffer[j] == iterator[s + j])
*** 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
j--;
Change "memory find" over to using a variation of the Boyer–Moore search algorithm Fixes rdar://15455621 (and adds a test case for this command which - surprisingly and sadly - was not there originally) llvm-svn: 280327
2016-09-01 08:09:59 +08:00
if (j < 0)
return low + s;
*** 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
Change "memory find" over to using a variation of the Boyer–Moore search algorithm Fixes rdar://15455621 (and adds a test case for this command which - surprisingly and sadly - was not there originally) llvm-svn: 280327
2016-09-01 08:09:59 +08:00
s += bad_char_heuristic[iterator[s + buffer_size - 1]];
*** 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/14322677> Implement a "memory find" command for LLDB This is still fairly rough around the edges but works well enough for simple scenarios where a chunk of text or a number are to be found within a certain range of memory, as in mem find `buffer` `buffer+0x1000` -s "me" -c 5 -r llvm-svn: 194544
2013-11-13 10:18:44 +08:00
return LLDB_INVALID_ADDRESS;
*** 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/14322677> Implement a "memory find" command for LLDB This is still fairly rough around the edges but works well enough for simple scenarios where a chunk of text or a number are to be found within a certain range of memory, as in mem find `buffer` `buffer+0x1000` -s "me" -c 5 -r llvm-svn: 194544
2013-11-13 10:18:44 +08:00
OptionGroupOptions m_option_group;
OptionGroupFindMemory m_memory_options;
[lldb] Add --show-tags option to "memory find" This is off by default. If you get a result and that memory has memory tags, when --show-tags is given you'll see the tags inline with the memory content. ``` (lldb) memory read mte_buf mte_buf+64 --show-tags <...> 0xfffff7ff8020: 00 00 00 00 00 00 00 00 0d f0 fe ca 00 00 00 00 ................ (tag: 0x2) <...> (lldb) memory find -e 0xcafef00d mte_buf mte_buf+64 --show-tags data found at location: 0xfffff7ff8028 0xfffff7ff8028: 0d f0 fe ca 00 00 00 00 00 00 00 00 00 00 00 00 ................ (tags: 0x2 0x3) 0xfffff7ff8038: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ (tags: 0x3 0x4) ``` The logic for handling alignments is the same as for memory read so in the above example because the line starts misaligned to the granule it covers 2 granules. Depends on D125089 Reviewed By: omjavaid Differential Revision: https://reviews.llvm.org/D125090
2022-04-13 21:32:18 +08:00
OptionGroupMemoryTag m_memory_tag_options;
<rdar://problem/14322677> Implement a "memory find" command for LLDB This is still fairly rough around the edges but works well enough for simple scenarios where a chunk of text or a number are to be found within a certain range of memory, as in mem find `buffer` `buffer+0x1000` -s "me" -c 5 -r llvm-svn: 194544
2013-11-13 10:18:44 +08:00
};
[lldb] Tablegenify expr/frame/log/register/memory llvm-svn: 367009
2019-07-25 19:22:46 +08:00
#define LLDB_OPTIONS_memory_write
#include "CommandOptions.inc"
Updated all commands that use a "--format" / "-f" options to use the new OptionGroupFormat. Updated OptionGroupFormat to be able to also use the "--size" and "--count" options. Commands that use a OptionGroupFormat instance can choose which of the options they want by initializing OptionGroupFormat accordingly. Clients can either get only the "--format", "--format" + "--size", or "--format" + "--size" + "--count". This is in preparation for upcoming chnages where there are alternate ways (GDB format specification) to set a format. llvm-svn: 142911
2011-10-25 14:44:01 +08:00
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
// Write memory to the inferior process
Make raw & parsed commands subclasses of CommandObject rather than having the raw version implement an Execute which was never going to get run and another ExecuteRawCommandString. Took the knowledge of how to prepare raw & parsed commands out of CommandInterpreter and put it in CommandObject where it belongs. Also took all the cases where there were the subcommands of Multiword commands declared in the .h file for the overall command and moved them into the .cpp file. Made the CommandObject flags work for raw as well as parsed commands. Made "expr" use the flags so that it requires you to be paused to run "expr". llvm-svn: 158235
2012-06-09 05:56:10 +08:00
class CommandObjectMemoryWrite : public CommandObjectParsed {
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
public:
Updated all commands that use a "--format" / "-f" options to use the new OptionGroupFormat. Updated OptionGroupFormat to be able to also use the "--size" and "--count" options. Commands that use a OptionGroupFormat instance can choose which of the options they want by initializing OptionGroupFormat accordingly. Clients can either get only the "--format", "--format" + "--size", or "--format" + "--size" + "--count". This is in preparation for upcoming chnages where there are alternate ways (GDB format specification) to set a format. llvm-svn: 142911
2011-10-25 14:44:01 +08:00
class OptionGroupWriteMemory : public OptionGroup {
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
public:
[LLDB] Applying clang-tidy modernize-use-equals-default over LLDB Applied modernize-use-equals-default clang-tidy check over LLDB. This check is already present in the lldb/.clang-tidy config. Differential Revision: https://reviews.llvm.org/D121844
2022-04-01 04:20:46 +08:00
OptionGroupWriteMemory() = default;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
Fix Clang-tidy modernize-use-nullptr and modernize-use-default warnings in some files in source/Commands; other minor fixes. llvm-svn: 261389
2016-02-20 08:58:29 +08:00
~OptionGroupWriteMemory() override = default;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
Convert option tables to ArrayRefs. This change is very mechanical. All it does is change the signature of `Options::GetDefinitions()` and `OptionGroup:: GetDefinitions()` to return an `ArrayRef<OptionDefinition>` instead of a `const OptionDefinition *`. In the case of the former, it deletes the sentinel entry from every table, and in the case of the latter, it removes the `GetNumDefinitions()` method from the interface. These are no longer necessary as `ArrayRef` carries its own length. In the former case, iteration was done by using a sentinel entry, so there was no knowledge of length. Because of this the individual option tables were allowed to be defined below the corresponding class (after all, only a pointer was needed). Now, however, the length must be known at compile time to construct the `ArrayRef`, and as a result it is necessary to move every option table before its corresponding class. This results in this CL looking very big, but in terms of substance there is not much here. Differential revision: https://reviews.llvm.org/D24834 llvm-svn: 282188
2016-09-23 04:22:55 +08:00
llvm::ArrayRef<OptionDefinition> GetDefinitions() override {
[lldb] Also include the array definition in CommandOptions.inc Summary: Right now our CommandOptions.inc only generates the initializer for the options list but not the array declaration boilerplate around it. As the array definition is identical for all arrays, we might as well also let the CommandOptions.inc generate it alongside the initializers. This patch will also allow us to generate additional declarations related to that option list in the future (e.g. a enum class representing the specific options which would make our handling code less prone). This patch also fixes a few option tables that didn't follow our naming style. Reviewers: JDevlieghere Reviewed By: JDevlieghere Subscribers: abidh, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D65331 llvm-svn: 367186
2019-07-28 14:24:07 +08:00
return llvm::makeArrayRef(g_memory_write_options);
Updated all commands that use a "--format" / "-f" options to use the new OptionGroupFormat. Updated OptionGroupFormat to be able to also use the "--size" and "--count" options. Commands that use a OptionGroupFormat instance can choose which of the options they want by initializing OptionGroupFormat accordingly. Clients can either get only the "--format", "--format" + "--size", or "--format" + "--size" + "--count". This is in preparation for upcoming chnages where there are alternate ways (GDB format specification) to set a format. llvm-svn: 142911
2011-10-25 14:44:01 +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
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 SetOptionValue(uint32_t option_idx, llvm::StringRef option_value,
ExecutionContext *execution_context) override {
Status error;
[lldb] Also include the array definition in CommandOptions.inc Summary: Right now our CommandOptions.inc only generates the initializer for the options list but not the array declaration boilerplate around it. As the array definition is identical for all arrays, we might as well also let the CommandOptions.inc generate it alongside the initializers. This patch will also allow us to generate additional declarations related to that option list in the future (e.g. a enum class representing the specific options which would make our handling code less prone). This patch also fixes a few option tables that didn't follow our naming style. Reviewers: JDevlieghere Reviewed By: JDevlieghere Subscribers: abidh, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D65331 llvm-svn: 367186
2019-07-28 14:24:07 +08:00
const int short_option = g_memory_write_options[option_idx].short_option;
*** 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
Cleaned up many error codes. For any who is filling in error strings into lldb_private::Error objects the rules are: - short strings that don't start with a capitol letter unless the name is a class or anything else that is always capitolized - no trailing newline character - should be one line if possible Implemented a first pass at adding "--gdb-format" support to anything that accepts format with optional size/count. llvm-svn: 142999
2011-10-26 08:56:27 +08:00
switch (short_option) {
Updated all commands that use a "--format" / "-f" options to use the new OptionGroupFormat. Updated OptionGroupFormat to be able to also use the "--size" and "--count" options. Commands that use a OptionGroupFormat instance can choose which of the options they want by initializing OptionGroupFormat accordingly. Clients can either get only the "--format", "--format" + "--size", or "--format" + "--size" + "--count". This is in preparation for upcoming chnages where there are alternate ways (GDB format specification) to set a format. llvm-svn: 142911
2011-10-25 14:44:01 +08:00
case 'i':
[FileSystem] Move path resolution logic out of FileSpec This patch removes the logic for resolving paths out of FileSpec and updates call sites to rely on the FileSystem class instead. Differential revision: https://reviews.llvm.org/D53915 llvm-svn: 345890
2018-11-02 05:05:36 +08:00
m_infile.SetFile(option_value, FileSpec::Style::native);
FileSystem::Instance().Resolve(m_infile);
[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
if (!FileSystem::Instance().Exists(m_infile)) {
Cleaned up many error codes. For any who is filling in error strings into lldb_private::Error objects the rules are: - short strings that don't start with a capitol letter unless the name is a class or anything else that is always capitolized - no trailing newline character - should be one line if possible Implemented a first pass at adding "--gdb-format" support to anything that accepts format with optional size/count. llvm-svn: 142999
2011-10-26 08:56:27 +08:00
m_infile.Clear();
error.SetErrorStringWithFormat("input file does not exist: '%s'",
Update OptionGroup::SetValue to take StringRef. Then deal with all the fallout. Differential Revision: https://reviews.llvm.org/D24847 llvm-svn: 282265
2016-09-24 01:48:13 +08:00
option_value.str().c_str());
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
Added new options to memory read to allow saving memory to disk as binary bytes or as an ASCII text dump. - The output file is specified with the "--outfile FILE" option. - The memory can be appended to an existing file using the "--append" option. - The memory will be written as an ASCII text dump by default, or as binary with the "--binary" option. Added new options to memory write to allow writing all or part of a file on disk to target memory: - The input file is specified using the "--infile FILE" option - The offset at which to start in the file defaults to zero, but can be overridden using the "--offset OFFSET" option. If the size is not specified, the remaining number of bytes in the file will be used as the default byte size. - The number of bytes to write defaults to the entire file byte size, but can be changed with the "--size COUNT" option. llvm-svn: 116172
2010-10-11 04:52:20 +08:00
break;
*** 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
Minor improvement to the "memory find" command Remove the --do-read option, and always provide a small dump of memory at each match spot Add a --dump-offset (-o) option, to specify a byte offset from which to start dumping relative to the matching address The real solution is to actually provide the format options found on "memory read" and use those as the key to actually printing memory upon each find That, however, requires a little refactoring work, so put this in for now until I get a chance to do the required shuffling around of moving parts llvm-svn: 194600
2013-11-14 04:08:30 +08:00
case 'o': {
Update OptionGroup::SetValue to take StringRef. Then deal with all the fallout. Differential Revision: https://reviews.llvm.org/D24847 llvm-svn: 282265
2016-09-24 01:48:13 +08:00
if (option_value.getAsInteger(0, m_infile_offset)) {
m_infile_offset = 0;
Cleaned up many error codes. For any who is filling in error strings into lldb_private::Error objects the rules are: - short strings that don't start with a capitol letter unless the name is a class or anything else that is always capitolized - no trailing newline character - should be one line if possible Implemented a first pass at adding "--gdb-format" support to anything that accepts format with optional size/count. llvm-svn: 142999
2011-10-26 08:56:27 +08:00
error.SetErrorStringWithFormat("invalid offset string '%s'",
Update OptionGroup::SetValue to take StringRef. Then deal with all the fallout. Differential Revision: https://reviews.llvm.org/D24847 llvm-svn: 282265
2016-09-24 01:48:13 +08:00
option_value.str().c_str());
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +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
} break;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
LLDB help content has accumulated over time without a recent attempt to review it for consistency, accuracy, and clarity. These changes attempt to address all of the above while keeping the text relatively terse. <rdar://problem/24868841> llvm-svn: 275485
2016-07-15 06:03:10 +08:00
default:
[lldb][NFC] Remove dead code that is supposed to handle invalid command options Summary: We currently have a bunch of code that is supposed to handle invalid command options, but all this code is unreachable because invalid options are already handled in `Options::Parse`. The only way we can reach this code is when we declare but then not implement an option (which will be made impossible with D65386, which is also when we can completely remove the `default` cases). This patch replaces all this code with `llvm_unreachable` to make clear this is dead code that can't be reached. Reviewers: JDevlieghere Reviewed By: JDevlieghere Subscribers: lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D66522 llvm-svn: 369625
2019-08-22 16:08:05 +08:00
llvm_unreachable("Unimplemented option");
*** 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
}
Modify existing commands with arguments to use the new argument mechanism (for standardized argument names, argument help, etc.) llvm-svn: 115570
2010-10-05 06:28:36 +08:00
return error;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
commands: Use override instead of virtual. Summary: This removes all uses of virtual on functions where override could be used, including on destructors. It also adds override where virtual was previously missing. Reviewers: clayborg, labath Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D13503 llvm-svn: 249564
2015-10-08 00:56:17 +08:00
void OptionParsingStarting(ExecutionContext *execution_context) override {
m_infile.Clear();
Updated all commands that use a "--format" / "-f" options to use the new OptionGroupFormat. Updated OptionGroupFormat to be able to also use the "--size" and "--count" options. Commands that use a OptionGroupFormat instance can choose which of the options they want by initializing OptionGroupFormat accordingly. Clients can either get only the "--format", "--format" + "--size", or "--format" + "--size" + "--count". This is in preparation for upcoming chnages where there are alternate ways (GDB format specification) to set a format. llvm-svn: 142911
2011-10-25 14:44:01 +08:00
m_infile_offset = 0;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
FileSpec m_infile;
off_t m_infile_offset;
};
CommandObjectMemoryWrite(CommandInterpreter &interpreter)
LLDB help content has accumulated over time without a recent attempt to review it for consistency, accuracy, and clarity. These changes attempt to address all of the above while keeping the text relatively terse. <rdar://problem/24868841> llvm-svn: 275485
2016-07-15 06:03:10 +08:00
: CommandObjectParsed(
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
interpreter, "memory write",
"Write to the memory of the current target process.", nullptr,
LLDB help content has accumulated over time without a recent attempt to review it for consistency, accuracy, and clarity. These changes attempt to address all of the above while keeping the text relatively terse. <rdar://problem/24868841> llvm-svn: 275485
2016-07-15 06:03:10 +08:00
eCommandRequiresProcess | eCommandProcessMustBeLaunched),
[Bug 49018][lldb] Fix incorrect help text for 'memory write' command Certain commands like 'memory write', 'register read' etc all use the OptionGroupFormat options but the help usage text for those options is not customized to those commands. One such example is: (lldb) help memory read -s <byte-size> ( --size <byte-size> ) The size in bytes to use when displaying with the selected format. (lldb) help memory write -s <byte-size> ( --size <byte-size> ) The size in bytes to use when displaying with the selected format. This patch allows such commands to overwrite the help text for the options in the OptionGroupFormat group as needed and fixes help text of memory write. llvm.org/pr49018. Reviewed By: DavidSpickett Differential Revision: https://reviews.llvm.org/D114448
2021-11-26 18:28:14 +08:00
m_format_options(
eFormatBytes, 1, UINT64_MAX,
{std::make_tuple(
eArgTypeFormat,
"The format to use for each of the value to be written."),
[Commands] Remove redundant member initialization (NFC) Identified with readability-redundant-member-init.
2022-01-24 03:07:14 +08:00
std::make_tuple(eArgTypeByteSize,
"The size in bytes to write from input file or "
"each value.")}) {
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
CommandArgumentEntry arg1;
Modify existing commands with arguments to use the new argument mechanism (for standardized argument names, argument help, etc.) llvm-svn: 115570
2010-10-05 06:28:36 +08:00
CommandArgumentEntry arg2;
CommandArgumentData addr_arg;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
CommandArgumentData value_arg;
Modify existing commands with arguments to use the new argument mechanism (for standardized argument names, argument help, etc.) llvm-svn: 115570
2010-10-05 06:28:36 +08:00
// Define the first (and only) variant of this arg.
addr_arg.arg_type = eArgTypeAddress;
addr_arg.arg_repetition = eArgRepeatPlain;
*** 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
Modify existing commands with arguments to use the new argument mechanism (for standardized argument names, argument help, etc.) llvm-svn: 115570
2010-10-05 06:28:36 +08:00
// There is only one variant this argument could be; put it into the
// argument entry.
arg1.push_back(addr_arg);
*** 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
Modify existing commands with arguments to use the new argument mechanism (for standardized argument names, argument help, etc.) llvm-svn: 115570
2010-10-05 06:28:36 +08:00
// Define the first (and only) variant of this arg.
value_arg.arg_type = eArgTypeValue;
Jim suggested to use eArgTypeAddressOrExpression for the addresses that 'memory find' takes llvm-svn: 243902
2015-08-04 04:47:19 +08:00
value_arg.arg_repetition = eArgRepeatPlus;
[lldb] Fix 'memory write' to not allow specifying values when writing file contents Currently the 'memory write' command allows specifying the values when writing the file contents to memory but the values are actually ignored. This patch fixes that by erroring out when values are specified in such cases. Reviewed By: DavidSpickett Differential Revision: https://reviews.llvm.org/D114544
2021-11-26 18:04:57 +08:00
value_arg.arg_opt_set_association = LLDB_OPT_SET_1;
*** 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
Modify existing commands with arguments to use the new argument mechanism (for standardized argument names, argument help, etc.) llvm-svn: 115570
2010-10-05 06:28:36 +08:00
// There is only one variant this argument could be; put it into the
// argument entry.
arg2.push_back(value_arg);
*** 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
Modify existing commands with arguments to use the new argument mechanism (for standardized argument names, argument help, etc.) llvm-svn: 115570
2010-10-05 06:28:36 +08:00
// Push the data for the first argument into the m_arguments vector.
m_arguments.push_back(arg1);
m_arguments.push_back(arg2);
*** 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
Updated all commands that use a "--format" / "-f" options to use the new OptionGroupFormat. Updated OptionGroupFormat to be able to also use the "--size" and "--count" options. Commands that use a OptionGroupFormat instance can choose which of the options they want by initializing OptionGroupFormat accordingly. Clients can either get only the "--format", "--format" + "--size", or "--format" + "--size" + "--count". This is in preparation for upcoming chnages where there are alternate ways (GDB format specification) to set a format. llvm-svn: 142911
2011-10-25 14:44:01 +08:00
m_option_group.Append(&m_format_options,
OptionGroupFormat::OPTION_GROUP_FORMAT,
LLDB_OPT_SET_1);
m_option_group.Append(&m_format_options,
OptionGroupFormat::OPTION_GROUP_SIZE,
LLDB_OPT_SET_1 | LLDB_OPT_SET_2);
m_option_group.Append(&m_memory_options, LLDB_OPT_SET_ALL, LLDB_OPT_SET_2);
m_option_group.Finalize();
*** 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
}
Fix Clang-tidy modernize-use-nullptr and modernize-use-default warnings in some files in source/Commands; other minor fixes. llvm-svn: 261389
2016-02-20 08:58:29 +08:00
~CommandObjectMemoryWrite() override = default;
*** 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
Updated all commands that use a "--format" / "-f" options to use the new OptionGroupFormat. Updated OptionGroupFormat to be able to also use the "--size" and "--count" options. Commands that use a OptionGroupFormat instance can choose which of the options they want by initializing OptionGroupFormat accordingly. Clients can either get only the "--format", "--format" + "--size", or "--format" + "--size" + "--count". This is in preparation for upcoming chnages where there are alternate ways (GDB format specification) to set a format. llvm-svn: 142911
2011-10-25 14:44:01 +08:00
Options *GetOptions() override { return &m_option_group; }
*** 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
Make raw & parsed commands subclasses of CommandObject rather than having the raw version implement an Execute which was never going to get run and another ExecuteRawCommandString. Took the knowledge of how to prepare raw & parsed commands out of CommandInterpreter and put it in CommandObject where it belongs. Also took all the cases where there were the subcommands of Multiword commands declared in the .h file for the overall command and moved them into the .cpp file. Made the CommandObject flags work for raw as well as parsed commands. Made "expr" use the flags so that it requires you to be paused to run "expr". llvm-svn: 158235
2012-06-09 05:56:10 +08:00
protected:
Since our expression parser needs to locate areas of memory that are not in use when you have a process that can't JIT code, like core file debugging, the core file process plug-ins should be able to override the Process::GetMemoryRegionInfo(...) function. In order to make this happen, I have added permissions to sections so that we can know what the permissions are for a given section, and modified both core file plug-ins to override Process::GetMemoryRegionInfo() and answer things correctly. llvm-svn: 272276
2016-06-10 00:34:06 +08:00
bool DoExecute(Args &command, CommandReturnObject &result) override {
Add support for custom commands to set flags on themselves This works for Python commands defined via a class (implement get_flags on your class) and C++ plugin commands (which can call SBCommand::GetFlags()/SetFlags()) Flags allow features such as not letting the command run if there's no target, or if the process is not stopped, ... Commands could always check for these things themselves, but having these accessible via flags makes custom commands more consistent with built-in ones llvm-svn: 238286
2015-05-27 13:04:35 +08:00
// No need to check "process" for validity as eCommandRequiresProcess
// ensures it is valid
Expanded the flags that can be set for a command object in lldb_private::CommandObject. This list of available flags are: enum { //---------------------------------------------------------------------- // eFlagRequiresTarget // // Ensures a valid target is contained in m_exe_ctx prior to executing // the command. If a target doesn't exist or is invalid, the command // will fail and CommandObject::GetInvalidTargetDescription() will be // returned as the error. CommandObject subclasses can override the // virtual function for GetInvalidTargetDescription() to provide custom // strings when needed. //---------------------------------------------------------------------- eFlagRequiresTarget = (1u << 0), //---------------------------------------------------------------------- // eFlagRequiresProcess // // Ensures a valid process is contained in m_exe_ctx prior to executing // the command. If a process doesn't exist or is invalid, the command // will fail and CommandObject::GetInvalidProcessDescription() will be // returned as the error. CommandObject subclasses can override the // virtual function for GetInvalidProcessDescription() to provide custom // strings when needed. //---------------------------------------------------------------------- eFlagRequiresProcess = (1u << 1), //---------------------------------------------------------------------- // eFlagRequiresThread // // Ensures a valid thread is contained in m_exe_ctx prior to executing // the command. If a thread doesn't exist or is invalid, the command // will fail and CommandObject::GetInvalidThreadDescription() will be // returned as the error. CommandObject subclasses can override the // virtual function for GetInvalidThreadDescription() to provide custom // strings when needed. //---------------------------------------------------------------------- eFlagRequiresThread = (1u << 2), //---------------------------------------------------------------------- // eFlagRequiresFrame // // Ensures a valid frame is contained in m_exe_ctx prior to executing // the command. If a frame doesn't exist or is invalid, the command // will fail and CommandObject::GetInvalidFrameDescription() will be // returned as the error. CommandObject subclasses can override the // virtual function for GetInvalidFrameDescription() to provide custom // strings when needed. //---------------------------------------------------------------------- eFlagRequiresFrame = (1u << 3), //---------------------------------------------------------------------- // eFlagRequiresRegContext // // Ensures a valid register context (from the selected frame if there // is a frame in m_exe_ctx, or from the selected thread from m_exe_ctx) // is availble from m_exe_ctx prior to executing the command. If a // target doesn't exist or is invalid, the command will fail and // CommandObject::GetInvalidRegContextDescription() will be returned as // the error. CommandObject subclasses can override the virtual function // for GetInvalidRegContextDescription() to provide custom strings when // needed. //---------------------------------------------------------------------- eFlagRequiresRegContext = (1u << 4), //---------------------------------------------------------------------- // eFlagTryTargetAPILock // // Attempts to acquire the target lock if a target is selected in the // command interpreter. If the command object fails to acquire the API // lock, the command will fail with an appropriate error message. //---------------------------------------------------------------------- eFlagTryTargetAPILock = (1u << 5), //---------------------------------------------------------------------- // eFlagProcessMustBeLaunched // // Verifies that there is a launched process in m_exe_ctx, if there // isn't, the command will fail with an appropriate error message. //---------------------------------------------------------------------- eFlagProcessMustBeLaunched = (1u << 6), //---------------------------------------------------------------------- // eFlagProcessMustBePaused // // Verifies that there is a paused process in m_exe_ctx, if there // isn't, the command will fail with an appropriate error message. //---------------------------------------------------------------------- eFlagProcessMustBePaused = (1u << 7) }; Now each command object contains a "ExecutionContext m_exe_ctx;" member variable that gets initialized prior to running the command. The validity of the target objects in m_exe_ctx are checked to ensure that any target/process/thread/frame/reg context that are required are valid prior to executing the command. Each command object also contains a Mutex::Locker m_api_locker which gets used if eFlagTryTargetAPILock is set. This centralizes a lot of checking code that was previously and inconsistently implemented across many commands. llvm-svn: 171990
2013-01-10 03:44:40 +08:00
Process *process = m_exe_ctx.GetProcessPtr();
*** 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
const size_t argc = command.GetArgumentCount();
*** 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
Updated all commands that use a "--format" / "-f" options to use the new OptionGroupFormat. Updated OptionGroupFormat to be able to also use the "--size" and "--count" options. Commands that use a OptionGroupFormat instance can choose which of the options they want by initializing OptionGroupFormat accordingly. Clients can either get only the "--format", "--format" + "--size", or "--format" + "--size" + "--count". This is in preparation for upcoming chnages where there are alternate ways (GDB format specification) to set a format. llvm-svn: 142911
2011-10-25 14:44:01 +08:00
if (m_memory_options.m_infile) {
Added new options to memory read to allow saving memory to disk as binary bytes or as an ASCII text dump. - The output file is specified with the "--outfile FILE" option. - The memory can be appended to an existing file using the "--append" option. - The memory will be written as an ASCII text dump by default, or as binary with the "--binary" option. Added new options to memory write to allow writing all or part of a file on disk to target memory: - The input file is specified using the "--infile FILE" option - The offset at which to start in the file defaults to zero, but can be overridden using the "--offset OFFSET" option. If the size is not specified, the remaining number of bytes in the file will be used as the default byte size. - The number of bytes to write defaults to the entire file byte size, but can be changed with the "--size COUNT" option. llvm-svn: 116172
2010-10-11 04:52:20 +08:00
if (argc < 1) {
"size_t" isn't always 64 bit, it is 32 bit on 32 bit systems. All printf style statements that were assuming size_t were 64 bit were changed, and they were also changed to display them as unsigned values as "size_t" isn't signed. If you print anything with 'size_t', please cast it to "uint64_t" in the printf and use PRIu64 or PRIx64. llvm-svn: 202738
2014-03-04 03:15:20 +08:00
result.AppendErrorWithFormat(
Added new options to memory read to allow saving memory to disk as binary bytes or as an ASCII text dump. - The output file is specified with the "--outfile FILE" option. - The memory can be appended to an existing file using the "--append" option. - The memory will be written as an ASCII text dump by default, or as binary with the "--binary" option. Added new options to memory write to allow writing all or part of a file on disk to target memory: - The input file is specified using the "--infile FILE" option - The offset at which to start in the file defaults to zero, but can be overridden using the "--offset OFFSET" option. If the size is not specified, the remaining number of bytes in the file will be used as the default byte size. - The number of bytes to write defaults to the entire file byte size, but can be changed with the "--size COUNT" option. llvm-svn: 116172
2010-10-11 04:52:20 +08:00
"%s takes a destination address when writing file contents.\n",
m_cmd_name.c_str());
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
return false;
*** 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
}
[lldb] Fix 'memory write' to not allow specifying values when writing file contents Currently the 'memory write' command allows specifying the values when writing the file contents to memory but the values are actually ignored. This patch fixes that by erroring out when values are specified in such cases. Reviewed By: DavidSpickett Differential Revision: https://reviews.llvm.org/D114544
2021-11-26 18:04:57 +08:00
if (argc > 1) {
result.AppendErrorWithFormat(
"%s takes only a destination address when writing file contents.\n",
m_cmd_name.c_str());
return false;
}
Added new options to memory read to allow saving memory to disk as binary bytes or as an ASCII text dump. - The output file is specified with the "--outfile FILE" option. - The memory can be appended to an existing file using the "--append" option. - The memory will be written as an ASCII text dump by default, or as binary with the "--binary" option. Added new options to memory write to allow writing all or part of a file on disk to target memory: - The input file is specified using the "--infile FILE" option - The offset at which to start in the file defaults to zero, but can be overridden using the "--offset OFFSET" option. If the size is not specified, the remaining number of bytes in the file will be used as the default byte size. - The number of bytes to write defaults to the entire file byte size, but can be changed with the "--size COUNT" option. llvm-svn: 116172
2010-10-11 04:52:20 +08:00
} else if (argc < 2) {
"size_t" isn't always 64 bit, it is 32 bit on 32 bit systems. All printf style statements that were assuming size_t were 64 bit were changed, and they were also changed to display them as unsigned values as "size_t" isn't signed. If you print anything with 'size_t', please cast it to "uint64_t" in the printf and use PRIu64 or PRIx64. llvm-svn: 202738
2014-03-04 03:15:20 +08:00
result.AppendErrorWithFormat(
Added new options to memory read to allow saving memory to disk as binary bytes or as an ASCII text dump. - The output file is specified with the "--outfile FILE" option. - The memory can be appended to an existing file using the "--append" option. - The memory will be written as an ASCII text dump by default, or as binary with the "--binary" option. Added new options to memory write to allow writing all or part of a file on disk to target memory: - The input file is specified using the "--infile FILE" option - The offset at which to start in the file defaults to zero, but can be overridden using the "--offset OFFSET" option. If the size is not specified, the remaining number of bytes in the file will be used as the default byte size. - The number of bytes to write defaults to the entire file byte size, but can be changed with the "--size COUNT" option. llvm-svn: 116172
2010-10-11 04:52:20 +08:00
"%s takes a destination address and at least one value.\n",
m_cmd_name.c_str());
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
return false;
}
StreamString buffer(
Stream::eBinary,
process->GetTarget().GetArchitecture().GetAddressByteSize(),
process->GetTarget().GetArchitecture().GetByteOrder());
Updated all commands that use a "--format" / "-f" options to use the new OptionGroupFormat. Updated OptionGroupFormat to be able to also use the "--size" and "--count" options. Commands that use a OptionGroupFormat instance can choose which of the options they want by initializing OptionGroupFormat accordingly. Clients can either get only the "--format", "--format" + "--size", or "--format" + "--size" + "--count". This is in preparation for upcoming chnages where there are alternate ways (GDB format specification) to set a format. llvm-svn: 142911
2011-10-25 14:44:01 +08:00
OptionValueUInt64 &byte_size_value = m_format_options.GetByteSizeValue();
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
size_t item_byte_size = byte_size_value.GetCurrentValue();
*** 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
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;
Move Args::StringTo*** functions to a new OptionArgParser class Summary: The idea behind this is to move the functionality which depend on other lldb classes into a separate class. This way, the Args class can be turned into a lightweight arc+argv wrapper and moved into the lower lldb layers. Reviewers: jingham, zturner Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D44306 llvm-svn: 329677
2018-04-10 17:03:59 +08:00
lldb::addr_t addr = OptionArgParser::ToAddress(
[lldb][NFC] Remove ArgEntry::ref member The StringRef should always be identical to the C string, so we might as well just create the StringRef from the C-string. This might be slightly slower until we implement the storage of ArgEntry with a string instead of a std::unique_ptr<char[]>. Until then we have to do the additional strlen on the C string to construct the StringRef. llvm-svn: 371842
2019-09-13 19:26:48 +08:00
&m_exe_ctx, command[0].ref(), LLDB_INVALID_ADDRESS, &error);
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
if (addr == LLDB_INVALID_ADDRESS) {
result.AppendError("invalid address expression\n");
result.AppendError(error.AsCString());
return false;
}
Updated all commands that use a "--format" / "-f" options to use the new OptionGroupFormat. Updated OptionGroupFormat to be able to also use the "--size" and "--count" options. Commands that use a OptionGroupFormat instance can choose which of the options they want by initializing OptionGroupFormat accordingly. Clients can either get only the "--format", "--format" + "--size", or "--format" + "--size" + "--count". This is in preparation for upcoming chnages where there are alternate ways (GDB format specification) to set a format. llvm-svn: 142911
2011-10-25 14:44:01 +08:00
if (m_memory_options.m_infile) {
Added new options to memory read to allow saving memory to disk as binary bytes or as an ASCII text dump. - The output file is specified with the "--outfile FILE" option. - The memory can be appended to an existing file using the "--append" option. - The memory will be written as an ASCII text dump by default, or as binary with the "--binary" option. Added new options to memory write to allow writing all or part of a file on disk to target memory: - The input file is specified using the "--infile FILE" option - The offset at which to start in the file defaults to zero, but can be overridden using the "--offset OFFSET" option. If the size is not specified, the remaining number of bytes in the file will be used as the default byte size. - The number of bytes to write defaults to the entire file byte size, but can be changed with the "--size COUNT" option. llvm-svn: 116172
2010-10-11 04:52:20 +08:00
size_t length = SIZE_MAX;
if (item_byte_size > 1)
Updated all commands that use a "--format" / "-f" options to use the new OptionGroupFormat. Updated OptionGroupFormat to be able to also use the "--size" and "--count" options. Commands that use a OptionGroupFormat instance can choose which of the options they want by initializing OptionGroupFormat accordingly. Clients can either get only the "--format", "--format" + "--size", or "--format" + "--size" + "--count". This is in preparation for upcoming chnages where there are alternate ways (GDB format specification) to set a format. llvm-svn: 142911
2011-10-25 14:44:01 +08:00
length = item_byte_size;
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
auto data_sp = FileSystem::Instance().CreateDataBuffer(
Remove FileSpec::ReadFileContents. This functionality is subsumed by DataBufferLLVM, which is also more efficient since it will try to mmap. However, we don't yet support mmaping writable private sections, and in some cases we were using ReadFileContents and then modifying the buffer. To address that I've added a flag to the DataBufferLLVM methods that allow you to map privately, which disables the mmaping path entirely. Eventually we should teach DataBufferLLVM to use mmap with writable private, but that is orthogonal to this effort. Differential Revision: https://reviews.llvm.org/D30622 llvm-svn: 297095
2017-03-07 07:42:14 +08:00
m_memory_options.m_infile.GetPath(), length,
m_memory_options.m_infile_offset);
Added new options to memory read to allow saving memory to disk as binary bytes or as an ASCII text dump. - The output file is specified with the "--outfile FILE" option. - The memory can be appended to an existing file using the "--append" option. - The memory will be written as an ASCII text dump by default, or as binary with the "--binary" option. Added new options to memory write to allow writing all or part of a file on disk to target memory: - The input file is specified using the "--infile FILE" option - The offset at which to start in the file defaults to zero, but can be overridden using the "--offset OFFSET" option. If the size is not specified, the remaining number of bytes in the file will be used as the default byte size. - The number of bytes to write defaults to the entire file byte size, but can be changed with the "--size COUNT" option. llvm-svn: 116172
2010-10-11 04:52:20 +08:00
if (data_sp) {
length = data_sp->GetByteSize();
if (length > 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;
Added new options to memory read to allow saving memory to disk as binary bytes or as an ASCII text dump. - The output file is specified with the "--outfile FILE" option. - The memory can be appended to an existing file using the "--append" option. - The memory will be written as an ASCII text dump by default, or as binary with the "--binary" option. Added new options to memory write to allow writing all or part of a file on disk to target memory: - The input file is specified using the "--infile FILE" option - The offset at which to start in the file defaults to zero, but can be overridden using the "--offset OFFSET" option. If the size is not specified, the remaining number of bytes in the file will be used as the default byte size. - The number of bytes to write defaults to the entire file byte size, but can be changed with the "--size COUNT" option. llvm-svn: 116172
2010-10-11 04:52:20 +08:00
size_t bytes_written =
process->WriteMemory(addr, data_sp->GetBytes(), length, error);
*** 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 new options to memory read to allow saving memory to disk as binary bytes or as an ASCII text dump. - The output file is specified with the "--outfile FILE" option. - The memory can be appended to an existing file using the "--append" option. - The memory will be written as an ASCII text dump by default, or as binary with the "--binary" option. Added new options to memory write to allow writing all or part of a file on disk to target memory: - The input file is specified using the "--infile FILE" option - The offset at which to start in the file defaults to zero, but can be overridden using the "--offset OFFSET" option. If the size is not specified, the remaining number of bytes in the file will be used as the default byte size. - The number of bytes to write defaults to the entire file byte size, but can be changed with the "--size COUNT" option. llvm-svn: 116172
2010-10-11 04:52:20 +08:00
if (bytes_written == length) {
// All bytes written
result.GetOutputStream().Printf(
"%" PRIu64 " bytes were written to 0x%" PRIx64 "\n",
(uint64_t)bytes_written, addr);
result.SetStatus(eReturnStatusSuccessFinishResult);
} else if (bytes_written > 0) {
// Some byte written
result.GetOutputStream().Printf(
"%" PRIu64 " bytes of %" PRIu64
" requested were written to 0x%" PRIx64 "\n",
(uint64_t)bytes_written, (uint64_t)length, addr);
result.SetStatus(eReturnStatusSuccessFinishResult);
*** 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 {
Added new options to memory read to allow saving memory to disk as binary bytes or as an ASCII text dump. - The output file is specified with the "--outfile FILE" option. - The memory can be appended to an existing file using the "--append" option. - The memory will be written as an ASCII text dump by default, or as binary with the "--binary" option. Added new options to memory write to allow writing all or part of a file on disk to target memory: - The input file is specified using the "--infile FILE" option - The offset at which to start in the file defaults to zero, but can be overridden using the "--offset OFFSET" option. If the size is not specified, the remaining number of bytes in the file will be used as the default byte size. - The number of bytes to write defaults to the entire file byte size, but can be changed with the "--size COUNT" option. llvm-svn: 116172
2010-10-11 04:52:20 +08:00
result.AppendErrorWithFormat("Memory write to 0x%" PRIx64
" failed: %s.\n",
addr, error.AsCString());
*** 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
}
*** 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 {
Added new options to memory read to allow saving memory to disk as binary bytes or as an ASCII text dump. - The output file is specified with the "--outfile FILE" option. - The memory can be appended to an existing file using the "--append" option. - The memory will be written as an ASCII text dump by default, or as binary with the "--binary" option. Added new options to memory write to allow writing all or part of a file on disk to target memory: - The input file is specified using the "--infile FILE" option - The offset at which to start in the file defaults to zero, but can be overridden using the "--offset OFFSET" option. If the size is not specified, the remaining number of bytes in the file will be used as the default byte size. - The number of bytes to write defaults to the entire file byte size, but can be changed with the "--size COUNT" option. llvm-svn: 116172
2010-10-11 04:52:20 +08:00
result.AppendErrorWithFormat("Unable to read contents of file.\n");
*** 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 new options to memory read to allow saving memory to disk as binary bytes or as an ASCII text dump. - The output file is specified with the "--outfile FILE" option. - The memory can be appended to an existing file using the "--append" option. - The memory will be written as an ASCII text dump by default, or as binary with the "--binary" option. Added new options to memory write to allow writing all or part of a file on disk to target memory: - The input file is specified using the "--infile FILE" option - The offset at which to start in the file defaults to zero, but can be overridden using the "--offset OFFSET" option. If the size is not specified, the remaining number of bytes in the file will be used as the default byte size. - The number of bytes to write defaults to the entire file byte size, but can be changed with the "--size COUNT" option. llvm-svn: 116172
2010-10-11 04:52:20 +08:00
return result.Succeeded();
Updated all commands that use a "--format" / "-f" options to use the new OptionGroupFormat. Updated OptionGroupFormat to be able to also use the "--size" and "--count" options. Commands that use a OptionGroupFormat instance can choose which of the options they want by initializing OptionGroupFormat accordingly. Clients can either get only the "--format", "--format" + "--size", or "--format" + "--size" + "--count". This is in preparation for upcoming chnages where there are alternate ways (GDB format specification) to set a format. llvm-svn: 142911
2011-10-25 14:44:01 +08:00
} else if (item_byte_size == 0) {
if (m_format_options.GetFormat() == eFormatPointer)
Added new options to memory read to allow saving memory to disk as binary bytes or as an ASCII text dump. - The output file is specified with the "--outfile FILE" option. - The memory can be appended to an existing file using the "--append" option. - The memory will be written as an ASCII text dump by default, or as binary with the "--binary" option. Added new options to memory write to allow writing all or part of a file on disk to target memory: - The input file is specified using the "--infile FILE" option - The offset at which to start in the file defaults to zero, but can be overridden using the "--offset OFFSET" option. If the size is not specified, the remaining number of bytes in the file will be used as the default byte size. - The number of bytes to write defaults to the entire file byte size, but can be changed with the "--size COUNT" option. llvm-svn: 116172
2010-10-11 04:52:20 +08:00
item_byte_size = buffer.GetAddressByteSize();
*** 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
Added new options to memory read to allow saving memory to disk as binary bytes or as an ASCII text dump. - The output file is specified with the "--outfile FILE" option. - The memory can be appended to an existing file using the "--append" option. - The memory will be written as an ASCII text dump by default, or as binary with the "--binary" option. Added new options to memory write to allow writing all or part of a file on disk to target memory: - The input file is specified using the "--infile FILE" option - The offset at which to start in the file defaults to zero, but can be overridden using the "--offset OFFSET" option. If the size is not specified, the remaining number of bytes in the file will be used as the default byte size. - The number of bytes to write defaults to the entire file byte size, but can be changed with the "--size COUNT" option. llvm-svn: 116172
2010-10-11 04:52:20 +08:00
item_byte_size = 1;
*** 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
Made lldb_private::ArchSpec contain much more than just an architecture. It now, in addition to cpu type/subtype and architecture flavor, contains: - byte order (big endian, little endian) - address size in bytes - llvm::Triple for true target triple support and for more powerful plug-in selection. llvm-svn: 125602
2011-02-16 05:59:32 +08:00
command.Shift(); // shift off the address argument
Updated all commands that use a "--format" / "-f" options to use the new OptionGroupFormat. Updated OptionGroupFormat to be able to also use the "--size" and "--count" options. Commands that use a OptionGroupFormat instance can choose which of the options they want by initializing OptionGroupFormat accordingly. Clients can either get only the "--format", "--format" + "--size", or "--format" + "--size" + "--count". This is in preparation for upcoming chnages where there are alternate ways (GDB format specification) to set a format. llvm-svn: 142911
2011-10-25 14:44:01 +08:00
uint64_t uval64;
int64_t sval64;
bool success = false;
Modernize the Args access pattern in a few more commands. llvm-svn: 289164
2016-12-09 09:08:29 +08:00
for (auto &entry : command) {
Updated all commands that use a "--format" / "-f" options to use the new OptionGroupFormat. Updated OptionGroupFormat to be able to also use the "--size" and "--count" options. Commands that use a OptionGroupFormat instance can choose which of the options they want by initializing OptionGroupFormat accordingly. Clients can either get only the "--format", "--format" + "--size", or "--format" + "--size" + "--count". This is in preparation for upcoming chnages where there are alternate ways (GDB format specification) to set a format. llvm-svn: 142911
2011-10-25 14:44:01 +08:00
switch (m_format_options.GetFormat()) {
Centralized all of the format to c-string and to format character code inside the FormatManager class. Modified the format arguments in any commands to be able to use a single character format, or a full format name, or a partial format name if no full format names match. Modified any code that was displaying formats to use the new FormatManager calls so that our help text and errors never get out of date. Modified the display of the "type format list" command to be a bit more human readable by showing the format as a format string rather than the single character format char. llvm-svn: 133765
2011-06-24 05:22:24 +08:00
case kNumFormats:
<rdar://problem/12820334> I modified the "Args::StringtoAddress(...)" function to be able to evaluate address expressions. This is now used for any command line arguments or options that takes addresses like: memory read <addr> [<end-addr>] memory write <addr> breakpoint set --address <addr> disassemble --start-address <addr> --end-address <addr> It calls the expression parser to evaluate the address expression and will also work around the issue where the compiler doesn't like to add offsets to function pointers (which is what happens when you try to evaluate "main + 12"). So there is a temp fix in the Args::StringtoAddress() to work around this until we can get special compiler support for debug expressions with function pointers. llvm-svn: 169556
2012-12-07 06:49:16 +08:00
case eFormatFloat: // TODO: add support for floats soon
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
case eFormatCharPrintable:
<rdar://problem/12820334> I modified the "Args::StringtoAddress(...)" function to be able to evaluate address expressions. This is now used for any command line arguments or options that takes addresses like: memory read <addr> [<end-addr>] memory write <addr> breakpoint set --address <addr> disassemble --start-address <addr> --end-address <addr> It calls the expression parser to evaluate the address expression and will also work around the issue where the compiler doesn't like to add offsets to function pointers (which is what happens when you try to evaluate "main + 12"). So there is a temp fix in the Args::StringtoAddress() to work around this until we can get special compiler support for debug expressions with function pointers. llvm-svn: 169556
2012-12-07 06:49:16 +08:00
case eFormatBytesWithASCII:
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
case eFormatComplex:
case eFormatEnum:
Add char8_t support (C++20) This patch adds support for the char8_t type introduced in C++20 char8_t. The original patch was submitted by James Blachly on the LLDB mailing list [1]. I modified the patch a bit and added a test. [1] http://lists.llvm.org/pipermail/lldb-dev/2019-August/015393.html Differential revision: https://reviews.llvm.org/D66447 llvm-svn: 369582
2019-08-22 05:30:55 +08:00
case eFormatUnicode8:
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
case eFormatUnicode16:
case eFormatUnicode32:
case eFormatVectorOfChar:
case eFormatVectorOfSInt8:
case eFormatVectorOfUInt8:
case eFormatVectorOfSInt16:
case eFormatVectorOfUInt16:
case eFormatVectorOfSInt32:
case eFormatVectorOfUInt32:
case eFormatVectorOfSInt64:
<rdar://problem/12820334> I modified the "Args::StringtoAddress(...)" function to be able to evaluate address expressions. This is now used for any command line arguments or options that takes addresses like: memory read <addr> [<end-addr>] memory write <addr> breakpoint set --address <addr> disassemble --start-address <addr> --end-address <addr> It calls the expression parser to evaluate the address expression and will also work around the issue where the compiler doesn't like to add offsets to function pointers (which is what happens when you try to evaluate "main + 12"). So there is a temp fix in the Args::StringtoAddress() to work around this until we can get special compiler support for debug expressions with function pointers. llvm-svn: 169556
2012-12-07 06:49:16 +08:00
case eFormatVectorOfUInt64:
case eFormatVectorOfFloat16:
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
case eFormatVectorOfFloat32:
case eFormatVectorOfFloat64:
case eFormatVectorOfUInt128:
Split all of the core of LLDB.framework/lldb.so into a static archive that can be linked against. LLDB.framework/lldb.so exports a very controlled API. Splitting the API into a static library allows other tools (debugserver for now) to use the power of the LLDB debugger core, yet not export it as its API is not portable or maintainable. The Host layer and many of the other internal only APIs can now be statically linked against. Now LLDB.framework/lldb.so links against "liblldb-core.a" instead of compiling the .o files only for the shared library. This fix is only for compiling with Xcode as the Makefile based build already does this. The Xcode projecdt compiler has been changed to LLVM. Anyone using Xcode 3 will need to manually change the compiler back to GCC 4.2, or update to Xcode 4. llvm-svn: 127963
2011-03-20 12:57:14 +08:00
case eFormatOSType:
<rdar://problem/12820334> I modified the "Args::StringtoAddress(...)" function to be able to evaluate address expressions. This is now used for any command line arguments or options that takes addresses like: memory read <addr> [<end-addr>] memory write <addr> breakpoint set --address <addr> disassemble --start-address <addr> --end-address <addr> It calls the expression parser to evaluate the address expression and will also work around the issue where the compiler doesn't like to add offsets to function pointers (which is what happens when you try to evaluate "main + 12"). So there is a temp fix in the Args::StringtoAddress() to work around this until we can get special compiler support for debug expressions with function pointers. llvm-svn: 169556
2012-12-07 06:49:16 +08:00
case eFormatComplexInteger:
case eFormatAddressInfo:
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 eFormatHexFloat:
<rdar://problem/12820334> I modified the "Args::StringtoAddress(...)" function to be able to evaluate address expressions. This is now used for any command line arguments or options that takes addresses like: memory read <addr> [<end-addr>] memory write <addr> breakpoint set --address <addr> disassemble --start-address <addr> --end-address <addr> It calls the expression parser to evaluate the address expression and will also work around the issue where the compiler doesn't like to add offsets to function pointers (which is what happens when you try to evaluate "main + 12"). So there is a temp fix in the Args::StringtoAddress() to work around this until we can get special compiler support for debug expressions with function pointers. llvm-svn: 169556
2012-12-07 06:49:16 +08:00
case eFormatInstruction:
case eFormatVoid:
result.AppendError("unsupported format for writing memory");
Added new options to memory read to allow saving memory to disk as binary bytes or as an ASCII text dump. - The output file is specified with the "--outfile FILE" option. - The memory can be appended to an existing file using the "--append" option. - The memory will be written as an ASCII text dump by default, or as binary with the "--binary" option. Added new options to memory write to allow writing all or part of a file on disk to target memory: - The input file is specified using the "--infile FILE" option - The offset at which to start in the file defaults to zero, but can be overridden using the "--offset OFFSET" option. If the size is not specified, the remaining number of bytes in the file will be used as the default byte size. - The number of bytes to write defaults to the entire file byte size, but can be changed with the "--size COUNT" option. llvm-svn: 116172
2010-10-11 04:52:20 +08:00
return false;
*** 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
case eFormatDefault:
case eFormatBytes:
case eFormatHex:
<rdar://problem/10449092> Adding a new uppercase hex format specifier. This commit also changes the short names for formats so that uppercase hex can be 'X', which was previously assigned to hex float. hex float now has no short name. llvm-svn: 161606
2012-08-10 03:33:34 +08:00
case eFormatHexUppercase:
Run clang-format on lldb/source/Commands (NFC) These files had a lot of whitespace errors in them which was a constant source of merge conflicts downstream.
2019-10-31 06:26:19 +08:00
case eFormatPointer: {
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
// Decode hex bytes
getAsInteger is not a equivalent replacement for strtol work around that fact for CommandObjectMemoryWrite. <rdar://problem/31457148> llvm-svn: 299609
2017-04-06 09:33:38 +08:00
// Be careful, getAsInteger with a radix of 16 rejects "0xab" so we
// have to special case that:
bool success = false;
[lldb][NFC] Remove ArgEntry::ref member The StringRef should always be identical to the C string, so we might as well just create the StringRef from the C-string. This might be slightly slower until we implement the storage of ArgEntry with a string instead of a std::unique_ptr<char[]>. Until then we have to do the additional strlen on the C string to construct the StringRef. llvm-svn: 371842
2019-09-13 19:26:48 +08:00
if (entry.ref().startswith("0x"))
success = !entry.ref().getAsInteger(0, uval64);
getAsInteger is not a equivalent replacement for strtol work around that fact for CommandObjectMemoryWrite. <rdar://problem/31457148> llvm-svn: 299609
2017-04-06 09:33:38 +08:00
if (!success)
[lldb][NFC] Remove ArgEntry::ref member The StringRef should always be identical to the C string, so we might as well just create the StringRef from the C-string. This might be slightly slower until we implement the storage of ArgEntry with a string instead of a std::unique_ptr<char[]>. Until then we have to do the additional strlen on the C string to construct the StringRef. llvm-svn: 371842
2019-09-13 19:26:48 +08:00
success = !entry.ref().getAsInteger(16, uval64);
getAsInteger is not a equivalent replacement for strtol work around that fact for CommandObjectMemoryWrite. <rdar://problem/31457148> llvm-svn: 299609
2017-04-06 09:33:38 +08:00
if (!success) {
"size_t" isn't always 64 bit, it is 32 bit on 32 bit systems. All printf style statements that were assuming size_t were 64 bit were changed, and they were also changed to display them as unsigned values as "size_t" isn't signed. If you print anything with 'size_t', please cast it to "uint64_t" in the printf and use PRIu64 or PRIx64. llvm-svn: 202738
2014-03-04 03:15:20 +08:00
result.AppendErrorWithFormat(
Modernize the Args access pattern in a few more commands. llvm-svn: 289164
2016-12-09 09:08:29 +08:00
"'%s' is not a valid hex string value.\n", entry.c_str());
Added new options to memory read to allow saving memory to disk as binary bytes or as an ASCII text dump. - The output file is specified with the "--outfile FILE" option. - The memory can be appended to an existing file using the "--append" option. - The memory will be written as an ASCII text dump by default, or as binary with the "--binary" option. Added new options to memory write to allow writing all or part of a file on disk to target memory: - The input file is specified using the "--infile FILE" option - The offset at which to start in the file defaults to zero, but can be overridden using the "--offset OFFSET" option. If the size is not specified, the remaining number of bytes in the file will be used as the default byte size. - The number of bytes to write defaults to the entire file byte size, but can be changed with the "--size COUNT" option. llvm-svn: 116172
2010-10-11 04:52:20 +08:00
return false;
[lldb] Remove [US]IntValueIsValidForSize from CommandObjectMemory Use llvm::is(U)IntN (MathExtras.h) instead.
2020-11-04 23:25:38 +08:00
} else if (!llvm::isUIntN(item_byte_size * 8, uval64)) {
<rdar://problem/12820334> I modified the "Args::StringtoAddress(...)" function to be able to evaluate address expressions. This is now used for any command line arguments or options that takes addresses like: memory read <addr> [<end-addr>] memory write <addr> breakpoint set --address <addr> disassemble --start-address <addr> --end-address <addr> It calls the expression parser to evaluate the address expression and will also work around the issue where the compiler doesn't like to add offsets to function pointers (which is what happens when you try to evaluate "main + 12"). So there is a temp fix in the Args::StringtoAddress() to work around this until we can get special compiler support for debug expressions with function pointers. llvm-svn: 169556
2012-12-07 06:49:16 +08:00
result.AppendErrorWithFormat("Value 0x%" PRIx64
"size_t" isn't always 64 bit, it is 32 bit on 32 bit systems. All printf style statements that were assuming size_t were 64 bit were changed, and they were also changed to display them as unsigned values as "size_t" isn't signed. If you print anything with 'size_t', please cast it to "uint64_t" in the printf and use PRIu64 or PRIx64. llvm-svn: 202738
2014-03-04 03:15:20 +08:00
" is too large to fit in a %" PRIu64
" byte unsigned integer value.\n",
uval64, (uint64_t)item_byte_size);
Added new options to memory read to allow saving memory to disk as binary bytes or as an ASCII text dump. - The output file is specified with the "--outfile FILE" option. - The memory can be appended to an existing file using the "--append" option. - The memory will be written as an ASCII text dump by default, or as binary with the "--binary" option. Added new options to memory write to allow writing all or part of a file on disk to target memory: - The input file is specified using the "--infile FILE" option - The offset at which to start in the file defaults to zero, but can be overridden using the "--offset OFFSET" option. If the size is not specified, the remaining number of bytes in the file will be used as the default byte size. - The number of bytes to write defaults to the entire file byte size, but can be changed with the "--size COUNT" option. llvm-svn: 116172
2010-10-11 04:52:20 +08:00
return false;
*** 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
buffer.PutMaxHex64(uval64, item_byte_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
break;
getAsInteger is not a equivalent replacement for strtol work around that fact for CommandObjectMemoryWrite. <rdar://problem/31457148> llvm-svn: 299609
2017-04-06 09:33:38 +08:00
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
case eFormatBoolean:
[lldb][NFC] Remove ArgEntry::ref member The StringRef should always be identical to the C string, so we might as well just create the StringRef from the C-string. This might be slightly slower until we implement the storage of ArgEntry with a string instead of a std::unique_ptr<char[]>. Until then we have to do the additional strlen on the C string to construct the StringRef. llvm-svn: 371842
2019-09-13 19:26:48 +08:00
uval64 = OptionArgParser::ToBoolean(entry.ref(), false, &success);
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
if (!success) {
"size_t" isn't always 64 bit, it is 32 bit on 32 bit systems. All printf style statements that were assuming size_t were 64 bit were changed, and they were also changed to display them as unsigned values as "size_t" isn't signed. If you print anything with 'size_t', please cast it to "uint64_t" in the printf and use PRIu64 or PRIx64. llvm-svn: 202738
2014-03-04 03:15:20 +08:00
result.AppendErrorWithFormat(
Modernize the Args access pattern in a few more commands. llvm-svn: 289164
2016-12-09 09:08:29 +08:00
"'%s' is not a valid boolean string value.\n", entry.c_str());
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
return false;
*** 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
buffer.PutMaxHex64(uval64, item_byte_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
break;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
case eFormatBinary:
[lldb][NFC] Remove ArgEntry::ref member The StringRef should always be identical to the C string, so we might as well just create the StringRef from the C-string. This might be slightly slower until we implement the storage of ArgEntry with a string instead of a std::unique_ptr<char[]>. Until then we have to do the additional strlen on the C string to construct the StringRef. llvm-svn: 371842
2019-09-13 19:26:48 +08:00
if (entry.ref().getAsInteger(2, uval64)) {
"size_t" isn't always 64 bit, it is 32 bit on 32 bit systems. All printf style statements that were assuming size_t were 64 bit were changed, and they were also changed to display them as unsigned values as "size_t" isn't signed. If you print anything with 'size_t', please cast it to "uint64_t" in the printf and use PRIu64 or PRIx64. llvm-svn: 202738
2014-03-04 03:15:20 +08:00
result.AppendErrorWithFormat(
Modernize the Args access pattern in a few more commands. llvm-svn: 289164
2016-12-09 09:08:29 +08:00
"'%s' is not a valid binary string value.\n", entry.c_str());
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
return false;
[lldb] Remove [US]IntValueIsValidForSize from CommandObjectMemory Use llvm::is(U)IntN (MathExtras.h) instead.
2020-11-04 23:25:38 +08:00
} else if (!llvm::isUIntN(item_byte_size * 8, uval64)) {
<rdar://problem/12820334> I modified the "Args::StringtoAddress(...)" function to be able to evaluate address expressions. This is now used for any command line arguments or options that takes addresses like: memory read <addr> [<end-addr>] memory write <addr> breakpoint set --address <addr> disassemble --start-address <addr> --end-address <addr> It calls the expression parser to evaluate the address expression and will also work around the issue where the compiler doesn't like to add offsets to function pointers (which is what happens when you try to evaluate "main + 12"). So there is a temp fix in the Args::StringtoAddress() to work around this until we can get special compiler support for debug expressions with function pointers. llvm-svn: 169556
2012-12-07 06:49:16 +08:00
result.AppendErrorWithFormat("Value 0x%" PRIx64
"size_t" isn't always 64 bit, it is 32 bit on 32 bit systems. All printf style statements that were assuming size_t were 64 bit were changed, and they were also changed to display them as unsigned values as "size_t" isn't signed. If you print anything with 'size_t', please cast it to "uint64_t" in the printf and use PRIu64 or PRIx64. llvm-svn: 202738
2014-03-04 03:15:20 +08:00
" is too large to fit in a %" PRIu64
" byte unsigned integer value.\n",
uval64, (uint64_t)item_byte_size);
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
return false;
*** 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/12820334> I modified the "Args::StringtoAddress(...)" function to be able to evaluate address expressions. This is now used for any command line arguments or options that takes addresses like: memory read <addr> [<end-addr>] memory write <addr> breakpoint set --address <addr> disassemble --start-address <addr> --end-address <addr> It calls the expression parser to evaluate the address expression and will also work around the issue where the compiler doesn't like to add offsets to function pointers (which is what happens when you try to evaluate "main + 12"). So there is a temp fix in the Args::StringtoAddress() to work around this until we can get special compiler support for debug expressions with function pointers. llvm-svn: 169556
2012-12-07 06:49:16 +08:00
buffer.PutMaxHex64(uval64, item_byte_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
break;
Added a new format for displaying an array of characters: eFormatCharArray This us useful because sometomes you have to show a single character as: 'a' (using eFormatChar) and other times you might have an array of single charcters for display as: 'a' 'b' 'c', and other times you might want to show the contents of buffer of characters that can contain non printable chars: "\0\x22\n123". This also fixes an issue that currently happens when you have a single character C string (const char *a = "a"; or char b[1] = { 'b' };) that was being output as "'a'" incorrectly due to the way the eFormatChar format output worked. llvm-svn: 133316
2011-06-18 07:50:44 +08:00
case eFormatCharArray:
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
case eFormatChar:
Modernize the Args access pattern in a few more commands. llvm-svn: 289164
2016-12-09 09:08:29 +08:00
case eFormatCString: {
[lldb][NFC] Remove ArgEntry::ref member The StringRef should always be identical to the C string, so we might as well just create the StringRef from the C-string. This might be slightly slower until we implement the storage of ArgEntry with a string instead of a std::unique_ptr<char[]>. Until then we have to do the additional strlen on the C string to construct the StringRef. llvm-svn: 371842
2019-09-13 19:26:48 +08:00
if (entry.ref().empty())
Modernize the Args access pattern in a few more commands. llvm-svn: 289164
2016-12-09 09:08:29 +08:00
break;
[lldb][NFC] Remove ArgEntry::ref member The StringRef should always be identical to the C string, so we might as well just create the StringRef from the C-string. This might be slightly slower until we implement the storage of ArgEntry with a string instead of a std::unique_ptr<char[]>. Until then we have to do the additional strlen on the C string to construct the StringRef. llvm-svn: 371842
2019-09-13 19:26:48 +08:00
size_t len = entry.ref().size();
Modernize the Args access pattern in a few more commands. llvm-svn: 289164
2016-12-09 09:08:29 +08:00
// Include the NULL for C strings...
if (m_format_options.GetFormat() == eFormatCString)
++len;
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;
Modernize the Args access pattern in a few more commands. llvm-svn: 289164
2016-12-09 09:08:29 +08:00
if (process->WriteMemory(addr, entry.c_str(), len, error) == len) {
addr += len;
} else {
result.AppendErrorWithFormat("Memory write to 0x%" PRIx64
" failed: %s.\n",
addr, error.AsCString());
return false;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
Updated all commands that use a "--format" / "-f" options to use the new OptionGroupFormat. Updated OptionGroupFormat to be able to also use the "--size" and "--count" options. Commands that use a OptionGroupFormat instance can choose which of the options they want by initializing OptionGroupFormat accordingly. Clients can either get only the "--format", "--format" + "--size", or "--format" + "--size" + "--count". This is in preparation for upcoming chnages where there are alternate ways (GDB format specification) to set a format. llvm-svn: 142911
2011-10-25 14:44:01 +08:00
break;
Modernize the Args access pattern in a few more commands. llvm-svn: 289164
2016-12-09 09:08:29 +08:00
}
Updated all commands that use a "--format" / "-f" options to use the new OptionGroupFormat. Updated OptionGroupFormat to be able to also use the "--size" and "--count" options. Commands that use a OptionGroupFormat instance can choose which of the options they want by initializing OptionGroupFormat accordingly. Clients can either get only the "--format", "--format" + "--size", or "--format" + "--size" + "--count". This is in preparation for upcoming chnages where there are alternate ways (GDB format specification) to set a format. llvm-svn: 142911
2011-10-25 14:44:01 +08:00
case eFormatDecimal:
[lldb][NFC] Remove ArgEntry::ref member The StringRef should always be identical to the C string, so we might as well just create the StringRef from the C-string. This might be slightly slower until we implement the storage of ArgEntry with a string instead of a std::unique_ptr<char[]>. Until then we have to do the additional strlen on the C string to construct the StringRef. llvm-svn: 371842
2019-09-13 19:26:48 +08:00
if (entry.ref().getAsInteger(0, sval64)) {
Resolve printf formatting warnings on Linux: - use macros from inttypes.h for format strings instead of OS-specific types Patch from Matt Kopec! llvm-svn: 168945
2012-11-30 05:49:15 +08:00
result.AppendErrorWithFormat(
Modernize the Args access pattern in a few more commands. llvm-svn: 289164
2016-12-09 09:08:29 +08:00
"'%s' is not a valid signed decimal value.\n", entry.c_str());
Added new options to memory read to allow saving memory to disk as binary bytes or as an ASCII text dump. - The output file is specified with the "--outfile FILE" option. - The memory can be appended to an existing file using the "--append" option. - The memory will be written as an ASCII text dump by default, or as binary with the "--binary" option. Added new options to memory write to allow writing all or part of a file on disk to target memory: - The input file is specified using the "--infile FILE" option - The offset at which to start in the file defaults to zero, but can be overridden using the "--offset OFFSET" option. If the size is not specified, the remaining number of bytes in the file will be used as the default byte size. - The number of bytes to write defaults to the entire file byte size, but can be changed with the "--size COUNT" option. llvm-svn: 116172
2010-10-11 04:52:20 +08:00
return false;
[lldb] Remove [US]IntValueIsValidForSize from CommandObjectMemory Use llvm::is(U)IntN (MathExtras.h) instead.
2020-11-04 23:25:38 +08:00
} else if (!llvm::isIntN(item_byte_size * 8, sval64)) {
Resolve printf formatting warnings on Linux: - use macros from inttypes.h for format strings instead of OS-specific types Patch from Matt Kopec! llvm-svn: 168945
2012-11-30 05:49:15 +08:00
result.AppendErrorWithFormat(
"Value %" PRIi64 " is too large or small to fit in a %" PRIu64
" byte signed integer value.\n",
sval64, (uint64_t)item_byte_size);
Added new options to memory read to allow saving memory to disk as binary bytes or as an ASCII text dump. - The output file is specified with the "--outfile FILE" option. - The memory can be appended to an existing file using the "--append" option. - The memory will be written as an ASCII text dump by default, or as binary with the "--binary" option. Added new options to memory write to allow writing all or part of a file on disk to target memory: - The input file is specified using the "--infile FILE" option - The offset at which to start in the file defaults to zero, but can be overridden using the "--offset OFFSET" option. If the size is not specified, the remaining number of bytes in the file will be used as the default byte size. - The number of bytes to write defaults to the entire file byte size, but can be changed with the "--size COUNT" option. llvm-svn: 116172
2010-10-11 04:52:20 +08:00
return false;
}
buffer.PutMaxHex64(sval64, item_byte_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
break;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
case eFormatUnsigned:
Modernize the Args access pattern in a few more commands. llvm-svn: 289164
2016-12-09 09:08:29 +08:00
[lldb] Correct unsigned decimal argument check in memory write getAsInteger returns false when it succeeds. Before: (lldb) memory write 0x00007ffff7dd3000 99 -f "unsigned decimal" error: '99' is not a valid unsigned decimal string value. After: (lldb) memory write 0x00007ffff7dd3000 99 -f "unsigned decimal" (lldb) memory read 0x00007ffff7dd3000 0x00007ffff7dd3001 0x7ffff7dd3000: 63 c
2021-03-17 23:45:37 +08:00
if (entry.ref().getAsInteger(0, uval64)) {
"size_t" isn't always 64 bit, it is 32 bit on 32 bit systems. All printf style statements that were assuming size_t were 64 bit were changed, and they were also changed to display them as unsigned values as "size_t" isn't signed. If you print anything with 'size_t', please cast it to "uint64_t" in the printf and use PRIu64 or PRIx64. llvm-svn: 202738
2014-03-04 03:15:20 +08:00
result.AppendErrorWithFormat(
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
"'%s' is not a valid unsigned decimal string value.\n",
Modernize the Args access pattern in a few more commands. llvm-svn: 289164
2016-12-09 09:08:29 +08:00
entry.c_str());
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
return false;
[lldb] Remove [US]IntValueIsValidForSize from CommandObjectMemory Use llvm::is(U)IntN (MathExtras.h) instead.
2020-11-04 23:25:38 +08:00
} else if (!llvm::isUIntN(item_byte_size * 8, uval64)) {
Added new options to memory read to allow saving memory to disk as binary bytes or as an ASCII text dump. - The output file is specified with the "--outfile FILE" option. - The memory can be appended to an existing file using the "--append" option. - The memory will be written as an ASCII text dump by default, or as binary with the "--binary" option. Added new options to memory write to allow writing all or part of a file on disk to target memory: - The input file is specified using the "--infile FILE" option - The offset at which to start in the file defaults to zero, but can be overridden using the "--offset OFFSET" option. If the size is not specified, the remaining number of bytes in the file will be used as the default byte size. - The number of bytes to write defaults to the entire file byte size, but can be changed with the "--size COUNT" option. llvm-svn: 116172
2010-10-11 04:52:20 +08:00
result.AppendErrorWithFormat("Value %" PRIu64
" is too large to fit in a %" PRIu64
"size_t" isn't always 64 bit, it is 32 bit on 32 bit systems. All printf style statements that were assuming size_t were 64 bit were changed, and they were also changed to display them as unsigned values as "size_t" isn't signed. If you print anything with 'size_t', please cast it to "uint64_t" in the printf and use PRIu64 or PRIx64. llvm-svn: 202738
2014-03-04 03:15:20 +08:00
" byte unsigned integer value.\n",
Added new options to memory read to allow saving memory to disk as binary bytes or as an ASCII text dump. - The output file is specified with the "--outfile FILE" option. - The memory can be appended to an existing file using the "--append" option. - The memory will be written as an ASCII text dump by default, or as binary with the "--binary" option. Added new options to memory write to allow writing all or part of a file on disk to target memory: - The input file is specified using the "--infile FILE" option - The offset at which to start in the file defaults to zero, but can be overridden using the "--offset OFFSET" option. If the size is not specified, the remaining number of bytes in the file will be used as the default byte size. - The number of bytes to write defaults to the entire file byte size, but can be changed with the "--size COUNT" option. llvm-svn: 116172
2010-10-11 04:52:20 +08:00
uval64, (uint64_t)item_byte_size);
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
return false;
Added new options to memory read to allow saving memory to disk as binary bytes or as an ASCII text dump. - The output file is specified with the "--outfile FILE" option. - The memory can be appended to an existing file using the "--append" option. - The memory will be written as an ASCII text dump by default, or as binary with the "--binary" option. Added new options to memory write to allow writing all or part of a file on disk to target memory: - The input file is specified using the "--infile FILE" option - The offset at which to start in the file defaults to zero, but can be overridden using the "--offset OFFSET" option. If the size is not specified, the remaining number of bytes in the file will be used as the default byte size. - The number of bytes to write defaults to the entire file byte size, but can be changed with the "--size COUNT" option. llvm-svn: 116172
2010-10-11 04:52:20 +08:00
}
<rdar://problem/13069948> Major fixed to allow reading files that are over 4GB. The main problems were that the DataExtractor was using 32 bit offsets as a data cursor, and since we mmap all of our object files we could run into cases where if we had a very large core file that was over 4GB, we were running into the 4GB boundary. So I defined a new "lldb::offset_t" which should be used for all file offsets. After making this change, I enabled warnings for data loss and for enexpected implicit conversions temporarily and found a ton of things that I fixed. Any functions that take an index internally, should use "size_t" for any indexes and also should return "size_t" for any sizes of collections. llvm-svn: 173463
2013-01-26 02:06:21 +08:00
buffer.PutMaxHex64(uval64, item_byte_size);
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
break;
*** 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
case eFormatOctal:
[lldb][NFC] Remove ArgEntry::ref member The StringRef should always be identical to the C string, so we might as well just create the StringRef from the C-string. This might be slightly slower until we implement the storage of ArgEntry with a string instead of a std::unique_ptr<char[]>. Until then we have to do the additional strlen on the C string to construct the StringRef. llvm-svn: 371842
2019-09-13 19:26:48 +08:00
if (entry.ref().getAsInteger(8, uval64)) {
"size_t" isn't always 64 bit, it is 32 bit on 32 bit systems. All printf style statements that were assuming size_t were 64 bit were changed, and they were also changed to display them as unsigned values as "size_t" isn't signed. If you print anything with 'size_t', please cast it to "uint64_t" in the printf and use PRIu64 or PRIx64. llvm-svn: 202738
2014-03-04 03:15:20 +08:00
result.AppendErrorWithFormat(
Modernize the Args access pattern in a few more commands. llvm-svn: 289164
2016-12-09 09:08:29 +08:00
"'%s' is not a valid octal string value.\n", entry.c_str());
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
return false;
[lldb] Remove [US]IntValueIsValidForSize from CommandObjectMemory Use llvm::is(U)IntN (MathExtras.h) instead.
2020-11-04 23:25:38 +08:00
} else if (!llvm::isUIntN(item_byte_size * 8, uval64)) {
Resolve printf formatting warnings on Linux: - use macros from inttypes.h for format strings instead of OS-specific types Patch from Matt Kopec! llvm-svn: 168945
2012-11-30 05:49:15 +08:00
result.AppendErrorWithFormat("Value %" PRIo64
"size_t" isn't always 64 bit, it is 32 bit on 32 bit systems. All printf style statements that were assuming size_t were 64 bit were changed, and they were also changed to display them as unsigned values as "size_t" isn't signed. If you print anything with 'size_t', please cast it to "uint64_t" in the printf and use PRIu64 or PRIx64. llvm-svn: 202738
2014-03-04 03:15:20 +08:00
" is too large to fit in a %" PRIu64
" byte unsigned integer value.\n",
uval64, (uint64_t)item_byte_size);
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
return false;
}
buffer.PutMaxHex64(uval64, item_byte_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
break;
}
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
if (!buffer.GetString().empty()) {
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;
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
if (process->WriteMemory(addr, buffer.GetString().data(),
Remove use of STL collection class use of the "data()" method since it isn't part of C++'98. Most of these were "std::vector<T>::data()" and "std::string::data()". llvm-svn: 108957
2010-07-21 06:52:08 +08:00
buffer.GetString().size(),
error) == buffer.GetString().size())
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
return true;
*** 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 {
Resolve printf formatting warnings on Linux: - use macros from inttypes.h for format strings instead of OS-specific types Patch from Matt Kopec! llvm-svn: 168945
2012-11-30 05:49:15 +08:00
result.AppendErrorWithFormat("Memory write to 0x%" PRIx64
" failed: %s.\n",
addr, error.AsCString());
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
return false;
*** 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
}
return true;
*** 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
Updated all commands that use a "--format" / "-f" options to use the new OptionGroupFormat. Updated OptionGroupFormat to be able to also use the "--size" and "--count" options. Commands that use a OptionGroupFormat instance can choose which of the options they want by initializing OptionGroupFormat accordingly. Clients can either get only the "--format", "--format" + "--size", or "--format" + "--size" + "--count". This is in preparation for upcoming chnages where there are alternate ways (GDB format specification) to set a format. llvm-svn: 142911
2011-10-25 14:44:01 +08:00
OptionGroupOptions m_option_group;
OptionGroupFormat m_format_options;
OptionGroupWriteMemory m_memory_options;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
};
ASan malloc/free history threads Reviewed at http://reviews.llvm.org/D4596 llvm-svn: 217116
2014-09-04 09:03:18 +08:00
// Get malloc/free history of a memory address.
class CommandObjectMemoryHistory : public CommandObjectParsed {
public:
LLDB help content has accumulated over time without a recent attempt to review it for consistency, accuracy, and clarity. These changes attempt to address all of the above while keeping the text relatively terse. <rdar://problem/24868841> llvm-svn: 275485
2016-07-15 06:03:10 +08:00
CommandObjectMemoryHistory(CommandInterpreter &interpreter)
Run clang-format on lldb/source/Commands (NFC) These files had a lot of whitespace errors in them which was a constant source of merge conflicts downstream.
2019-10-31 06:26:19 +08:00
: CommandObjectParsed(interpreter, "memory history",
"Print recorded stack traces for "
"allocation/deallocation events "
"associated with an address.",
nullptr,
eCommandRequiresTarget | eCommandRequiresProcess |
eCommandProcessMustBePaused |
eCommandProcessMustBeLaunched) {
ASan malloc/free history threads Reviewed at http://reviews.llvm.org/D4596 llvm-svn: 217116
2014-09-04 09:03:18 +08:00
CommandArgumentEntry arg1;
CommandArgumentData addr_arg;
*** 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
ASan malloc/free history threads Reviewed at http://reviews.llvm.org/D4596 llvm-svn: 217116
2014-09-04 09:03:18 +08:00
// Define the first (and only) variant of this arg.
addr_arg.arg_type = eArgTypeAddress;
addr_arg.arg_repetition = eArgRepeatPlain;
*** 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
ASan malloc/free history threads Reviewed at http://reviews.llvm.org/D4596 llvm-svn: 217116
2014-09-04 09:03:18 +08:00
// There is only one variant this argument could be; put it into the
// argument entry.
arg1.push_back(addr_arg);
*** 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
ASan malloc/free history threads Reviewed at http://reviews.llvm.org/D4596 llvm-svn: 217116
2014-09-04 09:03:18 +08:00
// Push the data for the first argument into the m_arguments vector.
m_arguments.push_back(arg1);
*** 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
}
Fix Clang-tidy modernize-use-nullptr and modernize-use-default warnings in some files in source/Commands; other minor fixes. llvm-svn: 261389
2016-02-20 08:58:29 +08:00
~CommandObjectMemoryHistory() override = default;
*** 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 a repeat command option for "thread backtrace --count N". This way if you have a long stack, you can issue "thread backtrace --count 10" and then subsequent <Return>-s will page you through the stack. This took a little more effort than just adding the repeat command, since the GetRepeatCommand API was returning a "const char *". That meant the command had to keep the repeat string alive, which is inconvenient. The original API returned either a nullptr, or a const char *, so I changed the private API to return an llvm::Optional<std::string>. Most of the patch is propagating that change. Also, there was a little thinko in fetching the repeat command. We don't fetch repeat commands for commands that aren't being added to history, which is in general reasonable. And we don't add repeat commands to the history - also reasonable. But we do want the repeat command to be able to generate the NEXT repeat command. So I adjusted the logic in HandleCommand to work that way. Differential Revision: https://reviews.llvm.org/D119046
2022-02-05 07:16:31 +08:00
llvm::Optional<std::string> GetRepeatCommand(Args &current_command_args,
uint32_t index) override {
return m_cmd_name;
*** 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
}
ASan malloc/free history threads Reviewed at http://reviews.llvm.org/D4596 llvm-svn: 217116
2014-09-04 09:03:18 +08:00
protected:
Since our expression parser needs to locate areas of memory that are not in use when you have a process that can't JIT code, like core file debugging, the core file process plug-ins should be able to override the Process::GetMemoryRegionInfo(...) function. In order to make this happen, I have added permissions to sections so that we can know what the permissions are for a given section, and modified both core file plug-ins to override Process::GetMemoryRegionInfo() and answer things correctly. llvm-svn: 272276
2016-06-10 00:34:06 +08:00
bool DoExecute(Args &command, CommandReturnObject &result) override {
ASan malloc/free history threads Reviewed at http://reviews.llvm.org/D4596 llvm-svn: 217116
2014-09-04 09:03:18 +08:00
const size_t argc = command.GetArgumentCount();
*** 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
ASan malloc/free history threads Reviewed at http://reviews.llvm.org/D4596 llvm-svn: 217116
2014-09-04 09:03:18 +08:00
if (argc == 0 || argc > 1) {
result.AppendErrorWithFormat("%s takes an address expression",
m_cmd_name.c_str());
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
return false;
ASan malloc/free history threads Reviewed at http://reviews.llvm.org/D4596 llvm-svn: 217116
2014-09-04 09:03:18 +08:00
}
Fix Clang-tidy modernize-use-nullptr and modernize-use-default warnings in some files in source/Commands; other minor fixes. llvm-svn: 261389
2016-02-20 08:58:29 +08:00
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;
Move Args::StringTo*** functions to a new OptionArgParser class Summary: The idea behind this is to move the functionality which depend on other lldb classes into a separate class. This way, the Args class can be turned into a lightweight arc+argv wrapper and moved into the lower lldb layers. Reviewers: jingham, zturner Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D44306 llvm-svn: 329677
2018-04-10 17:03:59 +08:00
lldb::addr_t addr = OptionArgParser::ToAddress(
[lldb][NFC] Remove ArgEntry::ref member The StringRef should always be identical to the C string, so we might as well just create the StringRef from the C-string. This might be slightly slower until we implement the storage of ArgEntry with a string instead of a std::unique_ptr<char[]>. Until then we have to do the additional strlen on the C string to construct the StringRef. llvm-svn: 371842
2019-09-13 19:26:48 +08:00
&m_exe_ctx, command[0].ref(), LLDB_INVALID_ADDRESS, &error);
Fix Clang-tidy modernize-use-nullptr and modernize-use-default warnings in some files in source/Commands; other minor fixes. llvm-svn: 261389
2016-02-20 08:58:29 +08:00
commands: Use override instead of virtual. Summary: This removes all uses of virtual on functions where override could be used, including on destructors. It also adds override where virtual was previously missing. Reviewers: clayborg, labath Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D13503 llvm-svn: 249564
2015-10-08 00:56:17 +08:00
if (addr == LLDB_INVALID_ADDRESS) {
result.AppendError("invalid address expression");
result.AppendError(error.AsCString());
ASan malloc/free history threads Reviewed at http://reviews.llvm.org/D4596 llvm-svn: 217116
2014-09-04 09:03:18 +08:00
return false;
}
*** 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
ASan malloc/free history threads Reviewed at http://reviews.llvm.org/D4596 llvm-svn: 217116
2014-09-04 09:03:18 +08:00
Stream *output_stream = &result.GetOutputStream();
*** 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
ASan malloc/free history threads Reviewed at http://reviews.llvm.org/D4596 llvm-svn: 217116
2014-09-04 09:03:18 +08:00
const ProcessSP &process_sp = m_exe_ctx.GetProcessSP();
const MemoryHistorySP &memory_history =
MemoryHistory::FindPlugin(process_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
Fix Clang-tidy modernize-use-nullptr and modernize-use-default warnings in some files in source/Commands; other minor fixes. llvm-svn: 261389
2016-02-20 08:58:29 +08:00
if (!memory_history) {
ASan malloc/free history threads Reviewed at http://reviews.llvm.org/D4596 llvm-svn: 217116
2014-09-04 09:03:18 +08:00
result.AppendError("no available memory history provider");
return false;
}
*** 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
ASan malloc/free history threads Reviewed at http://reviews.llvm.org/D4596 llvm-svn: 217116
2014-09-04 09:03:18 +08:00
HistoryThreads thread_list = memory_history->GetHistoryThreads(addr);
*** 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
Clean up the stop printing header lines. I added a "thread-stop-format" to distinguish between the form that is just the thread info (since the stop printing immediately prints the frame info) and one with more frame 0 info - which is useful for "thread list" and the like. I also added a frame.no-debug boolean to the format entities so you can print frame information differently between frames with source info and those without. This closes https://reviews.llvm.org/D26383. <rdar://problem/28273697> llvm-svn: 286288
2016-11-09 04:36:40 +08:00
const bool stop_format = false;
ASan malloc/free history threads Reviewed at http://reviews.llvm.org/D4596 llvm-svn: 217116
2014-09-04 09:03:18 +08:00
for (auto thread : thread_list) {
Clean up the stop printing header lines. I added a "thread-stop-format" to distinguish between the form that is just the thread info (since the stop printing immediately prints the frame info) and one with more frame 0 info - which is useful for "thread list" and the like. I also added a frame.no-debug boolean to the format entities so you can print frame information differently between frames with source info and those without. This closes https://reviews.llvm.org/D26383. <rdar://problem/28273697> llvm-svn: 286288
2016-11-09 04:36:40 +08:00
thread->GetStatus(*output_stream, 0, UINT32_MAX, 0, stop_format);
*** 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
}
ASan malloc/free history threads Reviewed at http://reviews.llvm.org/D4596 llvm-svn: 217116
2014-09-04 09:03:18 +08:00
result.SetStatus(eReturnStatusSuccessFinishResult);
*** 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
return true;
*** 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
}
ASan malloc/free history threads Reviewed at http://reviews.llvm.org/D4596 llvm-svn: 217116
2014-09-04 09:03:18 +08:00
};
Since our expression parser needs to locate areas of memory that are not in use when you have a process that can't JIT code, like core file debugging, the core file process plug-ins should be able to override the Process::GetMemoryRegionInfo(...) function. In order to make this happen, I have added permissions to sections so that we can know what the permissions are for a given section, and modified both core file plug-ins to override Process::GetMemoryRegionInfo() and answer things correctly. llvm-svn: 272276
2016-06-10 00:34:06 +08:00
// CommandObjectMemoryRegion
#pragma mark CommandObjectMemoryRegion
Reland "[lldb] Add --all option to "memory region"" This reverts commit 3e928c4b9dfb01efd2cb968795e605760828e873. This fixes an issue seen on Windows where we did not properly get the section names of regions if they overlapped. Windows has regions like: [0x00007fff928db000-0x00007fff949a0000) --- [0x00007fff949a0000-0x00007fff949a1000) r-- PECOFF header [0x00007fff949a0000-0x00007fff94a3d000) r-x .hexpthk [0x00007fff949a0000-0x00007fff94a85000) r-- .rdata [0x00007fff949a0000-0x00007fff94a88000) rw- .data [0x00007fff949a0000-0x00007fff94a94000) r-- .pdata [0x00007fff94a94000-0x00007fff95250000) --- I assumed that you could just resolve the address and get the section name using the start of the region but here you'd always get "PECOFF header" because they all have the same start point. The usual command repeating loop used the end address of the previous region when requesting the next, or getting the section name. So I've matched this in the --all scenario. In the example above, somehow asking for the region at 0x00007fff949a1000 would get you a region that starts at 0x00007fff949a0000 but has a different end point. Using the load address you get (what I assume is) the correct section name.
2022-05-19 19:57:44 +08:00
#define LLDB_OPTIONS_memory_region
#include "CommandOptions.inc"
Since our expression parser needs to locate areas of memory that are not in use when you have a process that can't JIT code, like core file debugging, the core file process plug-ins should be able to override the Process::GetMemoryRegionInfo(...) function. In order to make this happen, I have added permissions to sections so that we can know what the permissions are for a given section, and modified both core file plug-ins to override Process::GetMemoryRegionInfo() and answer things correctly. llvm-svn: 272276
2016-06-10 00:34:06 +08:00
class CommandObjectMemoryRegion : public CommandObjectParsed {
public:
Reland "[lldb] Add --all option to "memory region"" This reverts commit 3e928c4b9dfb01efd2cb968795e605760828e873. This fixes an issue seen on Windows where we did not properly get the section names of regions if they overlapped. Windows has regions like: [0x00007fff928db000-0x00007fff949a0000) --- [0x00007fff949a0000-0x00007fff949a1000) r-- PECOFF header [0x00007fff949a0000-0x00007fff94a3d000) r-x .hexpthk [0x00007fff949a0000-0x00007fff94a85000) r-- .rdata [0x00007fff949a0000-0x00007fff94a88000) rw- .data [0x00007fff949a0000-0x00007fff94a94000) r-- .pdata [0x00007fff94a94000-0x00007fff95250000) --- I assumed that you could just resolve the address and get the section name using the start of the region but here you'd always get "PECOFF header" because they all have the same start point. The usual command repeating loop used the end address of the previous region when requesting the next, or getting the section name. So I've matched this in the --all scenario. In the example above, somehow asking for the region at 0x00007fff949a1000 would get you a region that starts at 0x00007fff949a0000 but has a different end point. Using the load address you get (what I assume is) the correct section name.
2022-05-19 19:57:44 +08:00
class OptionGroupMemoryRegion : public OptionGroup {
public:
OptionGroupMemoryRegion() : OptionGroup(), m_all(false, false) {}
~OptionGroupMemoryRegion() override = default;
llvm::ArrayRef<OptionDefinition> GetDefinitions() override {
return llvm::makeArrayRef(g_memory_region_options);
}
Status SetOptionValue(uint32_t option_idx, llvm::StringRef option_value,
ExecutionContext *execution_context) override {
Status status;
const int short_option = g_memory_region_options[option_idx].short_option;
switch (short_option) {
case 'a':
m_all.SetCurrentValue(true);
m_all.SetOptionWasSet();
break;
default:
llvm_unreachable("Unimplemented option");
}
return status;
}
void OptionParsingStarting(ExecutionContext *execution_context) override {
m_all.Clear();
}
OptionValueBoolean m_all;
};
Since our expression parser needs to locate areas of memory that are not in use when you have a process that can't JIT code, like core file debugging, the core file process plug-ins should be able to override the Process::GetMemoryRegionInfo(...) function. In order to make this happen, I have added permissions to sections so that we can know what the permissions are for a given section, and modified both core file plug-ins to override Process::GetMemoryRegionInfo() and answer things correctly. llvm-svn: 272276
2016-06-10 00:34:06 +08:00
CommandObjectMemoryRegion(CommandInterpreter &interpreter)
LLDB help content has accumulated over time without a recent attempt to review it for consistency, accuracy, and clarity. These changes attempt to address all of the above while keeping the text relatively terse. <rdar://problem/24868841> llvm-svn: 275485
2016-07-15 06:03:10 +08:00
: CommandObjectParsed(interpreter, "memory region",
"Get information on the memory region containing "
"an address in the current target process.",
Reland "[lldb] Add --all option to "memory region"" This reverts commit 3e928c4b9dfb01efd2cb968795e605760828e873. This fixes an issue seen on Windows where we did not properly get the section names of regions if they overlapped. Windows has regions like: [0x00007fff928db000-0x00007fff949a0000) --- [0x00007fff949a0000-0x00007fff949a1000) r-- PECOFF header [0x00007fff949a0000-0x00007fff94a3d000) r-x .hexpthk [0x00007fff949a0000-0x00007fff94a85000) r-- .rdata [0x00007fff949a0000-0x00007fff94a88000) rw- .data [0x00007fff949a0000-0x00007fff94a94000) r-- .pdata [0x00007fff94a94000-0x00007fff95250000) --- I assumed that you could just resolve the address and get the section name using the start of the region but here you'd always get "PECOFF header" because they all have the same start point. The usual command repeating loop used the end address of the previous region when requesting the next, or getting the section name. So I've matched this in the --all scenario. In the example above, somehow asking for the region at 0x00007fff949a1000 would get you a region that starts at 0x00007fff949a0000 but has a different end point. Using the load address you get (what I assume is) the correct section name.
2022-05-19 19:57:44 +08:00
"memory region <address-expression> (or --all)",
LLDB help content has accumulated over time without a recent attempt to review it for consistency, accuracy, and clarity. These changes attempt to address all of the above while keeping the text relatively terse. <rdar://problem/24868841> llvm-svn: 275485
2016-07-15 06:03:10 +08:00
eCommandRequiresProcess | eCommandTryTargetAPILock |
Reland "[lldb] Add --all option to "memory region"" This reverts commit 3e928c4b9dfb01efd2cb968795e605760828e873. This fixes an issue seen on Windows where we did not properly get the section names of regions if they overlapped. Windows has regions like: [0x00007fff928db000-0x00007fff949a0000) --- [0x00007fff949a0000-0x00007fff949a1000) r-- PECOFF header [0x00007fff949a0000-0x00007fff94a3d000) r-x .hexpthk [0x00007fff949a0000-0x00007fff94a85000) r-- .rdata [0x00007fff949a0000-0x00007fff94a88000) rw- .data [0x00007fff949a0000-0x00007fff94a94000) r-- .pdata [0x00007fff94a94000-0x00007fff95250000) --- I assumed that you could just resolve the address and get the section name using the start of the region but here you'd always get "PECOFF header" because they all have the same start point. The usual command repeating loop used the end address of the previous region when requesting the next, or getting the section name. So I've matched this in the --all scenario. In the example above, somehow asking for the region at 0x00007fff949a1000 would get you a region that starts at 0x00007fff949a0000 but has a different end point. Using the load address you get (what I assume is) the correct section name.
2022-05-19 19:57:44 +08:00
eCommandProcessMustBeLaunched) {
// Address in option set 1.
m_arguments.push_back(CommandArgumentEntry{CommandArgumentData(
eArgTypeAddressOrExpression, eArgRepeatPlain, LLDB_OPT_SET_1)});
// "--all" will go in option set 2.
m_option_group.Append(&m_memory_region_options);
m_option_group.Finalize();
}
Since our expression parser needs to locate areas of memory that are not in use when you have a process that can't JIT code, like core file debugging, the core file process plug-ins should be able to override the Process::GetMemoryRegionInfo(...) function. In order to make this happen, I have added permissions to sections so that we can know what the permissions are for a given section, and modified both core file plug-ins to override Process::GetMemoryRegionInfo() and answer things correctly. llvm-svn: 272276
2016-06-10 00:34:06 +08:00
~CommandObjectMemoryRegion() override = default;
Reland "[lldb] Add --all option to "memory region"" This reverts commit 3e928c4b9dfb01efd2cb968795e605760828e873. This fixes an issue seen on Windows where we did not properly get the section names of regions if they overlapped. Windows has regions like: [0x00007fff928db000-0x00007fff949a0000) --- [0x00007fff949a0000-0x00007fff949a1000) r-- PECOFF header [0x00007fff949a0000-0x00007fff94a3d000) r-x .hexpthk [0x00007fff949a0000-0x00007fff94a85000) r-- .rdata [0x00007fff949a0000-0x00007fff94a88000) rw- .data [0x00007fff949a0000-0x00007fff94a94000) r-- .pdata [0x00007fff94a94000-0x00007fff95250000) --- I assumed that you could just resolve the address and get the section name using the start of the region but here you'd always get "PECOFF header" because they all have the same start point. The usual command repeating loop used the end address of the previous region when requesting the next, or getting the section name. So I've matched this in the --all scenario. In the example above, somehow asking for the region at 0x00007fff949a1000 would get you a region that starts at 0x00007fff949a0000 but has a different end point. Using the load address you get (what I assume is) the correct section name.
2022-05-19 19:57:44 +08:00
Options *GetOptions() override { return &m_option_group; }
Since our expression parser needs to locate areas of memory that are not in use when you have a process that can't JIT code, like core file debugging, the core file process plug-ins should be able to override the Process::GetMemoryRegionInfo(...) function. In order to make this happen, I have added permissions to sections so that we can know what the permissions are for a given section, and modified both core file plug-ins to override Process::GetMemoryRegionInfo() and answer things correctly. llvm-svn: 272276
2016-06-10 00:34:06 +08:00
protected:
Reland "[lldb] Add --all option to "memory region"" This reverts commit 3e928c4b9dfb01efd2cb968795e605760828e873. This fixes an issue seen on Windows where we did not properly get the section names of regions if they overlapped. Windows has regions like: [0x00007fff928db000-0x00007fff949a0000) --- [0x00007fff949a0000-0x00007fff949a1000) r-- PECOFF header [0x00007fff949a0000-0x00007fff94a3d000) r-x .hexpthk [0x00007fff949a0000-0x00007fff94a85000) r-- .rdata [0x00007fff949a0000-0x00007fff94a88000) rw- .data [0x00007fff949a0000-0x00007fff94a94000) r-- .pdata [0x00007fff94a94000-0x00007fff95250000) --- I assumed that you could just resolve the address and get the section name using the start of the region but here you'd always get "PECOFF header" because they all have the same start point. The usual command repeating loop used the end address of the previous region when requesting the next, or getting the section name. So I've matched this in the --all scenario. In the example above, somehow asking for the region at 0x00007fff949a1000 would get you a region that starts at 0x00007fff949a0000 but has a different end point. Using the load address you get (what I assume is) the correct section name.
2022-05-19 19:57:44 +08:00
void DumpRegion(CommandReturnObject &result, Target &target,
const MemoryRegionInfo &range_info, lldb::addr_t load_addr) {
lldb_private::Address addr;
ConstString section_name;
if (target.ResolveLoadAddress(load_addr, addr)) {
SectionSP section_sp(addr.GetSection());
if (section_sp) {
// Got the top most section, not the deepest section
while (section_sp->GetParent())
section_sp = section_sp->GetParent();
section_name = section_sp->GetName();
}
}
ConstString name = range_info.GetName();
result.AppendMessageWithFormatv(
"[{0:x16}-{1:x16}) {2:r}{3:w}{4:x}{5}{6}{7}{8}",
range_info.GetRange().GetRangeBase(),
range_info.GetRange().GetRangeEnd(), range_info.GetReadable(),
range_info.GetWritable(), range_info.GetExecutable(), name ? " " : "",
name, section_name ? " " : "", section_name);
MemoryRegionInfo::OptionalBool memory_tagged = range_info.GetMemoryTagged();
if (memory_tagged == MemoryRegionInfo::OptionalBool::eYes)
result.AppendMessage("memory tagging: enabled");
const llvm::Optional<std::vector<addr_t>> &dirty_page_list =
range_info.GetDirtyPageList();
if (dirty_page_list.hasValue()) {
const size_t page_count = dirty_page_list.getValue().size();
result.AppendMessageWithFormat(
"Modified memory (dirty) page list provided, %zu entries.\n",
page_count);
if (page_count > 0) {
bool print_comma = false;
result.AppendMessageWithFormat("Dirty pages: ");
for (size_t i = 0; i < page_count; i++) {
if (print_comma)
result.AppendMessageWithFormat(", ");
else
print_comma = true;
result.AppendMessageWithFormat("0x%" PRIx64,
dirty_page_list.getValue()[i]);
}
result.AppendMessageWithFormat(".\n");
}
}
}
Since our expression parser needs to locate areas of memory that are not in use when you have a process that can't JIT code, like core file debugging, the core file process plug-ins should be able to override the Process::GetMemoryRegionInfo(...) function. In order to make this happen, I have added permissions to sections so that we can know what the permissions are for a given section, and modified both core file plug-ins to override Process::GetMemoryRegionInfo() and answer things correctly. llvm-svn: 272276
2016-06-10 00:34:06 +08:00
bool DoExecute(Args &command, CommandReturnObject &result) override {
ProcessSP process_sp = m_exe_ctx.GetProcessSP();
Reland "[lldb] Don't send invalid region addresses to lldb server" This reverts commit c65627a1fe3be7521fc232d633bb6df577f55269. The test immediately after the new invalid symbol test was failing on Windows. This was because when we called VirtualQueryEx to get the region info for 0x0, even if it succeeded we would call GetLastError. Which must have picked up the last error that was set while trying to lookup "not_an_address". Which happened to be 2. ("The system cannot find the file specified.") To fix this only call GetLastError when we know VirtualQueryEx has failed. (when it returns 0, which we were also checking for anyway) Also convert memory region to an early return style to make the logic clearer. Reviewed By: labath, stella.stamenova Differential Revision: https://reviews.llvm.org/D88229
2020-09-24 21:50:41 +08:00
if (!process_sp) {
Since our expression parser needs to locate areas of memory that are not in use when you have a process that can't JIT code, like core file debugging, the core file process plug-ins should be able to override the Process::GetMemoryRegionInfo(...) function. In order to make this happen, I have added permissions to sections so that we can know what the permissions are for a given section, and modified both core file plug-ins to override Process::GetMemoryRegionInfo() and answer things correctly. llvm-svn: 272276
2016-06-10 00:34:06 +08:00
m_prev_end_addr = LLDB_INVALID_ADDRESS;
Reland "[lldb] Don't send invalid region addresses to lldb server" This reverts commit c65627a1fe3be7521fc232d633bb6df577f55269. The test immediately after the new invalid symbol test was failing on Windows. This was because when we called VirtualQueryEx to get the region info for 0x0, even if it succeeded we would call GetLastError. Which must have picked up the last error that was set while trying to lookup "not_an_address". Which happened to be 2. ("The system cannot find the file specified.") To fix this only call GetLastError when we know VirtualQueryEx has failed. (when it returns 0, which we were also checking for anyway) Also convert memory region to an early return style to make the logic clearer. Reviewed By: labath, stella.stamenova Differential Revision: https://reviews.llvm.org/D88229
2020-09-24 21:50:41 +08:00
result.AppendError("invalid process");
return false;
}
Status error;
lldb::addr_t load_addr = m_prev_end_addr;
m_prev_end_addr = LLDB_INVALID_ADDRESS;
*** 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
Reland "[lldb] Don't send invalid region addresses to lldb server" This reverts commit c65627a1fe3be7521fc232d633bb6df577f55269. The test immediately after the new invalid symbol test was failing on Windows. This was because when we called VirtualQueryEx to get the region info for 0x0, even if it succeeded we would call GetLastError. Which must have picked up the last error that was set while trying to lookup "not_an_address". Which happened to be 2. ("The system cannot find the file specified.") To fix this only call GetLastError when we know VirtualQueryEx has failed. (when it returns 0, which we were also checking for anyway) Also convert memory region to an early return style to make the logic clearer. Reviewed By: labath, stella.stamenova Differential Revision: https://reviews.llvm.org/D88229
2020-09-24 21:50:41 +08:00
const size_t argc = command.GetArgumentCount();
Reland "[lldb] Remove non address bits when looking up memory regions" This reverts commit 0df522969a7a0128052bd79182c8d58e00556e2f. Additional checks are added to fix the detection of the last memory region in GetMemoryRegions or repeating the "memory region" command when the target has non-address bits. Normally you keep reading from address 0, looking up each region's end address until you get LLDB_INVALID_ADDR as the region end address. (0xffffffffffffffff) This is what the remote will return once you go beyond the last mapped region: [0x0000fffffffdf000-0x0001000000000000) rw- [stack] [0x0001000000000000-0xffffffffffffffff) --- Problem is that when we "fix" the lookup address, we remove some bits from it. On an AArch64 system we have 48 bit virtual addresses, so when we fix the end address of the [stack] region the result is 0. So we loop back to the start. [0x0000fffffffdf000-0x0001000000000000) rw- [stack] [0x0000000000000000-0x0000000000400000) --- To fix this I added an additional check for the last range. If the end address of the region is different once you apply FixDataAddress, we are at the last region. Since the end of the last region will be the last valid mappable address, plus 1. That 1 will be removed by the ABI plugin. The only side effect is that on systems with non-address bits, you won't get that last catch all unmapped region from the max virtual address up to 0xf...f. [0x0000fffff8000000-0x0000fffffffdf000) --- [0x0000fffffffdf000-0x0001000000000000) rw- [stack] <ends here> Though in some way this is more correct because that region is not just unmapped, it's not mappable at all. No extra testing is needed because this is already covered by TestMemoryRegion.py, I simply forgot to run it on system that had both top byte ignore and pointer authentication. This change has been tested on a qemu VM with top byte ignore, memory tagging and pointer authentication enabled. Reviewed By: omjavaid Differential Revision: https://reviews.llvm.org/D115508
2021-12-02 00:14:54 +08:00
const lldb::ABISP &abi = process_sp->GetABI();
Reland "[lldb] Don't send invalid region addresses to lldb server" This reverts commit c65627a1fe3be7521fc232d633bb6df577f55269. The test immediately after the new invalid symbol test was failing on Windows. This was because when we called VirtualQueryEx to get the region info for 0x0, even if it succeeded we would call GetLastError. Which must have picked up the last error that was set while trying to lookup "not_an_address". Which happened to be 2. ("The system cannot find the file specified.") To fix this only call GetLastError when we know VirtualQueryEx has failed. (when it returns 0, which we were also checking for anyway) Also convert memory region to an early return style to make the logic clearer. Reviewed By: labath, stella.stamenova Differential Revision: https://reviews.llvm.org/D88229
2020-09-24 21:50:41 +08:00
if (argc == 1) {
Reland "[lldb] Add --all option to "memory region"" This reverts commit 3e928c4b9dfb01efd2cb968795e605760828e873. This fixes an issue seen on Windows where we did not properly get the section names of regions if they overlapped. Windows has regions like: [0x00007fff928db000-0x00007fff949a0000) --- [0x00007fff949a0000-0x00007fff949a1000) r-- PECOFF header [0x00007fff949a0000-0x00007fff94a3d000) r-x .hexpthk [0x00007fff949a0000-0x00007fff94a85000) r-- .rdata [0x00007fff949a0000-0x00007fff94a88000) rw- .data [0x00007fff949a0000-0x00007fff94a94000) r-- .pdata [0x00007fff94a94000-0x00007fff95250000) --- I assumed that you could just resolve the address and get the section name using the start of the region but here you'd always get "PECOFF header" because they all have the same start point. The usual command repeating loop used the end address of the previous region when requesting the next, or getting the section name. So I've matched this in the --all scenario. In the example above, somehow asking for the region at 0x00007fff949a1000 would get you a region that starts at 0x00007fff949a0000 but has a different end point. Using the load address you get (what I assume is) the correct section name.
2022-05-19 19:57:44 +08:00
if (m_memory_region_options.m_all) {
result.AppendError(
"The \"--all\" option cannot be used when an address "
"argument is given");
return false;
}
Reland "[lldb] Don't send invalid region addresses to lldb server" This reverts commit c65627a1fe3be7521fc232d633bb6df577f55269. The test immediately after the new invalid symbol test was failing on Windows. This was because when we called VirtualQueryEx to get the region info for 0x0, even if it succeeded we would call GetLastError. Which must have picked up the last error that was set while trying to lookup "not_an_address". Which happened to be 2. ("The system cannot find the file specified.") To fix this only call GetLastError when we know VirtualQueryEx has failed. (when it returns 0, which we were also checking for anyway) Also convert memory region to an early return style to make the logic clearer. Reviewed By: labath, stella.stamenova Differential Revision: https://reviews.llvm.org/D88229
2020-09-24 21:50:41 +08:00
auto load_addr_str = command[0].ref();
Reland "[lldb] Remove non address bits when looking up memory regions" This reverts commit 0df522969a7a0128052bd79182c8d58e00556e2f. Additional checks are added to fix the detection of the last memory region in GetMemoryRegions or repeating the "memory region" command when the target has non-address bits. Normally you keep reading from address 0, looking up each region's end address until you get LLDB_INVALID_ADDR as the region end address. (0xffffffffffffffff) This is what the remote will return once you go beyond the last mapped region: [0x0000fffffffdf000-0x0001000000000000) rw- [stack] [0x0001000000000000-0xffffffffffffffff) --- Problem is that when we "fix" the lookup address, we remove some bits from it. On an AArch64 system we have 48 bit virtual addresses, so when we fix the end address of the [stack] region the result is 0. So we loop back to the start. [0x0000fffffffdf000-0x0001000000000000) rw- [stack] [0x0000000000000000-0x0000000000400000) --- To fix this I added an additional check for the last range. If the end address of the region is different once you apply FixDataAddress, we are at the last region. Since the end of the last region will be the last valid mappable address, plus 1. That 1 will be removed by the ABI plugin. The only side effect is that on systems with non-address bits, you won't get that last catch all unmapped region from the max virtual address up to 0xf...f. [0x0000fffff8000000-0x0000fffffffdf000) --- [0x0000fffffffdf000-0x0001000000000000) rw- [stack] <ends here> Though in some way this is more correct because that region is not just unmapped, it's not mappable at all. No extra testing is needed because this is already covered by TestMemoryRegion.py, I simply forgot to run it on system that had both top byte ignore and pointer authentication. This change has been tested on a qemu VM with top byte ignore, memory tagging and pointer authentication enabled. Reviewed By: omjavaid Differential Revision: https://reviews.llvm.org/D115508
2021-12-02 00:14:54 +08:00
// Non-address bits in this will be handled later by GetMemoryRegion
Reland "[lldb] Don't send invalid region addresses to lldb server" This reverts commit c65627a1fe3be7521fc232d633bb6df577f55269. The test immediately after the new invalid symbol test was failing on Windows. This was because when we called VirtualQueryEx to get the region info for 0x0, even if it succeeded we would call GetLastError. Which must have picked up the last error that was set while trying to lookup "not_an_address". Which happened to be 2. ("The system cannot find the file specified.") To fix this only call GetLastError when we know VirtualQueryEx has failed. (when it returns 0, which we were also checking for anyway) Also convert memory region to an early return style to make the logic clearer. Reviewed By: labath, stella.stamenova Differential Revision: https://reviews.llvm.org/D88229
2020-09-24 21:50:41 +08:00
load_addr = OptionArgParser::ToAddress(&m_exe_ctx, load_addr_str,
LLDB_INVALID_ADDRESS, &error);
if (error.Fail() || load_addr == LLDB_INVALID_ADDRESS) {
result.AppendErrorWithFormat("invalid address argument \"%s\": %s\n",
command[0].c_str(), error.AsCString());
return false;
}
Reland "[lldb] Remove non address bits when looking up memory regions" This reverts commit 0df522969a7a0128052bd79182c8d58e00556e2f. Additional checks are added to fix the detection of the last memory region in GetMemoryRegions or repeating the "memory region" command when the target has non-address bits. Normally you keep reading from address 0, looking up each region's end address until you get LLDB_INVALID_ADDR as the region end address. (0xffffffffffffffff) This is what the remote will return once you go beyond the last mapped region: [0x0000fffffffdf000-0x0001000000000000) rw- [stack] [0x0001000000000000-0xffffffffffffffff) --- Problem is that when we "fix" the lookup address, we remove some bits from it. On an AArch64 system we have 48 bit virtual addresses, so when we fix the end address of the [stack] region the result is 0. So we loop back to the start. [0x0000fffffffdf000-0x0001000000000000) rw- [stack] [0x0000000000000000-0x0000000000400000) --- To fix this I added an additional check for the last range. If the end address of the region is different once you apply FixDataAddress, we are at the last region. Since the end of the last region will be the last valid mappable address, plus 1. That 1 will be removed by the ABI plugin. The only side effect is that on systems with non-address bits, you won't get that last catch all unmapped region from the max virtual address up to 0xf...f. [0x0000fffff8000000-0x0000fffffffdf000) --- [0x0000fffffffdf000-0x0001000000000000) rw- [stack] <ends here> Though in some way this is more correct because that region is not just unmapped, it's not mappable at all. No extra testing is needed because this is already covered by TestMemoryRegion.py, I simply forgot to run it on system that had both top byte ignore and pointer authentication. This change has been tested on a qemu VM with top byte ignore, memory tagging and pointer authentication enabled. Reviewed By: omjavaid Differential Revision: https://reviews.llvm.org/D115508
2021-12-02 00:14:54 +08:00
} else if (argc > 1 ||
// When we're repeating the command, the previous end address is
// used for load_addr. If that was 0xF...F then we must have
// reached the end of memory.
Reland "[lldb] Add --all option to "memory region"" This reverts commit 3e928c4b9dfb01efd2cb968795e605760828e873. This fixes an issue seen on Windows where we did not properly get the section names of regions if they overlapped. Windows has regions like: [0x00007fff928db000-0x00007fff949a0000) --- [0x00007fff949a0000-0x00007fff949a1000) r-- PECOFF header [0x00007fff949a0000-0x00007fff94a3d000) r-x .hexpthk [0x00007fff949a0000-0x00007fff94a85000) r-- .rdata [0x00007fff949a0000-0x00007fff94a88000) rw- .data [0x00007fff949a0000-0x00007fff94a94000) r-- .pdata [0x00007fff94a94000-0x00007fff95250000) --- I assumed that you could just resolve the address and get the section name using the start of the region but here you'd always get "PECOFF header" because they all have the same start point. The usual command repeating loop used the end address of the previous region when requesting the next, or getting the section name. So I've matched this in the --all scenario. In the example above, somehow asking for the region at 0x00007fff949a1000 would get you a region that starts at 0x00007fff949a0000 but has a different end point. Using the load address you get (what I assume is) the correct section name.
2022-05-19 19:57:44 +08:00
(argc == 0 && !m_memory_region_options.m_all &&
load_addr == LLDB_INVALID_ADDRESS) ||
Reland "[lldb] Remove non address bits when looking up memory regions" This reverts commit 0df522969a7a0128052bd79182c8d58e00556e2f. Additional checks are added to fix the detection of the last memory region in GetMemoryRegions or repeating the "memory region" command when the target has non-address bits. Normally you keep reading from address 0, looking up each region's end address until you get LLDB_INVALID_ADDR as the region end address. (0xffffffffffffffff) This is what the remote will return once you go beyond the last mapped region: [0x0000fffffffdf000-0x0001000000000000) rw- [stack] [0x0001000000000000-0xffffffffffffffff) --- Problem is that when we "fix" the lookup address, we remove some bits from it. On an AArch64 system we have 48 bit virtual addresses, so when we fix the end address of the [stack] region the result is 0. So we loop back to the start. [0x0000fffffffdf000-0x0001000000000000) rw- [stack] [0x0000000000000000-0x0000000000400000) --- To fix this I added an additional check for the last range. If the end address of the region is different once you apply FixDataAddress, we are at the last region. Since the end of the last region will be the last valid mappable address, plus 1. That 1 will be removed by the ABI plugin. The only side effect is that on systems with non-address bits, you won't get that last catch all unmapped region from the max virtual address up to 0xf...f. [0x0000fffff8000000-0x0000fffffffdf000) --- [0x0000fffffffdf000-0x0001000000000000) rw- [stack] <ends here> Though in some way this is more correct because that region is not just unmapped, it's not mappable at all. No extra testing is needed because this is already covered by TestMemoryRegion.py, I simply forgot to run it on system that had both top byte ignore and pointer authentication. This change has been tested on a qemu VM with top byte ignore, memory tagging and pointer authentication enabled. Reviewed By: omjavaid Differential Revision: https://reviews.llvm.org/D115508
2021-12-02 00:14:54 +08:00
// If the target has non-address bits (tags, limited virtual
// address size, etc.), the end of mappable memory will be lower
// than that. So if we find any non-address bit set, we must be
// at the end of the mappable range.
[lldb] Add FixAnyAddress to ABI plugins FixAnyAddress is to be used when we don't know or don't care whether we're fixing a code or data address. By using FixAnyAddress over the others, you document that no specific choice was made. On all existing platforms apart from Arm Thumb, you could use either FixCodeAddress or FixDataAddress and be fine. Up until now I've chosen to use FixDataAddress but if I had chosen to use FixCodeAddress that would have broken Arm Thumb. Hence FixAnyAddress, to give you the "safest" option when you're in generic code. Uses of FixDataAddress in memory region code have been changed to FixAnyAddress. The functionality is unchanged. Reviewed By: omjavaid, JDevlieghere Differential Revision: https://reviews.llvm.org/D124000
2022-04-13 20:27:46 +08:00
(abi && (abi->FixAnyAddress(load_addr) != load_addr))) {
Reland "[lldb] Add --all option to "memory region"" This reverts commit 3e928c4b9dfb01efd2cb968795e605760828e873. This fixes an issue seen on Windows where we did not properly get the section names of regions if they overlapped. Windows has regions like: [0x00007fff928db000-0x00007fff949a0000) --- [0x00007fff949a0000-0x00007fff949a1000) r-- PECOFF header [0x00007fff949a0000-0x00007fff94a3d000) r-x .hexpthk [0x00007fff949a0000-0x00007fff94a85000) r-- .rdata [0x00007fff949a0000-0x00007fff94a88000) rw- .data [0x00007fff949a0000-0x00007fff94a94000) r-- .pdata [0x00007fff94a94000-0x00007fff95250000) --- I assumed that you could just resolve the address and get the section name using the start of the region but here you'd always get "PECOFF header" because they all have the same start point. The usual command repeating loop used the end address of the previous region when requesting the next, or getting the section name. So I've matched this in the --all scenario. In the example above, somehow asking for the region at 0x00007fff949a1000 would get you a region that starts at 0x00007fff949a0000 but has a different end point. Using the load address you get (what I assume is) the correct section name.
2022-05-19 19:57:44 +08:00
result.AppendErrorWithFormat(
"'%s' takes one argument or \"--all\" option:\nUsage: %s\n",
m_cmd_name.c_str(), m_cmd_syntax.c_str());
Reland "[lldb] Remove non address bits when looking up memory regions" This reverts commit 0df522969a7a0128052bd79182c8d58e00556e2f. Additional checks are added to fix the detection of the last memory region in GetMemoryRegions or repeating the "memory region" command when the target has non-address bits. Normally you keep reading from address 0, looking up each region's end address until you get LLDB_INVALID_ADDR as the region end address. (0xffffffffffffffff) This is what the remote will return once you go beyond the last mapped region: [0x0000fffffffdf000-0x0001000000000000) rw- [stack] [0x0001000000000000-0xffffffffffffffff) --- Problem is that when we "fix" the lookup address, we remove some bits from it. On an AArch64 system we have 48 bit virtual addresses, so when we fix the end address of the [stack] region the result is 0. So we loop back to the start. [0x0000fffffffdf000-0x0001000000000000) rw- [stack] [0x0000000000000000-0x0000000000400000) --- To fix this I added an additional check for the last range. If the end address of the region is different once you apply FixDataAddress, we are at the last region. Since the end of the last region will be the last valid mappable address, plus 1. That 1 will be removed by the ABI plugin. The only side effect is that on systems with non-address bits, you won't get that last catch all unmapped region from the max virtual address up to 0xf...f. [0x0000fffff8000000-0x0000fffffffdf000) --- [0x0000fffffffdf000-0x0001000000000000) rw- [stack] <ends here> Though in some way this is more correct because that region is not just unmapped, it's not mappable at all. No extra testing is needed because this is already covered by TestMemoryRegion.py, I simply forgot to run it on system that had both top byte ignore and pointer authentication. This change has been tested on a qemu VM with top byte ignore, memory tagging and pointer authentication enabled. Reviewed By: omjavaid Differential Revision: https://reviews.llvm.org/D115508
2021-12-02 00:14:54 +08:00
return false;
Reland "[lldb] Don't send invalid region addresses to lldb server" This reverts commit c65627a1fe3be7521fc232d633bb6df577f55269. The test immediately after the new invalid symbol test was failing on Windows. This was because when we called VirtualQueryEx to get the region info for 0x0, even if it succeeded we would call GetLastError. Which must have picked up the last error that was set while trying to lookup "not_an_address". Which happened to be 2. ("The system cannot find the file specified.") To fix this only call GetLastError when we know VirtualQueryEx has failed. (when it returns 0, which we were also checking for anyway) Also convert memory region to an early return style to make the logic clearer. Reviewed By: labath, stella.stamenova Differential Revision: https://reviews.llvm.org/D88229
2020-09-24 21:50:41 +08:00
}
Since our expression parser needs to locate areas of memory that are not in use when you have a process that can't JIT code, like core file debugging, the core file process plug-ins should be able to override the Process::GetMemoryRegionInfo(...) function. In order to make this happen, I have added permissions to sections so that we can know what the permissions are for a given section, and modified both core file plug-ins to override Process::GetMemoryRegionInfo() and answer things correctly. llvm-svn: 272276
2016-06-10 00:34:06 +08:00
Reland "[lldb] Add --all option to "memory region"" This reverts commit 3e928c4b9dfb01efd2cb968795e605760828e873. This fixes an issue seen on Windows where we did not properly get the section names of regions if they overlapped. Windows has regions like: [0x00007fff928db000-0x00007fff949a0000) --- [0x00007fff949a0000-0x00007fff949a1000) r-- PECOFF header [0x00007fff949a0000-0x00007fff94a3d000) r-x .hexpthk [0x00007fff949a0000-0x00007fff94a85000) r-- .rdata [0x00007fff949a0000-0x00007fff94a88000) rw- .data [0x00007fff949a0000-0x00007fff94a94000) r-- .pdata [0x00007fff94a94000-0x00007fff95250000) --- I assumed that you could just resolve the address and get the section name using the start of the region but here you'd always get "PECOFF header" because they all have the same start point. The usual command repeating loop used the end address of the previous region when requesting the next, or getting the section name. So I've matched this in the --all scenario. In the example above, somehow asking for the region at 0x00007fff949a1000 would get you a region that starts at 0x00007fff949a0000 but has a different end point. Using the load address you get (what I assume is) the correct section name.
2022-05-19 19:57:44 +08:00
// Is is important that we track the address used to request the region as
// this will give the correct section name in the case that regions overlap.
// On Windows we get mutliple regions that start at the same place but are
// different sizes and refer to different sections.
std::vector<std::pair<lldb_private::MemoryRegionInfo, lldb::addr_t>>
region_list;
if (m_memory_region_options.m_all) {
// We don't use GetMemoryRegions here because it doesn't include unmapped
// areas like repeating the command would. So instead, emulate doing that.
lldb::addr_t addr = 0;
while (error.Success() && addr != LLDB_INVALID_ADDRESS &&
// When there are non-address bits the last range will not extend
// to LLDB_INVALID_ADDRESS but to the max virtual address.
// This prevents us looping forever if that is the case.
(abi && (abi->FixAnyAddress(addr) == addr))) {
lldb_private::MemoryRegionInfo region_info;
error = process_sp->GetMemoryRegionInfo(addr, region_info);
if (error.Success()) {
region_list.push_back({region_info, addr});
addr = region_info.GetRange().GetRangeEnd();
*** 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
}
}
[lldb][AArch64/Linux] Show memory tagged memory regions This extends the "memory region" command to show tagged regions on AArch64 Linux when the MTE extension is enabled. (lldb) memory region the_page [0x0000fffff7ff8000-0x0000fffff7ff9000) rw- memory tagging: enabled This is done by adding an optional "flags" field to the qMemoryRegion packet. The only supported flag is "mt" but this can be extended. This "mt" flag is read from /proc/{pid}/smaps on Linux, other platforms will leave out the "flags" field. Where this "mt" flag is received "memory region" will show that it is enabled. If it is not or the target doesn't support memory tagging, the line is not shown. (since majority of the time tagging will not be enabled) Testing is added for the existing /proc/{pid}/maps parsing and the new smaps parsing. Minidump parsing has been updated where needed, though it only uses maps not smaps. Target specific tests can be run with QEMU and I have added MTE flags to the existing helper scripts. Reviewed By: labath Differential Revision: https://reviews.llvm.org/D87442
2020-08-17 22:02:04 +08:00
Reland "[lldb] Add --all option to "memory region"" This reverts commit 3e928c4b9dfb01efd2cb968795e605760828e873. This fixes an issue seen on Windows where we did not properly get the section names of regions if they overlapped. Windows has regions like: [0x00007fff928db000-0x00007fff949a0000) --- [0x00007fff949a0000-0x00007fff949a1000) r-- PECOFF header [0x00007fff949a0000-0x00007fff94a3d000) r-x .hexpthk [0x00007fff949a0000-0x00007fff94a85000) r-- .rdata [0x00007fff949a0000-0x00007fff94a88000) rw- .data [0x00007fff949a0000-0x00007fff94a94000) r-- .pdata [0x00007fff94a94000-0x00007fff95250000) --- I assumed that you could just resolve the address and get the section name using the start of the region but here you'd always get "PECOFF header" because they all have the same start point. The usual command repeating loop used the end address of the previous region when requesting the next, or getting the section name. So I've matched this in the --all scenario. In the example above, somehow asking for the region at 0x00007fff949a1000 would get you a region that starts at 0x00007fff949a0000 but has a different end point. Using the load address you get (what I assume is) the correct section name.
2022-05-19 19:57:44 +08:00
// Even if we read nothing, don't error for --all
error.Clear();
} else {
lldb_private::MemoryRegionInfo region_info;
error = process_sp->GetMemoryRegionInfo(load_addr, region_info);
if (error.Success())
region_list.push_back({region_info, load_addr});
}
if (error.Success()) {
for (std::pair<MemoryRegionInfo, addr_t> &range : region_list) {
DumpRegion(result, process_sp->GetTarget(), range.first, range.second);
m_prev_end_addr = range.first.GetRange().GetRangeEnd();
Add a corefile style option to process save-core; skinny corefiles Add a new feature to process save-core on Darwin systems -- for lldb to create a user process corefile with only the dirty (modified memory) pages included. All of the binaries that were used in the corefile are assumed to still exist on the system for the duration of the use of the corefile. A new --style option to process save-core is added, so a full corefile can be requested if portability across systems, or across time, is needed for this corefile. debugserver can now identify the dirty pages in a memory region when queried with qMemoryRegionInfo, and the size of vm pages is given in qHostInfo. Create a new "all image infos" LC_NOTE for Mach-O which allows us to describe all of the binaries that were loaded in the process -- load address, UUID, file path, segment load addresses, and optionally whether code from the binary was executing on any thread. The old "read dyld_all_image_infos and then the in-memory Mach-O load commands to get segment load addresses" no longer works when we only have dirty memory. rdar://69670807 Differential Revision: https://reviews.llvm.org/D88387
2021-06-21 03:19:50 +08:00
}
Reland "[lldb] Don't send invalid region addresses to lldb server" This reverts commit c65627a1fe3be7521fc232d633bb6df577f55269. The test immediately after the new invalid symbol test was failing on Windows. This was because when we called VirtualQueryEx to get the region info for 0x0, even if it succeeded we would call GetLastError. Which must have picked up the last error that was set while trying to lookup "not_an_address". Which happened to be 2. ("The system cannot find the file specified.") To fix this only call GetLastError when we know VirtualQueryEx has failed. (when it returns 0, which we were also checking for anyway) Also convert memory region to an early return style to make the logic clearer. Reviewed By: labath, stella.stamenova Differential Revision: https://reviews.llvm.org/D88229
2020-09-24 21:50:41 +08:00
result.SetStatus(eReturnStatusSuccessFinishResult);
return true;
Since our expression parser needs to locate areas of memory that are not in use when you have a process that can't JIT code, like core file debugging, the core file process plug-ins should be able to override the Process::GetMemoryRegionInfo(...) function. In order to make this happen, I have added permissions to sections so that we can know what the permissions are for a given section, and modified both core file plug-ins to override Process::GetMemoryRegionInfo() and answer things correctly. llvm-svn: 272276
2016-06-10 00:34:06 +08:00
}
Reland "[lldb] Don't send invalid region addresses to lldb server" This reverts commit c65627a1fe3be7521fc232d633bb6df577f55269. The test immediately after the new invalid symbol test was failing on Windows. This was because when we called VirtualQueryEx to get the region info for 0x0, even if it succeeded we would call GetLastError. Which must have picked up the last error that was set while trying to lookup "not_an_address". Which happened to be 2. ("The system cannot find the file specified.") To fix this only call GetLastError when we know VirtualQueryEx has failed. (when it returns 0, which we were also checking for anyway) Also convert memory region to an early return style to make the logic clearer. Reviewed By: labath, stella.stamenova Differential Revision: https://reviews.llvm.org/D88229
2020-09-24 21:50:41 +08:00
result.AppendErrorWithFormat("%s\n", error.AsCString());
return false;
*** 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 a repeat command option for "thread backtrace --count N". This way if you have a long stack, you can issue "thread backtrace --count 10" and then subsequent <Return>-s will page you through the stack. This took a little more effort than just adding the repeat command, since the GetRepeatCommand API was returning a "const char *". That meant the command had to keep the repeat string alive, which is inconvenient. The original API returned either a nullptr, or a const char *, so I changed the private API to return an llvm::Optional<std::string>. Most of the patch is propagating that change. Also, there was a little thinko in fetching the repeat command. We don't fetch repeat commands for commands that aren't being added to history, which is in general reasonable. And we don't add repeat commands to the history - also reasonable. But we do want the repeat command to be able to generate the NEXT repeat command. So I adjusted the logic in HandleCommand to work that way. Differential Revision: https://reviews.llvm.org/D119046
2022-02-05 07:16:31 +08:00
llvm::Optional<std::string> GetRepeatCommand(Args &current_command_args,
uint32_t index) override {
<rdar://problem/14521548> Fixed a crasher where if you accidentally specify a size that is too large when reading memory, LLDB would crash. llvm-svn: 187060
2013-07-25 02:17:35 +08:00
// If we repeat this command, repeat it without any arguments so we can
Since our expression parser needs to locate areas of memory that are not in use when you have a process that can't JIT code, like core file debugging, the core file process plug-ins should be able to override the Process::GetMemoryRegionInfo(...) function. In order to make this happen, I have added permissions to sections so that we can know what the permissions are for a given section, and modified both core file plug-ins to override Process::GetMemoryRegionInfo() and answer things correctly. llvm-svn: 272276
2016-06-10 00:34:06 +08:00
// show the next memory range
Add a repeat command option for "thread backtrace --count N". This way if you have a long stack, you can issue "thread backtrace --count 10" and then subsequent <Return>-s will page you through the stack. This took a little more effort than just adding the repeat command, since the GetRepeatCommand API was returning a "const char *". That meant the command had to keep the repeat string alive, which is inconvenient. The original API returned either a nullptr, or a const char *, so I changed the private API to return an llvm::Optional<std::string>. Most of the patch is propagating that change. Also, there was a little thinko in fetching the repeat command. We don't fetch repeat commands for commands that aren't being added to history, which is in general reasonable. And we don't add repeat commands to the history - also reasonable. But we do want the repeat command to be able to generate the NEXT repeat command. So I adjusted the logic in HandleCommand to work that way. Differential Revision: https://reviews.llvm.org/D119046
2022-02-05 07:16:31 +08:00
return m_cmd_name;
*** 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
}
Since our expression parser needs to locate areas of memory that are not in use when you have a process that can't JIT code, like core file debugging, the core file process plug-ins should be able to override the Process::GetMemoryRegionInfo(...) function. In order to make this happen, I have added permissions to sections so that we can know what the permissions are for a given section, and modified both core file plug-ins to override Process::GetMemoryRegionInfo() and answer things correctly. llvm-svn: 272276
2016-06-10 00:34:06 +08:00
[LLDB] Applying clang-tidy modernize-use-default-member-init over LLDB Applied modernize-use-default-member-init clang-tidy check over LLDB. It appears in many files we had already switched to in class member init but never updated the constructors to reflect that. This check is already present in the lldb/.clang-tidy config. Differential Revision: https://reviews.llvm.org/D121481
2022-03-15 04:32:03 +08:00
lldb::addr_t m_prev_end_addr = LLDB_INVALID_ADDRESS;
Reland "[lldb] Add --all option to "memory region"" This reverts commit 3e928c4b9dfb01efd2cb968795e605760828e873. This fixes an issue seen on Windows where we did not properly get the section names of regions if they overlapped. Windows has regions like: [0x00007fff928db000-0x00007fff949a0000) --- [0x00007fff949a0000-0x00007fff949a1000) r-- PECOFF header [0x00007fff949a0000-0x00007fff94a3d000) r-x .hexpthk [0x00007fff949a0000-0x00007fff94a85000) r-- .rdata [0x00007fff949a0000-0x00007fff94a88000) rw- .data [0x00007fff949a0000-0x00007fff94a94000) r-- .pdata [0x00007fff94a94000-0x00007fff95250000) --- I assumed that you could just resolve the address and get the section name using the start of the region but here you'd always get "PECOFF header" because they all have the same start point. The usual command repeating loop used the end address of the previous region when requesting the next, or getting the section name. So I've matched this in the --all scenario. In the example above, somehow asking for the region at 0x00007fff949a1000 would get you a region that starts at 0x00007fff949a0000 but has a different end point. Using the load address you get (what I assume is) the correct section name.
2022-05-19 19:57:44 +08:00
OptionGroupOptions m_option_group;
OptionGroupMemoryRegion m_memory_region_options;
Since our expression parser needs to locate areas of memory that are not in use when you have a process that can't JIT code, like core file debugging, the core file process plug-ins should be able to override the Process::GetMemoryRegionInfo(...) function. In order to make this happen, I have added permissions to sections so that we can know what the permissions are for a given section, and modified both core file plug-ins to override Process::GetMemoryRegionInfo() and answer things correctly. llvm-svn: 272276
2016-06-10 00:34:06 +08:00
};
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
// CommandObjectMemory
LLDB help content has accumulated over time without a recent attempt to review it for consistency, accuracy, and clarity. These changes attempt to address all of the above while keeping the text relatively terse. <rdar://problem/24868841> llvm-svn: 275485
2016-07-15 06:03:10 +08:00
CommandObjectMemory::CommandObjectMemory(CommandInterpreter &interpreter)
: CommandObjectMultiword(
interpreter, "memory",
"Commands for operating on memory in the current target process.",
"memory <subcommand> [<subcommand-options>]") {
Since our expression parser needs to locate areas of memory that are not in use when you have a process that can't JIT code, like core file debugging, the core file process plug-ins should be able to override the Process::GetMemoryRegionInfo(...) function. In order to make this happen, I have added permissions to sections so that we can know what the permissions are for a given section, and modified both core file plug-ins to override Process::GetMemoryRegionInfo() and answer things correctly. llvm-svn: 272276
2016-06-10 00:34:06 +08:00
LoadSubCommand("find",
CommandObjectSP(new CommandObjectMemoryFind(interpreter)));
LoadSubCommand("read",
CommandObjectSP(new CommandObjectMemoryRead(interpreter)));
LoadSubCommand("write",
CommandObjectSP(new CommandObjectMemoryWrite(interpreter)));
LoadSubCommand("history",
CommandObjectSP(new CommandObjectMemoryHistory(interpreter)));
LoadSubCommand("region",
CommandObjectSP(new CommandObjectMemoryRegion(interpreter)));
[lldb][AArch64] Add "memory tag read" command This new command looks much like "memory read" and mirrors its basic behaviour. (lldb) memory tag read new_buf_ptr new_buf_ptr+32 Logical tag: 0x9 Allocation tags: [0x900fffff7ffa000, 0x900fffff7ffa010): 0x9 [0x900fffff7ffa010, 0x900fffff7ffa020): 0x0 Important proprties: * The end address is optional and defaults to reading 1 tag if ommitted * It is an error to try to read tags if the architecture or process doesn't support it, or if the range asked for is not tagged. * It is an error to read an inverted range (end < begin) (logical tags are removed for this check so you can pass tagged addresses here) * The range will be expanded to fit the tagging granule, so you can get more tags than simply (end-begin)/granule size. Whatever you get back will always cover the original range. Reviewed By: omjavaid Differential Revision: https://reviews.llvm.org/D97285
2021-02-20 00:31:46 +08:00
LoadSubCommand("tag",
CommandObjectSP(new CommandObjectMemoryTag(interpreter)));
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
Fix Clang-tidy modernize-use-nullptr and modernize-use-default warnings in some files in source/Commands; other minor fixes. llvm-svn: 261389
2016-02-20 08:58:29 +08:00
CommandObjectMemory::~CommandObjectMemory() = default;