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

1452 lines
51 KiB
C++
Raw Normal View History

Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
//===-- Disassembler.cpp ----------------------------------------*- C++ -*-===//
//
// The LLVM Compiler Infrastructure
//
// This file is distributed under the University of Illinois Open Source
// License. See LICENSE.TXT for details.
//
//===----------------------------------------------------------------------===//
#include "lldb/Core/Disassembler.h"
// C Includes
// C++ Includes
Fix Clang-tidy modernize-use-nullptr warnings in some files in source/Core; other minor fixes. llvm-svn: 262570
2016-03-03 08:51:40 +08:00
#include <cstdio>
#include <cstring>
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
// Other libraries and framework includes
// Project includes
#include "lldb/Core/DataBufferHeap.h"
#include "lldb/Core/DataExtractor.h"
#include "lldb/Core/Debugger.h"
Add the rest of the mechanisms to make ARM instruction emulation usable/possible. llvm-svn: 128907
2011-04-06 02:46:00 +08:00
#include "lldb/Core/EmulateInstruction.h"
Unicode support on Win32. Win32 API calls that are Unicode aware require wide character strings, but LLDB uses UTF8 everywhere. This patch does conversions wherever necessary when passing strings into and out of Win32 API calls. Patch by Cameron Differential Revision: http://reviews.llvm.org/D17107 Reviewed By: zturner, amccarth llvm-svn: 264074
2016-03-23 01:58:09 +08:00
#include "lldb/Core/Error.h"
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
#include "lldb/Core/Module.h"
#include "lldb/Core/PluginManager.h"
Change code for reading emulation data files to read the new file format. (The newly formatted files will go in as a separate commit in a few minutes). llvm-svn: 129981
2011-04-22 13:08:45 +08:00
#include "lldb/Core/RegularExpression.h"
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
#include "lldb/Core/Timer.h"
Unicode support on Win32. Win32 API calls that are Unicode aware require wide character strings, but LLDB uses UTF8 everywhere. This patch does conversions wherever necessary when passing strings into and out of Win32 API calls. Patch by Cameron Differential Revision: http://reviews.llvm.org/D17107 Reviewed By: zturner, amccarth llvm-svn: 264074
2016-03-23 01:58:09 +08:00
#include "lldb/Host/FileSystem.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/OptionValue.h"
#include "lldb/Interpreter/OptionValueArray.h"
#include "lldb/Interpreter/OptionValueDictionary.h"
I'm experimenting with changing how the mixed source & assembly mode in lldb works. I've been discussing this with Jim Ingham, Greg Clayton, and Kate Stone for the past week or two. Previously lldb would print three source lines (centered on the line table entry line for the current line) followed by the assembly. It would print the context information (module`function + offset) before those three lines of source. Now lldb will print up to two lines before/after the line table entry. It prints two '*' characters for the line table line to make it clear what line is showing assembly. There is one line of whitespace before/after the source lines so the separation between source & assembly is clearer. I don't print the context line (module`function + offset). I stop printing context lines if it's a different line table entry, or if it's a source line I've already printed as context to another source line. If I have two line table entries one after another for the same source line (I get these often with clang - with different column information in them), I only print the source line once. I'm also using the target.process.thread.step-avoid-regexp setting (which keeps you from stepping into STL functions that have been inlined into your own code) and avoid printing any source lines from functions that match that regexp. When lldb disassembles into a new function, it will try to find the declaration line # for the function and print all of the source lines between the decl and the first line table entry (usually a { curly brace) so we have a good chance of including the arguments, at least with the debug info emitted by clang. Finally, the # of source lines of context to show has been separated from whether we're doing mixed source & assembly or not. Previously specifying 0 lines of context would turn off mixed source & assembly. I think there's room for improvement, and maybe some bugs I haven't found yet, but it's in good enough shape to upstream and iterate at this point. I'm not sure how best to indicate which source line is the actual line table # versus context lines. I'm using '**' right now. Both Kate and Greg had the initial idea to reuse '->' (normally used to indicate "currently executing source line") - I tried it but I wasn't thrilled, I'm too used to the established meaning of ->. Greg had the interesting idea of avoiding context source lines only in two line table entries in the same source file. So we'd print two lines before & after a source line, and then the next line table entry (if it was on the next source line after those two context lines) we'd display only the following two lines -- the previous two had just been printed. If an inline source line was printed between these two, though, we'd print the context lines for both of them. It's an interesting idea, and I want to see how it works with both -O0 and -O3 codegen where we have different amounts of inlining. <rdar://problem/27961419> llvm-svn: 280906
2016-09-08 13:12:41 +08:00
#include "lldb/Interpreter/OptionValueRegex.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"
#include "lldb/Interpreter/OptionValueUInt64.h"
<rdar://problem/11757916> Make breakpoint setting by file and line much more efficient by only looking for inlined breakpoint locations if we are setting a breakpoint in anything but a source implementation file. Implementing this complex for a many reasons. Turns out that parsing compile units lazily had some issues with respect to how we need to do things with DWARF in .o files. So the fixes in the checkin for this makes these changes: - Add a new setting called "target.inline-breakpoint-strategy" which can be set to "never", "always", or "headers". "never" will never try and set any inlined breakpoints (fastest). "always" always looks for inlined breakpoint locations (slowest, but most accurate). "headers", which is the default setting, will only look for inlined breakpoint locations if the breakpoint is set in what are consudered to be header files, which is realy defined as "not in an implementation source file". - modify the breakpoint setting by file and line to check the current "target.inline-breakpoint-strategy" setting and act accordingly - Modify compile units to be able to get their language and other info lazily. This allows us to create compile units from the debug map and not have to fill all of the details in, and then lazily discover this information as we go on debuggging. This is needed to avoid parsing all .o files when setting breakpoints in implementation only files (no inlines). Otherwise we would need to parse the .o file, the object file (mach-o in our case) and the symbol file (DWARF in the object file) just to see what the compile unit was. - modify the "SymbolFileDWARFDebugMap" to subclass lldb_private::Module so that the virtual "GetObjectFile()" and "GetSymbolVendor()" functions can be intercepted when the .o file contenst are later lazilly needed. Prior to this fix, when we first instantiated the "SymbolFileDWARFDebugMap" class, we would also make modules, object files and symbol files for every .o file in the debug map because we needed to fix up the sections in the .o files with information that is in the executable debug map. Now we lazily do this in the DebugMapModule::GetObjectFile() Cleaned up header includes a bit as well. llvm-svn: 162860
2012-08-30 05:13:06 +08:00
#include "lldb/Symbol/Function.h"
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
#include "lldb/Symbol/ObjectFile.h"
#include "lldb/Target/ExecutionContext.h"
#include "lldb/Target/Process.h"
For logical backtrace work, lldb needs to track Module unloads etc & symoblicate an address based on a point in time <rdar://problem/15314403> This patch adds a new lldb_private::SectionLoadHistory class that tracks what shared libraries were loaded given a process stop ID. This allows us to keep a history of the sections that were loaded for a time T. Many items in history objects will rely upon the process stop ID in the future. llvm-svn: 196557
2013-12-06 09:12:00 +08:00
#include "lldb/Target/SectionLoadList.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"
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
#include "lldb/Target/Target.h"
Unicode support on Win32. Win32 API calls that are Unicode aware require wide character strings, but LLDB uses UTF8 everywhere. This patch does conversions wherever necessary when passing strings into and out of Win32 API calls. Patch by Cameron Differential Revision: http://reviews.llvm.org/D17107 Reviewed By: zturner, amccarth llvm-svn: 264074
2016-03-23 01:58:09 +08:00
#include "lldb/lldb-private.h"
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
#define DEFAULT_DISASM_BYTE_SIZE 32
using namespace lldb;
using namespace lldb_private;
*** 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
DisassemblerSP Disassembler::FindPlugin(const ArchSpec &arch,
const char *flavor,
const char *plugin_name) {
Timer scoped_timer(LLVM_PRETTY_FUNCTION,
"Disassembler::FindPlugin (arch = %s, plugin_name = %s)",
arch.GetArchitectureName(), plugin_name);
DisassemblerCreateInstance create_callback = nullptr;
if (plugin_name) {
ConstString const_plugin_name(plugin_name);
create_callback = PluginManager::GetDisassemblerCreateCallbackForPluginName(
const_plugin_name);
if (create_callback) {
DisassemblerSP disassembler_sp(create_callback(arch, flavor));
if (disassembler_sp)
return disassembler_sp;
Cleaned up the Disassembler code a bit more. You can now request a disassembler plugin by name on the command line for when there is more than one disassembler plugin. Taught the Opcode class to dump itself so that "disassembler -b" will dump the bytes correctly for each opcode type. Modified all places that were passing the opcode bytes buffer in so that the bytes could be displayed to just pass in a bool that indicates if we should dump the opcode bytes since the opcode now lives inside llvm_private::Instruction. llvm-svn: 128290
2011-03-26 02:03:16 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
} else {
for (uint32_t idx = 0;
(create_callback = PluginManager::GetDisassemblerCreateCallbackAtIndex(
idx)) != nullptr;
++idx) {
DisassemblerSP disassembler_sp(create_callback(arch, flavor));
if (disassembler_sp)
return disassembler_sp;
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
}
return DisassemblerSP();
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
DisassemblerSP Disassembler::FindPluginForTarget(const TargetSP target_sp,
const ArchSpec &arch,
const char *flavor,
const char *plugin_name) {
if (target_sp && flavor == nullptr) {
// FIXME - we don't have the mechanism in place to do per-architecture
// settings. But since we know that for now
// we only support flavors on x86 & x86_64,
if (arch.GetTriple().getArch() == llvm::Triple::x86 ||
arch.GetTriple().getArch() == llvm::Triple::x86_64)
flavor = target_sp->GetDisassemblyFlavor();
}
return FindPlugin(arch, flavor, plugin_name);
Convert from the C-based LLVM Disassembler shim to the full MC Disassembler API's. Calculate "can branch" using the MC API's rather than our hand-rolled regex'es. As extra credit, allow setting the disassembly flavor for x86 based architectures to intel or att. <rdar://problem/11319574> <rdar://problem/9329275> llvm-svn: 176392
2013-03-02 08:26:47 +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
static void ResolveAddress(const ExecutionContext &exe_ctx, const Address &addr,
Address &resolved_addr) {
if (!addr.IsSectionOffset()) {
// If we weren't passed in a section offset address range,
// try and resolve it to something
Target *target = exe_ctx.GetTargetPtr();
if (target) {
if (target->GetSectionLoadList().IsEmpty()) {
target->GetImages().ResolveFileAddress(addr.GetOffset(), resolved_addr);
} else {
target->GetSectionLoadList().ResolveLoadAddress(addr.GetOffset(),
resolved_addr);
}
// We weren't able to resolve the address, just treat it as a
// raw address
if (resolved_addr.IsValid())
return;
Centralized all disassembly into static functions in source/Core/Disassembler.cpp. Added the ability to read memory from the target's object files when we aren't running, so disassembling works before you run! Cleaned up the API to lldb_private::Target::ReadMemory(). Cleaned up the API to the Disassembler to use actual "lldb_private::Address" objects instead of just an "addr_t". This is nice because the Address objects when resolved carry along their section and module which can get us the object file. This allows Target::ReadMemory to be used when we are not running. Added a new lldb_private::Address dump style: DumpStyleDetailedSymbolContext This will show a full breakdown of what an address points to. To see some sample output, execute a "image lookup --address <addr>". Fixed SymbolContext::DumpStopContext(...) to not require a live process in order to be able to print function and symbol offsets. llvm-svn: 107350
2010-07-01 07:03:03 +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
}
resolved_addr = addr;
Centralized all disassembly into static functions in source/Core/Disassembler.cpp. Added the ability to read memory from the target's object files when we aren't running, so disassembling works before you run! Cleaned up the API to lldb_private::Target::ReadMemory(). Cleaned up the API to the Disassembler to use actual "lldb_private::Address" objects instead of just an "addr_t". This is nice because the Address objects when resolved carry along their section and module which can get us the object file. This allows Target::ReadMemory to be used when we are not running. Added a new lldb_private::Address dump style: DumpStyleDetailedSymbolContext This will show a full breakdown of what an address points to. To see some sample output, execute a "image lookup --address <addr>". Fixed SymbolContext::DumpStopContext(...) to not require a live process in order to be able to print function and symbol offsets. llvm-svn: 107350
2010-07-01 07:03:03 +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
size_t Disassembler::Disassemble(Debugger &debugger, const ArchSpec &arch,
const char *plugin_name, const char *flavor,
const ExecutionContext &exe_ctx,
SymbolContextList &sc_list,
uint32_t num_instructions,
I'm experimenting with changing how the mixed source & assembly mode in lldb works. I've been discussing this with Jim Ingham, Greg Clayton, and Kate Stone for the past week or two. Previously lldb would print three source lines (centered on the line table entry line for the current line) followed by the assembly. It would print the context information (module`function + offset) before those three lines of source. Now lldb will print up to two lines before/after the line table entry. It prints two '*' characters for the line table line to make it clear what line is showing assembly. There is one line of whitespace before/after the source lines so the separation between source & assembly is clearer. I don't print the context line (module`function + offset). I stop printing context lines if it's a different line table entry, or if it's a source line I've already printed as context to another source line. If I have two line table entries one after another for the same source line (I get these often with clang - with different column information in them), I only print the source line once. I'm also using the target.process.thread.step-avoid-regexp setting (which keeps you from stepping into STL functions that have been inlined into your own code) and avoid printing any source lines from functions that match that regexp. When lldb disassembles into a new function, it will try to find the declaration line # for the function and print all of the source lines between the decl and the first line table entry (usually a { curly brace) so we have a good chance of including the arguments, at least with the debug info emitted by clang. Finally, the # of source lines of context to show has been separated from whether we're doing mixed source & assembly or not. Previously specifying 0 lines of context would turn off mixed source & assembly. I think there's room for improvement, and maybe some bugs I haven't found yet, but it's in good enough shape to upstream and iterate at this point. I'm not sure how best to indicate which source line is the actual line table # versus context lines. I'm using '**' right now. Both Kate and Greg had the initial idea to reuse '->' (normally used to indicate "currently executing source line") - I tried it but I wasn't thrilled, I'm too used to the established meaning of ->. Greg had the interesting idea of avoiding context source lines only in two line table entries in the same source file. So we'd print two lines before & after a source line, and then the next line table entry (if it was on the next source line after those two context lines) we'd display only the following two lines -- the previous two had just been printed. If an inline source line was printed between these two, though, we'd print the context lines for both of them. It's an interesting idea, and I want to see how it works with both -O0 and -O3 codegen where we have different amounts of inlining. <rdar://problem/27961419> llvm-svn: 280906
2016-09-08 13:12:41 +08:00
bool mixed_source_and_assembly,
*** 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
uint32_t num_mixed_context_lines,
uint32_t options, Stream &strm) {
size_t success_count = 0;
const size_t count = sc_list.GetSize();
SymbolContext sc;
AddressRange range;
const uint32_t scope =
eSymbolContextBlock | eSymbolContextFunction | eSymbolContextSymbol;
const bool use_inline_block_range = true;
for (size_t i = 0; i < count; ++i) {
if (!sc_list.GetContextAtIndex(i, sc))
break;
for (uint32_t range_idx = 0;
sc.GetAddressRange(scope, range_idx, use_inline_block_range, range);
++range_idx) {
if (Disassemble(debugger, arch, plugin_name, flavor, exe_ctx, range,
I'm experimenting with changing how the mixed source & assembly mode in lldb works. I've been discussing this with Jim Ingham, Greg Clayton, and Kate Stone for the past week or two. Previously lldb would print three source lines (centered on the line table entry line for the current line) followed by the assembly. It would print the context information (module`function + offset) before those three lines of source. Now lldb will print up to two lines before/after the line table entry. It prints two '*' characters for the line table line to make it clear what line is showing assembly. There is one line of whitespace before/after the source lines so the separation between source & assembly is clearer. I don't print the context line (module`function + offset). I stop printing context lines if it's a different line table entry, or if it's a source line I've already printed as context to another source line. If I have two line table entries one after another for the same source line (I get these often with clang - with different column information in them), I only print the source line once. I'm also using the target.process.thread.step-avoid-regexp setting (which keeps you from stepping into STL functions that have been inlined into your own code) and avoid printing any source lines from functions that match that regexp. When lldb disassembles into a new function, it will try to find the declaration line # for the function and print all of the source lines between the decl and the first line table entry (usually a { curly brace) so we have a good chance of including the arguments, at least with the debug info emitted by clang. Finally, the # of source lines of context to show has been separated from whether we're doing mixed source & assembly or not. Previously specifying 0 lines of context would turn off mixed source & assembly. I think there's room for improvement, and maybe some bugs I haven't found yet, but it's in good enough shape to upstream and iterate at this point. I'm not sure how best to indicate which source line is the actual line table # versus context lines. I'm using '**' right now. Both Kate and Greg had the initial idea to reuse '->' (normally used to indicate "currently executing source line") - I tried it but I wasn't thrilled, I'm too used to the established meaning of ->. Greg had the interesting idea of avoiding context source lines only in two line table entries in the same source file. So we'd print two lines before & after a source line, and then the next line table entry (if it was on the next source line after those two context lines) we'd display only the following two lines -- the previous two had just been printed. If an inline source line was printed between these two, though, we'd print the context lines for both of them. It's an interesting idea, and I want to see how it works with both -O0 and -O3 codegen where we have different amounts of inlining. <rdar://problem/27961419> llvm-svn: 280906
2016-09-08 13:12:41 +08:00
num_instructions, mixed_source_and_assembly,
num_mixed_context_lines, options, strm)) {
*** 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
++success_count;
strm.EOL();
}
Changed the SymbolFile::FindFunction() function calls to only return lldb_private::Function objects. Previously the SymbolFileSymtab subclass would return lldb_private::Symbol objects when it was asked to find functions. The Module::FindFunctions (...) now take a boolean "bool include_symbols" so that the module can track down functions and symbols, yet functions are found by the SymbolFile plug-ins (through the SymbolVendor class), and symbols are gotten through the ObjectFile plug-ins. Fixed and issue where the DWARF parser might run into incomplete class member function defintions which would make clang mad when we tried to make certain member functions with invalid number of parameters (such as an operator= operator that had no parameters). Now we just avoid and don't complete these incomplete functions. llvm-svn: 124359
2011-01-27 14:44:37 +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
}
return success_count;
Centralized all disassembly into static functions in source/Core/Disassembler.cpp. Added the ability to read memory from the target's object files when we aren't running, so disassembling works before you run! Cleaned up the API to lldb_private::Target::ReadMemory(). Cleaned up the API to the Disassembler to use actual "lldb_private::Address" objects instead of just an "addr_t". This is nice because the Address objects when resolved carry along their section and module which can get us the object file. This allows Target::ReadMemory to be used when we are not running. Added a new lldb_private::Address dump style: DumpStyleDetailedSymbolContext This will show a full breakdown of what an address points to. To see some sample output, execute a "image lookup --address <addr>". Fixed SymbolContext::DumpStopContext(...) to not require a live process in order to be able to print function and symbol offsets. llvm-svn: 107350
2010-07-01 07:03:03 +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
bool Disassembler::Disassemble(Debugger &debugger, const ArchSpec &arch,
const char *plugin_name, const char *flavor,
Fix Clang-tidy modernize-use-nullptr warnings in some files in source/Core; other minor fixes. llvm-svn: 262570
2016-03-03 08:51:40 +08:00
const ExecutionContext &exe_ctx,
*** 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
const ConstString &name, Module *module,
uint32_t num_instructions,
I'm experimenting with changing how the mixed source & assembly mode in lldb works. I've been discussing this with Jim Ingham, Greg Clayton, and Kate Stone for the past week or two. Previously lldb would print three source lines (centered on the line table entry line for the current line) followed by the assembly. It would print the context information (module`function + offset) before those three lines of source. Now lldb will print up to two lines before/after the line table entry. It prints two '*' characters for the line table line to make it clear what line is showing assembly. There is one line of whitespace before/after the source lines so the separation between source & assembly is clearer. I don't print the context line (module`function + offset). I stop printing context lines if it's a different line table entry, or if it's a source line I've already printed as context to another source line. If I have two line table entries one after another for the same source line (I get these often with clang - with different column information in them), I only print the source line once. I'm also using the target.process.thread.step-avoid-regexp setting (which keeps you from stepping into STL functions that have been inlined into your own code) and avoid printing any source lines from functions that match that regexp. When lldb disassembles into a new function, it will try to find the declaration line # for the function and print all of the source lines between the decl and the first line table entry (usually a { curly brace) so we have a good chance of including the arguments, at least with the debug info emitted by clang. Finally, the # of source lines of context to show has been separated from whether we're doing mixed source & assembly or not. Previously specifying 0 lines of context would turn off mixed source & assembly. I think there's room for improvement, and maybe some bugs I haven't found yet, but it's in good enough shape to upstream and iterate at this point. I'm not sure how best to indicate which source line is the actual line table # versus context lines. I'm using '**' right now. Both Kate and Greg had the initial idea to reuse '->' (normally used to indicate "currently executing source line") - I tried it but I wasn't thrilled, I'm too used to the established meaning of ->. Greg had the interesting idea of avoiding context source lines only in two line table entries in the same source file. So we'd print two lines before & after a source line, and then the next line table entry (if it was on the next source line after those two context lines) we'd display only the following two lines -- the previous two had just been printed. If an inline source line was printed between these two, though, we'd print the context lines for both of them. It's an interesting idea, and I want to see how it works with both -O0 and -O3 codegen where we have different amounts of inlining. <rdar://problem/27961419> llvm-svn: 280906
2016-09-08 13:12:41 +08:00
bool mixed_source_and_assembly,
*** 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
uint32_t num_mixed_context_lines,
uint32_t options, Stream &strm) {
SymbolContextList sc_list;
if (name) {
const bool include_symbols = true;
const bool include_inlines = true;
if (module) {
module->FindFunctions(name, nullptr, eFunctionNameTypeAuto,
include_symbols, include_inlines, true, sc_list);
} else if (exe_ctx.GetTargetPtr()) {
exe_ctx.GetTargetPtr()->GetImages().FindFunctions(
name, eFunctionNameTypeAuto, include_symbols, include_inlines, false,
sc_list);
Added the ability to get the disassembly instructions from the function and symbol. llvm-svn: 115734
2010-10-06 11:09:58 +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
}
if (sc_list.GetSize()) {
return Disassemble(debugger, arch, plugin_name, flavor, exe_ctx, sc_list,
I'm experimenting with changing how the mixed source & assembly mode in lldb works. I've been discussing this with Jim Ingham, Greg Clayton, and Kate Stone for the past week or two. Previously lldb would print three source lines (centered on the line table entry line for the current line) followed by the assembly. It would print the context information (module`function + offset) before those three lines of source. Now lldb will print up to two lines before/after the line table entry. It prints two '*' characters for the line table line to make it clear what line is showing assembly. There is one line of whitespace before/after the source lines so the separation between source & assembly is clearer. I don't print the context line (module`function + offset). I stop printing context lines if it's a different line table entry, or if it's a source line I've already printed as context to another source line. If I have two line table entries one after another for the same source line (I get these often with clang - with different column information in them), I only print the source line once. I'm also using the target.process.thread.step-avoid-regexp setting (which keeps you from stepping into STL functions that have been inlined into your own code) and avoid printing any source lines from functions that match that regexp. When lldb disassembles into a new function, it will try to find the declaration line # for the function and print all of the source lines between the decl and the first line table entry (usually a { curly brace) so we have a good chance of including the arguments, at least with the debug info emitted by clang. Finally, the # of source lines of context to show has been separated from whether we're doing mixed source & assembly or not. Previously specifying 0 lines of context would turn off mixed source & assembly. I think there's room for improvement, and maybe some bugs I haven't found yet, but it's in good enough shape to upstream and iterate at this point. I'm not sure how best to indicate which source line is the actual line table # versus context lines. I'm using '**' right now. Both Kate and Greg had the initial idea to reuse '->' (normally used to indicate "currently executing source line") - I tried it but I wasn't thrilled, I'm too used to the established meaning of ->. Greg had the interesting idea of avoiding context source lines only in two line table entries in the same source file. So we'd print two lines before & after a source line, and then the next line table entry (if it was on the next source line after those two context lines) we'd display only the following two lines -- the previous two had just been printed. If an inline source line was printed between these two, though, we'd print the context lines for both of them. It's an interesting idea, and I want to see how it works with both -O0 and -O3 codegen where we have different amounts of inlining. <rdar://problem/27961419> llvm-svn: 280906
2016-09-08 13:12:41 +08:00
num_instructions, mixed_source_and_assembly,
num_mixed_context_lines, options, strm);
*** 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
}
return false;
Added the ability to get the disassembly instructions from the function and symbol. llvm-svn: 115734
2010-10-06 11:09:58 +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
lldb::DisassemblerSP Disassembler::DisassembleRange(
const ArchSpec &arch, const char *plugin_name, const char *flavor,
const ExecutionContext &exe_ctx, const AddressRange &range,
bool prefer_file_cache) {
lldb::DisassemblerSP disasm_sp;
if (range.GetByteSize() > 0 && range.GetBaseAddress().IsValid()) {
disasm_sp = Disassembler::FindPluginForTarget(exe_ctx.GetTargetSP(), arch,
flavor, plugin_name);
if (disasm_sp) {
size_t bytes_disassembled = disasm_sp->ParseInstructions(
&exe_ctx, range, nullptr, prefer_file_cache);
if (bytes_disassembled == 0)
disasm_sp.reset();
I have added a function to SBTarget that allows clients to disassemble a series of raw bytes as demonstrated by a new testcase. In the future, this API will also allow clients to provide a callback that adds comments for addresses in the disassembly. I also modified the SWIG harness to ensure that Python ByteArrays work as well as strings as sources of raw data. llvm-svn: 146611
2011-12-15 07:49:37 +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
}
return disasm_sp;
I have added a function to SBTarget that allows clients to disassemble a series of raw bytes as demonstrated by a new testcase. In the future, this API will also allow clients to provide a callback that adds comments for addresses in the disassembly. I also modified the SWIG harness to ensure that Python ByteArrays work as well as strings as sources of raw data. llvm-svn: 146611
2011-12-15 07:49:37 +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
lldb::DisassemblerSP
Disassembler::DisassembleBytes(const ArchSpec &arch, const char *plugin_name,
const char *flavor, const Address &start,
const void *src, size_t src_len,
uint32_t num_instructions, bool data_from_file) {
lldb::DisassemblerSP disasm_sp;
if (src) {
disasm_sp = Disassembler::FindPlugin(arch, flavor, plugin_name);
if (disasm_sp) {
DataExtractor data(src, src_len, arch.GetByteOrder(),
arch.GetAddressByteSize());
(void)disasm_sp->DecodeInstructions(start, data, 0, num_instructions,
false, data_from_file);
Add the ability to disassemble "n" instructions from the current PC, or the first "n" instructions in a function. Also added a "-p" flag that disassembles from the current pc. llvm-svn: 128063
2011-03-22 09:48:42 +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
}
return disasm_sp;
Add the ability to disassemble "n" instructions from the current PC, or the first "n" instructions in a function. Also added a "-p" flag that disassembles from the current pc. llvm-svn: 128063
2011-03-22 09:48:42 +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
bool Disassembler::Disassemble(Debugger &debugger, const ArchSpec &arch,
const char *plugin_name, const char *flavor,
const ExecutionContext &exe_ctx,
const AddressRange &disasm_range,
uint32_t num_instructions,
I'm experimenting with changing how the mixed source & assembly mode in lldb works. I've been discussing this with Jim Ingham, Greg Clayton, and Kate Stone for the past week or two. Previously lldb would print three source lines (centered on the line table entry line for the current line) followed by the assembly. It would print the context information (module`function + offset) before those three lines of source. Now lldb will print up to two lines before/after the line table entry. It prints two '*' characters for the line table line to make it clear what line is showing assembly. There is one line of whitespace before/after the source lines so the separation between source & assembly is clearer. I don't print the context line (module`function + offset). I stop printing context lines if it's a different line table entry, or if it's a source line I've already printed as context to another source line. If I have two line table entries one after another for the same source line (I get these often with clang - with different column information in them), I only print the source line once. I'm also using the target.process.thread.step-avoid-regexp setting (which keeps you from stepping into STL functions that have been inlined into your own code) and avoid printing any source lines from functions that match that regexp. When lldb disassembles into a new function, it will try to find the declaration line # for the function and print all of the source lines between the decl and the first line table entry (usually a { curly brace) so we have a good chance of including the arguments, at least with the debug info emitted by clang. Finally, the # of source lines of context to show has been separated from whether we're doing mixed source & assembly or not. Previously specifying 0 lines of context would turn off mixed source & assembly. I think there's room for improvement, and maybe some bugs I haven't found yet, but it's in good enough shape to upstream and iterate at this point. I'm not sure how best to indicate which source line is the actual line table # versus context lines. I'm using '**' right now. Both Kate and Greg had the initial idea to reuse '->' (normally used to indicate "currently executing source line") - I tried it but I wasn't thrilled, I'm too used to the established meaning of ->. Greg had the interesting idea of avoiding context source lines only in two line table entries in the same source file. So we'd print two lines before & after a source line, and then the next line table entry (if it was on the next source line after those two context lines) we'd display only the following two lines -- the previous two had just been printed. If an inline source line was printed between these two, though, we'd print the context lines for both of them. It's an interesting idea, and I want to see how it works with both -O0 and -O3 codegen where we have different amounts of inlining. <rdar://problem/27961419> llvm-svn: 280906
2016-09-08 13:12:41 +08:00
bool mixed_source_and_assembly,
*** 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
uint32_t num_mixed_context_lines,
uint32_t options, Stream &strm) {
if (disasm_range.GetByteSize()) {
lldb::DisassemblerSP disasm_sp(Disassembler::FindPluginForTarget(
exe_ctx.GetTargetSP(), arch, flavor, plugin_name));
if (disasm_sp) {
AddressRange range;
ResolveAddress(exe_ctx, disasm_range.GetBaseAddress(),
range.GetBaseAddress());
range.SetByteSize(disasm_range.GetByteSize());
const bool prefer_file_cache = false;
size_t bytes_disassembled = disasm_sp->ParseInstructions(
&exe_ctx, range, &strm, prefer_file_cache);
if (bytes_disassembled == 0)
return false;
return PrintInstructions(disasm_sp.get(), debugger, arch, exe_ctx,
I'm experimenting with changing how the mixed source & assembly mode in lldb works. I've been discussing this with Jim Ingham, Greg Clayton, and Kate Stone for the past week or two. Previously lldb would print three source lines (centered on the line table entry line for the current line) followed by the assembly. It would print the context information (module`function + offset) before those three lines of source. Now lldb will print up to two lines before/after the line table entry. It prints two '*' characters for the line table line to make it clear what line is showing assembly. There is one line of whitespace before/after the source lines so the separation between source & assembly is clearer. I don't print the context line (module`function + offset). I stop printing context lines if it's a different line table entry, or if it's a source line I've already printed as context to another source line. If I have two line table entries one after another for the same source line (I get these often with clang - with different column information in them), I only print the source line once. I'm also using the target.process.thread.step-avoid-regexp setting (which keeps you from stepping into STL functions that have been inlined into your own code) and avoid printing any source lines from functions that match that regexp. When lldb disassembles into a new function, it will try to find the declaration line # for the function and print all of the source lines between the decl and the first line table entry (usually a { curly brace) so we have a good chance of including the arguments, at least with the debug info emitted by clang. Finally, the # of source lines of context to show has been separated from whether we're doing mixed source & assembly or not. Previously specifying 0 lines of context would turn off mixed source & assembly. I think there's room for improvement, and maybe some bugs I haven't found yet, but it's in good enough shape to upstream and iterate at this point. I'm not sure how best to indicate which source line is the actual line table # versus context lines. I'm using '**' right now. Both Kate and Greg had the initial idea to reuse '->' (normally used to indicate "currently executing source line") - I tried it but I wasn't thrilled, I'm too used to the established meaning of ->. Greg had the interesting idea of avoiding context source lines only in two line table entries in the same source file. So we'd print two lines before & after a source line, and then the next line table entry (if it was on the next source line after those two context lines) we'd display only the following two lines -- the previous two had just been printed. If an inline source line was printed between these two, though, we'd print the context lines for both of them. It's an interesting idea, and I want to see how it works with both -O0 and -O3 codegen where we have different amounts of inlining. <rdar://problem/27961419> llvm-svn: 280906
2016-09-08 13:12:41 +08:00
num_instructions, mixed_source_and_assembly,
num_mixed_context_lines, options, strm);
Add the ability to disassemble "n" instructions from the current PC, or the first "n" instructions in a function. Also added a "-p" flag that disassembles from the current pc. llvm-svn: 128063
2011-03-22 09:48:42 +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
}
return false;
Add the ability to disassemble "n" instructions from the current PC, or the first "n" instructions in a function. Also added a "-p" flag that disassembles from the current pc. llvm-svn: 128063
2011-03-22 09:48:42 +08:00
}
Now that there are no cycles that cause leaks in the disassembler/instruction classes, we can get rid of the FIXME lines that were working around this issue. <rdar://problem/26684190> llvm-svn: 272071
2016-06-08 07:19:00 +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
bool Disassembler::Disassemble(Debugger &debugger, const ArchSpec &arch,
const char *plugin_name, const char *flavor,
const ExecutionContext &exe_ctx,
const Address &start_address,
uint32_t num_instructions,
I'm experimenting with changing how the mixed source & assembly mode in lldb works. I've been discussing this with Jim Ingham, Greg Clayton, and Kate Stone for the past week or two. Previously lldb would print three source lines (centered on the line table entry line for the current line) followed by the assembly. It would print the context information (module`function + offset) before those three lines of source. Now lldb will print up to two lines before/after the line table entry. It prints two '*' characters for the line table line to make it clear what line is showing assembly. There is one line of whitespace before/after the source lines so the separation between source & assembly is clearer. I don't print the context line (module`function + offset). I stop printing context lines if it's a different line table entry, or if it's a source line I've already printed as context to another source line. If I have two line table entries one after another for the same source line (I get these often with clang - with different column information in them), I only print the source line once. I'm also using the target.process.thread.step-avoid-regexp setting (which keeps you from stepping into STL functions that have been inlined into your own code) and avoid printing any source lines from functions that match that regexp. When lldb disassembles into a new function, it will try to find the declaration line # for the function and print all of the source lines between the decl and the first line table entry (usually a { curly brace) so we have a good chance of including the arguments, at least with the debug info emitted by clang. Finally, the # of source lines of context to show has been separated from whether we're doing mixed source & assembly or not. Previously specifying 0 lines of context would turn off mixed source & assembly. I think there's room for improvement, and maybe some bugs I haven't found yet, but it's in good enough shape to upstream and iterate at this point. I'm not sure how best to indicate which source line is the actual line table # versus context lines. I'm using '**' right now. Both Kate and Greg had the initial idea to reuse '->' (normally used to indicate "currently executing source line") - I tried it but I wasn't thrilled, I'm too used to the established meaning of ->. Greg had the interesting idea of avoiding context source lines only in two line table entries in the same source file. So we'd print two lines before & after a source line, and then the next line table entry (if it was on the next source line after those two context lines) we'd display only the following two lines -- the previous two had just been printed. If an inline source line was printed between these two, though, we'd print the context lines for both of them. It's an interesting idea, and I want to see how it works with both -O0 and -O3 codegen where we have different amounts of inlining. <rdar://problem/27961419> llvm-svn: 280906
2016-09-08 13:12:41 +08:00
bool mixed_source_and_assembly,
*** 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
uint32_t num_mixed_context_lines,
uint32_t options, Stream &strm) {
if (num_instructions > 0) {
lldb::DisassemblerSP disasm_sp(Disassembler::FindPluginForTarget(
exe_ctx.GetTargetSP(), arch, flavor, plugin_name));
if (disasm_sp) {
Address addr;
ResolveAddress(exe_ctx, start_address, addr);
const bool prefer_file_cache = false;
size_t bytes_disassembled = disasm_sp->ParseInstructions(
&exe_ctx, addr, num_instructions, prefer_file_cache);
if (bytes_disassembled == 0)
return false;
return PrintInstructions(disasm_sp.get(), debugger, arch, exe_ctx,
I'm experimenting with changing how the mixed source & assembly mode in lldb works. I've been discussing this with Jim Ingham, Greg Clayton, and Kate Stone for the past week or two. Previously lldb would print three source lines (centered on the line table entry line for the current line) followed by the assembly. It would print the context information (module`function + offset) before those three lines of source. Now lldb will print up to two lines before/after the line table entry. It prints two '*' characters for the line table line to make it clear what line is showing assembly. There is one line of whitespace before/after the source lines so the separation between source & assembly is clearer. I don't print the context line (module`function + offset). I stop printing context lines if it's a different line table entry, or if it's a source line I've already printed as context to another source line. If I have two line table entries one after another for the same source line (I get these often with clang - with different column information in them), I only print the source line once. I'm also using the target.process.thread.step-avoid-regexp setting (which keeps you from stepping into STL functions that have been inlined into your own code) and avoid printing any source lines from functions that match that regexp. When lldb disassembles into a new function, it will try to find the declaration line # for the function and print all of the source lines between the decl and the first line table entry (usually a { curly brace) so we have a good chance of including the arguments, at least with the debug info emitted by clang. Finally, the # of source lines of context to show has been separated from whether we're doing mixed source & assembly or not. Previously specifying 0 lines of context would turn off mixed source & assembly. I think there's room for improvement, and maybe some bugs I haven't found yet, but it's in good enough shape to upstream and iterate at this point. I'm not sure how best to indicate which source line is the actual line table # versus context lines. I'm using '**' right now. Both Kate and Greg had the initial idea to reuse '->' (normally used to indicate "currently executing source line") - I tried it but I wasn't thrilled, I'm too used to the established meaning of ->. Greg had the interesting idea of avoiding context source lines only in two line table entries in the same source file. So we'd print two lines before & after a source line, and then the next line table entry (if it was on the next source line after those two context lines) we'd display only the following two lines -- the previous two had just been printed. If an inline source line was printed between these two, though, we'd print the context lines for both of them. It's an interesting idea, and I want to see how it works with both -O0 and -O3 codegen where we have different amounts of inlining. <rdar://problem/27961419> llvm-svn: 280906
2016-09-08 13:12:41 +08:00
num_instructions, mixed_source_and_assembly,
num_mixed_context_lines, options, strm);
Change the default disassembly format again. First attempt at changing it was in r219544 - after living on that for a few months, I wanted to take another crack at this. The disassembly-format setting still exists and the old format can be user specified with a setting like ${current-pc-arrow}${addr-file-or-load}{ <${function.name-without-args}${function.concrete-only-addr-offset-no-padding}>}: This patch was discussed in http://reviews.llvm.org/D7578 <rdar://problem/19726421> llvm-svn: 229186
2015-02-14 07:24:21 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
}
return false;
}
Change the default disassembly format again. First attempt at changing it was in r219544 - after living on that for a few months, I wanted to take another crack at this. The disassembly-format setting still exists and the old format can be user specified with a setting like ${current-pc-arrow}${addr-file-or-load}{ <${function.name-without-args}${function.concrete-only-addr-offset-no-padding}>}: This patch was discussed in http://reviews.llvm.org/D7578 <rdar://problem/19726421> llvm-svn: 229186
2015-02-14 07:24:21 +08:00
I'm experimenting with changing how the mixed source & assembly mode in lldb works. I've been discussing this with Jim Ingham, Greg Clayton, and Kate Stone for the past week or two. Previously lldb would print three source lines (centered on the line table entry line for the current line) followed by the assembly. It would print the context information (module`function + offset) before those three lines of source. Now lldb will print up to two lines before/after the line table entry. It prints two '*' characters for the line table line to make it clear what line is showing assembly. There is one line of whitespace before/after the source lines so the separation between source & assembly is clearer. I don't print the context line (module`function + offset). I stop printing context lines if it's a different line table entry, or if it's a source line I've already printed as context to another source line. If I have two line table entries one after another for the same source line (I get these often with clang - with different column information in them), I only print the source line once. I'm also using the target.process.thread.step-avoid-regexp setting (which keeps you from stepping into STL functions that have been inlined into your own code) and avoid printing any source lines from functions that match that regexp. When lldb disassembles into a new function, it will try to find the declaration line # for the function and print all of the source lines between the decl and the first line table entry (usually a { curly brace) so we have a good chance of including the arguments, at least with the debug info emitted by clang. Finally, the # of source lines of context to show has been separated from whether we're doing mixed source & assembly or not. Previously specifying 0 lines of context would turn off mixed source & assembly. I think there's room for improvement, and maybe some bugs I haven't found yet, but it's in good enough shape to upstream and iterate at this point. I'm not sure how best to indicate which source line is the actual line table # versus context lines. I'm using '**' right now. Both Kate and Greg had the initial idea to reuse '->' (normally used to indicate "currently executing source line") - I tried it but I wasn't thrilled, I'm too used to the established meaning of ->. Greg had the interesting idea of avoiding context source lines only in two line table entries in the same source file. So we'd print two lines before & after a source line, and then the next line table entry (if it was on the next source line after those two context lines) we'd display only the following two lines -- the previous two had just been printed. If an inline source line was printed between these two, though, we'd print the context lines for both of them. It's an interesting idea, and I want to see how it works with both -O0 and -O3 codegen where we have different amounts of inlining. <rdar://problem/27961419> llvm-svn: 280906
2016-09-08 13:12:41 +08:00
Disassembler::SourceLine
Disassembler::GetFunctionDeclLineEntry(const SymbolContext &sc) {
SourceLine decl_line;
if (sc.function && sc.line_entry.IsValid()) {
LineEntry prologue_end_line = sc.line_entry;
FileSpec func_decl_file;
uint32_t func_decl_line;
sc.function->GetStartLineSourceInfo(func_decl_file, func_decl_line);
if (func_decl_file == prologue_end_line.file ||
func_decl_file == prologue_end_line.original_file) {
decl_line.file = func_decl_file;
decl_line.line = func_decl_line;
add stop column highlighting support This change introduces optional marking of the column within a source line where a thread is stopped. This marking will show up when the source code for a thread stop is displayed, when the debug info knows the column information, and if the optional column marking is enabled. There are two separate methods for handling the marking of the stop column: * via ANSI terminal codes, which are added inline to the source line display. The default ANSI mark-up is to underline the column. * via a pure text-based caret that is added in the appropriate column in a newly-inserted blank line underneath the source line in question. There are some new options that control how this all works. * settings set stop-show-column This takes one of 4 values: * ansi-or-caret: use the ANSI terminal code mechanism if LLDB is running with color enabled; if not, use the caret-based, pure text method (see the "caret" mode below). * ansi: only use the ANSI terminal code mechanism to highlight the stop line. If LLDB is running with color disabled, no stop column marking will occur. * caret: only use the pure text caret method, which introduces a newly-inserted line underneath the current line, where the only character in the new line is a caret that highlights the stop column in question. * none: no stop column marking will be attempted. * settings set stop-show-column-ansi-prefix This is a text format that indicates the ANSI formatting code to insert into the stream immediately preceding the column where the stop column character will be marked up. It defaults to ${ansi.underline}; however, it can contain any valid LLDB format codes, e.g. ${ansi.fg.red}${ansi.bold}${ansi.underline} * settings set stop-show-column-ansi-suffix This is the text format that specifies the ANSI terminal codes to end the markup that was started with the prefix described above. It defaults to: ${ansi.normal}. This should be sufficient for the common cases. Significant leg-work was done by Adrian Prantl. (Thanks, Adrian!) differential review: https://reviews.llvm.org/D20835 reviewers: clayborg, jingham llvm-svn: 282105
2016-09-22 04:13:14 +08:00
// TODO do we care about column on these entries? If so, we need to
// plumb that through GetStartLineSourceInfo.
decl_line.column = 0;
I'm experimenting with changing how the mixed source & assembly mode in lldb works. I've been discussing this with Jim Ingham, Greg Clayton, and Kate Stone for the past week or two. Previously lldb would print three source lines (centered on the line table entry line for the current line) followed by the assembly. It would print the context information (module`function + offset) before those three lines of source. Now lldb will print up to two lines before/after the line table entry. It prints two '*' characters for the line table line to make it clear what line is showing assembly. There is one line of whitespace before/after the source lines so the separation between source & assembly is clearer. I don't print the context line (module`function + offset). I stop printing context lines if it's a different line table entry, or if it's a source line I've already printed as context to another source line. If I have two line table entries one after another for the same source line (I get these often with clang - with different column information in them), I only print the source line once. I'm also using the target.process.thread.step-avoid-regexp setting (which keeps you from stepping into STL functions that have been inlined into your own code) and avoid printing any source lines from functions that match that regexp. When lldb disassembles into a new function, it will try to find the declaration line # for the function and print all of the source lines between the decl and the first line table entry (usually a { curly brace) so we have a good chance of including the arguments, at least with the debug info emitted by clang. Finally, the # of source lines of context to show has been separated from whether we're doing mixed source & assembly or not. Previously specifying 0 lines of context would turn off mixed source & assembly. I think there's room for improvement, and maybe some bugs I haven't found yet, but it's in good enough shape to upstream and iterate at this point. I'm not sure how best to indicate which source line is the actual line table # versus context lines. I'm using '**' right now. Both Kate and Greg had the initial idea to reuse '->' (normally used to indicate "currently executing source line") - I tried it but I wasn't thrilled, I'm too used to the established meaning of ->. Greg had the interesting idea of avoiding context source lines only in two line table entries in the same source file. So we'd print two lines before & after a source line, and then the next line table entry (if it was on the next source line after those two context lines) we'd display only the following two lines -- the previous two had just been printed. If an inline source line was printed between these two, though, we'd print the context lines for both of them. It's an interesting idea, and I want to see how it works with both -O0 and -O3 codegen where we have different amounts of inlining. <rdar://problem/27961419> llvm-svn: 280906
2016-09-08 13:12:41 +08:00
}
}
return decl_line;
}
void Disassembler::AddLineToSourceLineTables(
SourceLine &line,
std::map<FileSpec, std::set<uint32_t>> &source_lines_seen) {
if (line.IsValid()) {
auto source_lines_seen_pos = source_lines_seen.find(line.file);
if (source_lines_seen_pos == source_lines_seen.end()) {
std::set<uint32_t> lines;
lines.insert(line.line);
source_lines_seen.emplace(line.file, lines);
} else {
source_lines_seen_pos->second.insert(line.line);
}
}
}
bool Disassembler::ElideMixedSourceAndDisassemblyLine(
const ExecutionContext &exe_ctx, const SymbolContext &sc,
SourceLine &line) {
// TODO: should we also check target.process.thread.step-avoid-libraries ?
const RegularExpression *avoid_regex = nullptr;
// Skip any line #0 entries - they are implementation details
if (line.line == 0)
return false;
ThreadSP thread_sp = exe_ctx.GetThreadSP();
if (thread_sp) {
avoid_regex = thread_sp->GetSymbolsToAvoidRegexp();
} else {
TargetSP target_sp = exe_ctx.GetTargetSP();
if (target_sp) {
Error error;
OptionValueSP value_sp = target_sp->GetDebugger().GetPropertyValue(
&exe_ctx, "target.process.thread.step-avoid-regexp", false, error);
if (value_sp && value_sp->GetType() == OptionValue::eTypeRegex) {
OptionValueRegex *re = value_sp->GetAsRegex();
if (re) {
avoid_regex = re->GetCurrentValue();
}
}
}
}
if (avoid_regex && sc.symbol != nullptr) {
const char *function_name =
sc.GetFunctionName(Mangled::ePreferDemangledWithoutArguments)
.GetCString();
if (function_name) {
RegularExpression::Match regex_match(1);
if (avoid_regex->Execute(function_name, &regex_match)) {
// skip this source line
return true;
}
}
}
// don't skip this source line
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
bool Disassembler::PrintInstructions(Disassembler *disasm_ptr,
Debugger &debugger, const ArchSpec &arch,
const ExecutionContext &exe_ctx,
uint32_t num_instructions,
I'm experimenting with changing how the mixed source & assembly mode in lldb works. I've been discussing this with Jim Ingham, Greg Clayton, and Kate Stone for the past week or two. Previously lldb would print three source lines (centered on the line table entry line for the current line) followed by the assembly. It would print the context information (module`function + offset) before those three lines of source. Now lldb will print up to two lines before/after the line table entry. It prints two '*' characters for the line table line to make it clear what line is showing assembly. There is one line of whitespace before/after the source lines so the separation between source & assembly is clearer. I don't print the context line (module`function + offset). I stop printing context lines if it's a different line table entry, or if it's a source line I've already printed as context to another source line. If I have two line table entries one after another for the same source line (I get these often with clang - with different column information in them), I only print the source line once. I'm also using the target.process.thread.step-avoid-regexp setting (which keeps you from stepping into STL functions that have been inlined into your own code) and avoid printing any source lines from functions that match that regexp. When lldb disassembles into a new function, it will try to find the declaration line # for the function and print all of the source lines between the decl and the first line table entry (usually a { curly brace) so we have a good chance of including the arguments, at least with the debug info emitted by clang. Finally, the # of source lines of context to show has been separated from whether we're doing mixed source & assembly or not. Previously specifying 0 lines of context would turn off mixed source & assembly. I think there's room for improvement, and maybe some bugs I haven't found yet, but it's in good enough shape to upstream and iterate at this point. I'm not sure how best to indicate which source line is the actual line table # versus context lines. I'm using '**' right now. Both Kate and Greg had the initial idea to reuse '->' (normally used to indicate "currently executing source line") - I tried it but I wasn't thrilled, I'm too used to the established meaning of ->. Greg had the interesting idea of avoiding context source lines only in two line table entries in the same source file. So we'd print two lines before & after a source line, and then the next line table entry (if it was on the next source line after those two context lines) we'd display only the following two lines -- the previous two had just been printed. If an inline source line was printed between these two, though, we'd print the context lines for both of them. It's an interesting idea, and I want to see how it works with both -O0 and -O3 codegen where we have different amounts of inlining. <rdar://problem/27961419> llvm-svn: 280906
2016-09-08 13:12:41 +08:00
bool mixed_source_and_assembly,
*** 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
uint32_t num_mixed_context_lines,
uint32_t options, Stream &strm) {
// We got some things disassembled...
size_t num_instructions_found = disasm_ptr->GetInstructionList().GetSize();
if (num_instructions > 0 && num_instructions < num_instructions_found)
num_instructions_found = num_instructions;
const uint32_t max_opcode_byte_size =
disasm_ptr->GetInstructionList().GetMaxOpcocdeByteSize();
SymbolContext sc;
SymbolContext prev_sc;
I'm experimenting with changing how the mixed source & assembly mode in lldb works. I've been discussing this with Jim Ingham, Greg Clayton, and Kate Stone for the past week or two. Previously lldb would print three source lines (centered on the line table entry line for the current line) followed by the assembly. It would print the context information (module`function + offset) before those three lines of source. Now lldb will print up to two lines before/after the line table entry. It prints two '*' characters for the line table line to make it clear what line is showing assembly. There is one line of whitespace before/after the source lines so the separation between source & assembly is clearer. I don't print the context line (module`function + offset). I stop printing context lines if it's a different line table entry, or if it's a source line I've already printed as context to another source line. If I have two line table entries one after another for the same source line (I get these often with clang - with different column information in them), I only print the source line once. I'm also using the target.process.thread.step-avoid-regexp setting (which keeps you from stepping into STL functions that have been inlined into your own code) and avoid printing any source lines from functions that match that regexp. When lldb disassembles into a new function, it will try to find the declaration line # for the function and print all of the source lines between the decl and the first line table entry (usually a { curly brace) so we have a good chance of including the arguments, at least with the debug info emitted by clang. Finally, the # of source lines of context to show has been separated from whether we're doing mixed source & assembly or not. Previously specifying 0 lines of context would turn off mixed source & assembly. I think there's room for improvement, and maybe some bugs I haven't found yet, but it's in good enough shape to upstream and iterate at this point. I'm not sure how best to indicate which source line is the actual line table # versus context lines. I'm using '**' right now. Both Kate and Greg had the initial idea to reuse '->' (normally used to indicate "currently executing source line") - I tried it but I wasn't thrilled, I'm too used to the established meaning of ->. Greg had the interesting idea of avoiding context source lines only in two line table entries in the same source file. So we'd print two lines before & after a source line, and then the next line table entry (if it was on the next source line after those two context lines) we'd display only the following two lines -- the previous two had just been printed. If an inline source line was printed between these two, though, we'd print the context lines for both of them. It's an interesting idea, and I want to see how it works with both -O0 and -O3 codegen where we have different amounts of inlining. <rdar://problem/27961419> llvm-svn: 280906
2016-09-08 13:12:41 +08:00
AddressRange current_source_line_range;
*** 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
const Address *pc_addr_ptr = nullptr;
StackFrame *frame = exe_ctx.GetFramePtr();
TargetSP target_sp(exe_ctx.GetTargetSP());
SourceManager &source_manager =
target_sp ? target_sp->GetSourceManager() : debugger.GetSourceManager();
if (frame) {
pc_addr_ptr = &frame->GetFrameCodeAddress();
}
const uint32_t scope =
eSymbolContextLineEntry | eSymbolContextFunction | eSymbolContextSymbol;
const bool use_inline_block_range = false;
const FormatEntity::Entry *disassembly_format = nullptr;
FormatEntity::Entry format;
if (exe_ctx.HasTargetScope()) {
disassembly_format =
exe_ctx.GetTargetRef().GetDebugger().GetDisassemblyFormat();
} else {
FormatEntity::Parse("${addr}: ", format);
disassembly_format = &format;
}
// First pass: step through the list of instructions,
// find how long the initial addresses strings are, insert padding
// in the second pass so the opcodes all line up nicely.
I'm experimenting with changing how the mixed source & assembly mode in lldb works. I've been discussing this with Jim Ingham, Greg Clayton, and Kate Stone for the past week or two. Previously lldb would print three source lines (centered on the line table entry line for the current line) followed by the assembly. It would print the context information (module`function + offset) before those three lines of source. Now lldb will print up to two lines before/after the line table entry. It prints two '*' characters for the line table line to make it clear what line is showing assembly. There is one line of whitespace before/after the source lines so the separation between source & assembly is clearer. I don't print the context line (module`function + offset). I stop printing context lines if it's a different line table entry, or if it's a source line I've already printed as context to another source line. If I have two line table entries one after another for the same source line (I get these often with clang - with different column information in them), I only print the source line once. I'm also using the target.process.thread.step-avoid-regexp setting (which keeps you from stepping into STL functions that have been inlined into your own code) and avoid printing any source lines from functions that match that regexp. When lldb disassembles into a new function, it will try to find the declaration line # for the function and print all of the source lines between the decl and the first line table entry (usually a { curly brace) so we have a good chance of including the arguments, at least with the debug info emitted by clang. Finally, the # of source lines of context to show has been separated from whether we're doing mixed source & assembly or not. Previously specifying 0 lines of context would turn off mixed source & assembly. I think there's room for improvement, and maybe some bugs I haven't found yet, but it's in good enough shape to upstream and iterate at this point. I'm not sure how best to indicate which source line is the actual line table # versus context lines. I'm using '**' right now. Both Kate and Greg had the initial idea to reuse '->' (normally used to indicate "currently executing source line") - I tried it but I wasn't thrilled, I'm too used to the established meaning of ->. Greg had the interesting idea of avoiding context source lines only in two line table entries in the same source file. So we'd print two lines before & after a source line, and then the next line table entry (if it was on the next source line after those two context lines) we'd display only the following two lines -- the previous two had just been printed. If an inline source line was printed between these two, though, we'd print the context lines for both of them. It's an interesting idea, and I want to see how it works with both -O0 and -O3 codegen where we have different amounts of inlining. <rdar://problem/27961419> llvm-svn: 280906
2016-09-08 13:12:41 +08:00
// Also build up the source line mapping if this is mixed source & assembly
// mode.
// Calculate the source line for each assembly instruction (eliding inlined
// functions
// which the user wants to skip).
std::map<FileSpec, std::set<uint32_t>> source_lines_seen;
Symbol *previous_symbol = nullptr;
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
size_t address_text_size = 0;
for (size_t i = 0; i < num_instructions_found; ++i) {
Instruction *inst =
disasm_ptr->GetInstructionList().GetInstructionAtIndex(i).get();
if (inst) {
const Address &addr = inst->GetAddress();
ModuleSP module_sp(addr.GetModule());
if (module_sp) {
I'm experimenting with changing how the mixed source & assembly mode in lldb works. I've been discussing this with Jim Ingham, Greg Clayton, and Kate Stone for the past week or two. Previously lldb would print three source lines (centered on the line table entry line for the current line) followed by the assembly. It would print the context information (module`function + offset) before those three lines of source. Now lldb will print up to two lines before/after the line table entry. It prints two '*' characters for the line table line to make it clear what line is showing assembly. There is one line of whitespace before/after the source lines so the separation between source & assembly is clearer. I don't print the context line (module`function + offset). I stop printing context lines if it's a different line table entry, or if it's a source line I've already printed as context to another source line. If I have two line table entries one after another for the same source line (I get these often with clang - with different column information in them), I only print the source line once. I'm also using the target.process.thread.step-avoid-regexp setting (which keeps you from stepping into STL functions that have been inlined into your own code) and avoid printing any source lines from functions that match that regexp. When lldb disassembles into a new function, it will try to find the declaration line # for the function and print all of the source lines between the decl and the first line table entry (usually a { curly brace) so we have a good chance of including the arguments, at least with the debug info emitted by clang. Finally, the # of source lines of context to show has been separated from whether we're doing mixed source & assembly or not. Previously specifying 0 lines of context would turn off mixed source & assembly. I think there's room for improvement, and maybe some bugs I haven't found yet, but it's in good enough shape to upstream and iterate at this point. I'm not sure how best to indicate which source line is the actual line table # versus context lines. I'm using '**' right now. Both Kate and Greg had the initial idea to reuse '->' (normally used to indicate "currently executing source line") - I tried it but I wasn't thrilled, I'm too used to the established meaning of ->. Greg had the interesting idea of avoiding context source lines only in two line table entries in the same source file. So we'd print two lines before & after a source line, and then the next line table entry (if it was on the next source line after those two context lines) we'd display only the following two lines -- the previous two had just been printed. If an inline source line was printed between these two, though, we'd print the context lines for both of them. It's an interesting idea, and I want to see how it works with both -O0 and -O3 codegen where we have different amounts of inlining. <rdar://problem/27961419> llvm-svn: 280906
2016-09-08 13:12:41 +08:00
const uint32_t resolve_mask = eSymbolContextFunction |
eSymbolContextSymbol |
eSymbolContextLineEntry;
*** 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
uint32_t resolved_mask =
module_sp->ResolveSymbolContextForAddress(addr, resolve_mask, sc);
if (resolved_mask) {
StreamString strmstr;
Debugger::FormatDisassemblerAddress(disassembly_format, &sc, nullptr,
&exe_ctx, &addr, strmstr);
size_t cur_line = strmstr.GetSizeOfLastLine();
if (cur_line > address_text_size)
address_text_size = cur_line;
I'm experimenting with changing how the mixed source & assembly mode in lldb works. I've been discussing this with Jim Ingham, Greg Clayton, and Kate Stone for the past week or two. Previously lldb would print three source lines (centered on the line table entry line for the current line) followed by the assembly. It would print the context information (module`function + offset) before those three lines of source. Now lldb will print up to two lines before/after the line table entry. It prints two '*' characters for the line table line to make it clear what line is showing assembly. There is one line of whitespace before/after the source lines so the separation between source & assembly is clearer. I don't print the context line (module`function + offset). I stop printing context lines if it's a different line table entry, or if it's a source line I've already printed as context to another source line. If I have two line table entries one after another for the same source line (I get these often with clang - with different column information in them), I only print the source line once. I'm also using the target.process.thread.step-avoid-regexp setting (which keeps you from stepping into STL functions that have been inlined into your own code) and avoid printing any source lines from functions that match that regexp. When lldb disassembles into a new function, it will try to find the declaration line # for the function and print all of the source lines between the decl and the first line table entry (usually a { curly brace) so we have a good chance of including the arguments, at least with the debug info emitted by clang. Finally, the # of source lines of context to show has been separated from whether we're doing mixed source & assembly or not. Previously specifying 0 lines of context would turn off mixed source & assembly. I think there's room for improvement, and maybe some bugs I haven't found yet, but it's in good enough shape to upstream and iterate at this point. I'm not sure how best to indicate which source line is the actual line table # versus context lines. I'm using '**' right now. Both Kate and Greg had the initial idea to reuse '->' (normally used to indicate "currently executing source line") - I tried it but I wasn't thrilled, I'm too used to the established meaning of ->. Greg had the interesting idea of avoiding context source lines only in two line table entries in the same source file. So we'd print two lines before & after a source line, and then the next line table entry (if it was on the next source line after those two context lines) we'd display only the following two lines -- the previous two had just been printed. If an inline source line was printed between these two, though, we'd print the context lines for both of them. It's an interesting idea, and I want to see how it works with both -O0 and -O3 codegen where we have different amounts of inlining. <rdar://problem/27961419> llvm-svn: 280906
2016-09-08 13:12:41 +08:00
// Add entries to our "source_lines_seen" map+set which list which
// sources lines occur in this disassembly session. We will print
// lines of context around a source line, but we don't want to print
// a source line that has a line table entry of its own - we'll leave
// that source line to be printed when it actually occurs in the
// disassembly.
if (mixed_source_and_assembly && sc.line_entry.IsValid()) {
if (sc.symbol != previous_symbol) {
SourceLine decl_line = GetFunctionDeclLineEntry(sc);
if (ElideMixedSourceAndDisassemblyLine(exe_ctx, sc, decl_line) ==
false)
AddLineToSourceLineTables(decl_line, source_lines_seen);
}
if (sc.line_entry.IsValid()) {
SourceLine this_line;
this_line.file = sc.line_entry.file;
this_line.line = sc.line_entry.line;
add stop column highlighting support This change introduces optional marking of the column within a source line where a thread is stopped. This marking will show up when the source code for a thread stop is displayed, when the debug info knows the column information, and if the optional column marking is enabled. There are two separate methods for handling the marking of the stop column: * via ANSI terminal codes, which are added inline to the source line display. The default ANSI mark-up is to underline the column. * via a pure text-based caret that is added in the appropriate column in a newly-inserted blank line underneath the source line in question. There are some new options that control how this all works. * settings set stop-show-column This takes one of 4 values: * ansi-or-caret: use the ANSI terminal code mechanism if LLDB is running with color enabled; if not, use the caret-based, pure text method (see the "caret" mode below). * ansi: only use the ANSI terminal code mechanism to highlight the stop line. If LLDB is running with color disabled, no stop column marking will occur. * caret: only use the pure text caret method, which introduces a newly-inserted line underneath the current line, where the only character in the new line is a caret that highlights the stop column in question. * none: no stop column marking will be attempted. * settings set stop-show-column-ansi-prefix This is a text format that indicates the ANSI formatting code to insert into the stream immediately preceding the column where the stop column character will be marked up. It defaults to ${ansi.underline}; however, it can contain any valid LLDB format codes, e.g. ${ansi.fg.red}${ansi.bold}${ansi.underline} * settings set stop-show-column-ansi-suffix This is the text format that specifies the ANSI terminal codes to end the markup that was started with the prefix described above. It defaults to: ${ansi.normal}. This should be sufficient for the common cases. Significant leg-work was done by Adrian Prantl. (Thanks, Adrian!) differential review: https://reviews.llvm.org/D20835 reviewers: clayborg, jingham llvm-svn: 282105
2016-09-22 04:13:14 +08:00
this_line.column = sc.line_entry.column;
I'm experimenting with changing how the mixed source & assembly mode in lldb works. I've been discussing this with Jim Ingham, Greg Clayton, and Kate Stone for the past week or two. Previously lldb would print three source lines (centered on the line table entry line for the current line) followed by the assembly. It would print the context information (module`function + offset) before those three lines of source. Now lldb will print up to two lines before/after the line table entry. It prints two '*' characters for the line table line to make it clear what line is showing assembly. There is one line of whitespace before/after the source lines so the separation between source & assembly is clearer. I don't print the context line (module`function + offset). I stop printing context lines if it's a different line table entry, or if it's a source line I've already printed as context to another source line. If I have two line table entries one after another for the same source line (I get these often with clang - with different column information in them), I only print the source line once. I'm also using the target.process.thread.step-avoid-regexp setting (which keeps you from stepping into STL functions that have been inlined into your own code) and avoid printing any source lines from functions that match that regexp. When lldb disassembles into a new function, it will try to find the declaration line # for the function and print all of the source lines between the decl and the first line table entry (usually a { curly brace) so we have a good chance of including the arguments, at least with the debug info emitted by clang. Finally, the # of source lines of context to show has been separated from whether we're doing mixed source & assembly or not. Previously specifying 0 lines of context would turn off mixed source & assembly. I think there's room for improvement, and maybe some bugs I haven't found yet, but it's in good enough shape to upstream and iterate at this point. I'm not sure how best to indicate which source line is the actual line table # versus context lines. I'm using '**' right now. Both Kate and Greg had the initial idea to reuse '->' (normally used to indicate "currently executing source line") - I tried it but I wasn't thrilled, I'm too used to the established meaning of ->. Greg had the interesting idea of avoiding context source lines only in two line table entries in the same source file. So we'd print two lines before & after a source line, and then the next line table entry (if it was on the next source line after those two context lines) we'd display only the following two lines -- the previous two had just been printed. If an inline source line was printed between these two, though, we'd print the context lines for both of them. It's an interesting idea, and I want to see how it works with both -O0 and -O3 codegen where we have different amounts of inlining. <rdar://problem/27961419> llvm-svn: 280906
2016-09-08 13:12:41 +08:00
if (ElideMixedSourceAndDisassemblyLine(exe_ctx, sc, this_line) ==
false)
AddLineToSourceLineTables(this_line, source_lines_seen);
}
}
Change the default disassembly format again. First attempt at changing it was in r219544 - after living on that for a few months, I wanted to take another crack at this. The disassembly-format setting still exists and the old format can be user specified with a setting like ${current-pc-arrow}${addr-file-or-load}{ <${function.name-without-args}${function.concrete-only-addr-offset-no-padding}>}: This patch was discussed in http://reviews.llvm.org/D7578 <rdar://problem/19726421> llvm-svn: 229186
2015-02-14 07:24:21 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
sc.Clear(false);
}
Change the default disassembly format again. First attempt at changing it was in r219544 - after living on that for a few months, I wanted to take another crack at this. The disassembly-format setting still exists and the old format can be user specified with a setting like ${current-pc-arrow}${addr-file-or-load}{ <${function.name-without-args}${function.concrete-only-addr-offset-no-padding}>}: This patch was discussed in http://reviews.llvm.org/D7578 <rdar://problem/19726421> llvm-svn: 229186
2015-02-14 07:24:21 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
}
I'm experimenting with changing how the mixed source & assembly mode in lldb works. I've been discussing this with Jim Ingham, Greg Clayton, and Kate Stone for the past week or two. Previously lldb would print three source lines (centered on the line table entry line for the current line) followed by the assembly. It would print the context information (module`function + offset) before those three lines of source. Now lldb will print up to two lines before/after the line table entry. It prints two '*' characters for the line table line to make it clear what line is showing assembly. There is one line of whitespace before/after the source lines so the separation between source & assembly is clearer. I don't print the context line (module`function + offset). I stop printing context lines if it's a different line table entry, or if it's a source line I've already printed as context to another source line. If I have two line table entries one after another for the same source line (I get these often with clang - with different column information in them), I only print the source line once. I'm also using the target.process.thread.step-avoid-regexp setting (which keeps you from stepping into STL functions that have been inlined into your own code) and avoid printing any source lines from functions that match that regexp. When lldb disassembles into a new function, it will try to find the declaration line # for the function and print all of the source lines between the decl and the first line table entry (usually a { curly brace) so we have a good chance of including the arguments, at least with the debug info emitted by clang. Finally, the # of source lines of context to show has been separated from whether we're doing mixed source & assembly or not. Previously specifying 0 lines of context would turn off mixed source & assembly. I think there's room for improvement, and maybe some bugs I haven't found yet, but it's in good enough shape to upstream and iterate at this point. I'm not sure how best to indicate which source line is the actual line table # versus context lines. I'm using '**' right now. Both Kate and Greg had the initial idea to reuse '->' (normally used to indicate "currently executing source line") - I tried it but I wasn't thrilled, I'm too used to the established meaning of ->. Greg had the interesting idea of avoiding context source lines only in two line table entries in the same source file. So we'd print two lines before & after a source line, and then the next line table entry (if it was on the next source line after those two context lines) we'd display only the following two lines -- the previous two had just been printed. If an inline source line was printed between these two, though, we'd print the context lines for both of them. It's an interesting idea, and I want to see how it works with both -O0 and -O3 codegen where we have different amounts of inlining. <rdar://problem/27961419> llvm-svn: 280906
2016-09-08 13:12:41 +08:00
previous_symbol = nullptr;
SourceLine previous_line;
*** 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
for (size_t i = 0; i < num_instructions_found; ++i) {
Instruction *inst =
disasm_ptr->GetInstructionList().GetInstructionAtIndex(i).get();
I'm experimenting with changing how the mixed source & assembly mode in lldb works. I've been discussing this with Jim Ingham, Greg Clayton, and Kate Stone for the past week or two. Previously lldb would print three source lines (centered on the line table entry line for the current line) followed by the assembly. It would print the context information (module`function + offset) before those three lines of source. Now lldb will print up to two lines before/after the line table entry. It prints two '*' characters for the line table line to make it clear what line is showing assembly. There is one line of whitespace before/after the source lines so the separation between source & assembly is clearer. I don't print the context line (module`function + offset). I stop printing context lines if it's a different line table entry, or if it's a source line I've already printed as context to another source line. If I have two line table entries one after another for the same source line (I get these often with clang - with different column information in them), I only print the source line once. I'm also using the target.process.thread.step-avoid-regexp setting (which keeps you from stepping into STL functions that have been inlined into your own code) and avoid printing any source lines from functions that match that regexp. When lldb disassembles into a new function, it will try to find the declaration line # for the function and print all of the source lines between the decl and the first line table entry (usually a { curly brace) so we have a good chance of including the arguments, at least with the debug info emitted by clang. Finally, the # of source lines of context to show has been separated from whether we're doing mixed source & assembly or not. Previously specifying 0 lines of context would turn off mixed source & assembly. I think there's room for improvement, and maybe some bugs I haven't found yet, but it's in good enough shape to upstream and iterate at this point. I'm not sure how best to indicate which source line is the actual line table # versus context lines. I'm using '**' right now. Both Kate and Greg had the initial idea to reuse '->' (normally used to indicate "currently executing source line") - I tried it but I wasn't thrilled, I'm too used to the established meaning of ->. Greg had the interesting idea of avoiding context source lines only in two line table entries in the same source file. So we'd print two lines before & after a source line, and then the next line table entry (if it was on the next source line after those two context lines) we'd display only the following two lines -- the previous two had just been printed. If an inline source line was printed between these two, though, we'd print the context lines for both of them. It's an interesting idea, and I want to see how it works with both -O0 and -O3 codegen where we have different amounts of inlining. <rdar://problem/27961419> llvm-svn: 280906
2016-09-08 13:12:41 +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
if (inst) {
const Address &addr = inst->GetAddress();
const bool inst_is_at_pc = pc_addr_ptr && addr == *pc_addr_ptr;
I'm experimenting with changing how the mixed source & assembly mode in lldb works. I've been discussing this with Jim Ingham, Greg Clayton, and Kate Stone for the past week or two. Previously lldb would print three source lines (centered on the line table entry line for the current line) followed by the assembly. It would print the context information (module`function + offset) before those three lines of source. Now lldb will print up to two lines before/after the line table entry. It prints two '*' characters for the line table line to make it clear what line is showing assembly. There is one line of whitespace before/after the source lines so the separation between source & assembly is clearer. I don't print the context line (module`function + offset). I stop printing context lines if it's a different line table entry, or if it's a source line I've already printed as context to another source line. If I have two line table entries one after another for the same source line (I get these often with clang - with different column information in them), I only print the source line once. I'm also using the target.process.thread.step-avoid-regexp setting (which keeps you from stepping into STL functions that have been inlined into your own code) and avoid printing any source lines from functions that match that regexp. When lldb disassembles into a new function, it will try to find the declaration line # for the function and print all of the source lines between the decl and the first line table entry (usually a { curly brace) so we have a good chance of including the arguments, at least with the debug info emitted by clang. Finally, the # of source lines of context to show has been separated from whether we're doing mixed source & assembly or not. Previously specifying 0 lines of context would turn off mixed source & assembly. I think there's room for improvement, and maybe some bugs I haven't found yet, but it's in good enough shape to upstream and iterate at this point. I'm not sure how best to indicate which source line is the actual line table # versus context lines. I'm using '**' right now. Both Kate and Greg had the initial idea to reuse '->' (normally used to indicate "currently executing source line") - I tried it but I wasn't thrilled, I'm too used to the established meaning of ->. Greg had the interesting idea of avoiding context source lines only in two line table entries in the same source file. So we'd print two lines before & after a source line, and then the next line table entry (if it was on the next source line after those two context lines) we'd display only the following two lines -- the previous two had just been printed. If an inline source line was printed between these two, though, we'd print the context lines for both of them. It's an interesting idea, and I want to see how it works with both -O0 and -O3 codegen where we have different amounts of inlining. <rdar://problem/27961419> llvm-svn: 280906
2016-09-08 13:12:41 +08:00
SourceLinesToDisplay source_lines_to_display;
*** 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
prev_sc = sc;
ModuleSP module_sp(addr.GetModule());
if (module_sp) {
uint32_t resolved_mask = module_sp->ResolveSymbolContextForAddress(
addr, eSymbolContextEverything, sc);
if (resolved_mask) {
I'm experimenting with changing how the mixed source & assembly mode in lldb works. I've been discussing this with Jim Ingham, Greg Clayton, and Kate Stone for the past week or two. Previously lldb would print three source lines (centered on the line table entry line for the current line) followed by the assembly. It would print the context information (module`function + offset) before those three lines of source. Now lldb will print up to two lines before/after the line table entry. It prints two '*' characters for the line table line to make it clear what line is showing assembly. There is one line of whitespace before/after the source lines so the separation between source & assembly is clearer. I don't print the context line (module`function + offset). I stop printing context lines if it's a different line table entry, or if it's a source line I've already printed as context to another source line. If I have two line table entries one after another for the same source line (I get these often with clang - with different column information in them), I only print the source line once. I'm also using the target.process.thread.step-avoid-regexp setting (which keeps you from stepping into STL functions that have been inlined into your own code) and avoid printing any source lines from functions that match that regexp. When lldb disassembles into a new function, it will try to find the declaration line # for the function and print all of the source lines between the decl and the first line table entry (usually a { curly brace) so we have a good chance of including the arguments, at least with the debug info emitted by clang. Finally, the # of source lines of context to show has been separated from whether we're doing mixed source & assembly or not. Previously specifying 0 lines of context would turn off mixed source & assembly. I think there's room for improvement, and maybe some bugs I haven't found yet, but it's in good enough shape to upstream and iterate at this point. I'm not sure how best to indicate which source line is the actual line table # versus context lines. I'm using '**' right now. Both Kate and Greg had the initial idea to reuse '->' (normally used to indicate "currently executing source line") - I tried it but I wasn't thrilled, I'm too used to the established meaning of ->. Greg had the interesting idea of avoiding context source lines only in two line table entries in the same source file. So we'd print two lines before & after a source line, and then the next line table entry (if it was on the next source line after those two context lines) we'd display only the following two lines -- the previous two had just been printed. If an inline source line was printed between these two, though, we'd print the context lines for both of them. It's an interesting idea, and I want to see how it works with both -O0 and -O3 codegen where we have different amounts of inlining. <rdar://problem/27961419> llvm-svn: 280906
2016-09-08 13:12:41 +08:00
if (mixed_source_and_assembly) {
// If we've started a new function (non-inlined), print all of the
// source lines from the
// function declaration until the first line table entry - typically
// the opening curly brace of
// the function.
if (previous_symbol != sc.symbol) {
// The default disassembly format puts an extra blank line between
// functions - so
// when we're displaying the source context for a function, we
// don't want to add
// a blank line after the source context or we'll end up with two
// of them.
if (previous_symbol != nullptr)
source_lines_to_display.print_source_context_end_eol = false;
previous_symbol = sc.symbol;
if (sc.function && sc.line_entry.IsValid()) {
LineEntry prologue_end_line = sc.line_entry;
if (ElideMixedSourceAndDisassemblyLine(
exe_ctx, sc, prologue_end_line) == false) {
FileSpec func_decl_file;
uint32_t func_decl_line;
sc.function->GetStartLineSourceInfo(func_decl_file,
func_decl_line);
if (func_decl_file == prologue_end_line.file ||
func_decl_file == prologue_end_line.original_file) {
// Add all the lines between the function declaration
// and the first non-prologue source line to the list
// of lines to print.
for (uint32_t lineno = func_decl_line;
lineno <= prologue_end_line.line; lineno++) {
SourceLine this_line;
this_line.file = func_decl_file;
this_line.line = lineno;
source_lines_to_display.lines.push_back(this_line);
}
// Mark the last line as the "current" one. Usually
// this is the open curly brace.
if (source_lines_to_display.lines.size() > 0)
source_lines_to_display.current_source_line =
source_lines_to_display.lines.size() - 1;
}
}
}
sc.GetAddressRange(scope, 0, use_inline_block_range,
current_source_line_range);
}
// If we've left a previous source line's address range, print a new
// source line
if (!current_source_line_range.ContainsFileAddress(addr)) {
sc.GetAddressRange(scope, 0, use_inline_block_range,
current_source_line_range);
if (sc != prev_sc && sc.comp_unit && sc.line_entry.IsValid()) {
SourceLine this_line;
this_line.file = sc.line_entry.file;
this_line.line = sc.line_entry.line;
if (ElideMixedSourceAndDisassemblyLine(exe_ctx, sc,
this_line) == false) {
// Only print this source line if it is different from the
// last source line we printed. There may have been inlined
// functions between these lines that we elided, resulting in
// the same line being printed twice in a row for a contiguous
// block of assembly instructions.
if (this_line != previous_line) {
std::vector<uint32_t> previous_lines;
Fix unused variable and integer sign warnings from r280906 llvm-svn: 280931
2016-09-08 21:11:31 +08:00
for (uint32_t i = 0;
I'm experimenting with changing how the mixed source & assembly mode in lldb works. I've been discussing this with Jim Ingham, Greg Clayton, and Kate Stone for the past week or two. Previously lldb would print three source lines (centered on the line table entry line for the current line) followed by the assembly. It would print the context information (module`function + offset) before those three lines of source. Now lldb will print up to two lines before/after the line table entry. It prints two '*' characters for the line table line to make it clear what line is showing assembly. There is one line of whitespace before/after the source lines so the separation between source & assembly is clearer. I don't print the context line (module`function + offset). I stop printing context lines if it's a different line table entry, or if it's a source line I've already printed as context to another source line. If I have two line table entries one after another for the same source line (I get these often with clang - with different column information in them), I only print the source line once. I'm also using the target.process.thread.step-avoid-regexp setting (which keeps you from stepping into STL functions that have been inlined into your own code) and avoid printing any source lines from functions that match that regexp. When lldb disassembles into a new function, it will try to find the declaration line # for the function and print all of the source lines between the decl and the first line table entry (usually a { curly brace) so we have a good chance of including the arguments, at least with the debug info emitted by clang. Finally, the # of source lines of context to show has been separated from whether we're doing mixed source & assembly or not. Previously specifying 0 lines of context would turn off mixed source & assembly. I think there's room for improvement, and maybe some bugs I haven't found yet, but it's in good enough shape to upstream and iterate at this point. I'm not sure how best to indicate which source line is the actual line table # versus context lines. I'm using '**' right now. Both Kate and Greg had the initial idea to reuse '->' (normally used to indicate "currently executing source line") - I tried it but I wasn't thrilled, I'm too used to the established meaning of ->. Greg had the interesting idea of avoiding context source lines only in two line table entries in the same source file. So we'd print two lines before & after a source line, and then the next line table entry (if it was on the next source line after those two context lines) we'd display only the following two lines -- the previous two had just been printed. If an inline source line was printed between these two, though, we'd print the context lines for both of them. It's an interesting idea, and I want to see how it works with both -O0 and -O3 codegen where we have different amounts of inlining. <rdar://problem/27961419> llvm-svn: 280906
2016-09-08 13:12:41 +08:00
i < num_mixed_context_lines &&
(this_line.line - num_mixed_context_lines) > 0;
i++) {
uint32_t line =
this_line.line - num_mixed_context_lines + i;
auto pos = source_lines_seen.find(this_line.file);
if (pos != source_lines_seen.end()) {
if (pos->second.count(line) == 1) {
previous_lines.clear();
} else {
previous_lines.push_back(line);
}
}
}
for (size_t i = 0; i < previous_lines.size(); i++) {
SourceLine previous_line;
previous_line.file = this_line.file;
previous_line.line = previous_lines[i];
auto pos = source_lines_seen.find(previous_line.file);
if (pos != source_lines_seen.end()) {
pos->second.insert(previous_line.line);
}
source_lines_to_display.lines.push_back(previous_line);
}
source_lines_to_display.lines.push_back(this_line);
source_lines_to_display.current_source_line =
source_lines_to_display.lines.size() - 1;
Fix unused variable and integer sign warnings from r280906 llvm-svn: 280931
2016-09-08 21:11:31 +08:00
for (uint32_t i = 0; i < num_mixed_context_lines; i++) {
I'm experimenting with changing how the mixed source & assembly mode in lldb works. I've been discussing this with Jim Ingham, Greg Clayton, and Kate Stone for the past week or two. Previously lldb would print three source lines (centered on the line table entry line for the current line) followed by the assembly. It would print the context information (module`function + offset) before those three lines of source. Now lldb will print up to two lines before/after the line table entry. It prints two '*' characters for the line table line to make it clear what line is showing assembly. There is one line of whitespace before/after the source lines so the separation between source & assembly is clearer. I don't print the context line (module`function + offset). I stop printing context lines if it's a different line table entry, or if it's a source line I've already printed as context to another source line. If I have two line table entries one after another for the same source line (I get these often with clang - with different column information in them), I only print the source line once. I'm also using the target.process.thread.step-avoid-regexp setting (which keeps you from stepping into STL functions that have been inlined into your own code) and avoid printing any source lines from functions that match that regexp. When lldb disassembles into a new function, it will try to find the declaration line # for the function and print all of the source lines between the decl and the first line table entry (usually a { curly brace) so we have a good chance of including the arguments, at least with the debug info emitted by clang. Finally, the # of source lines of context to show has been separated from whether we're doing mixed source & assembly or not. Previously specifying 0 lines of context would turn off mixed source & assembly. I think there's room for improvement, and maybe some bugs I haven't found yet, but it's in good enough shape to upstream and iterate at this point. I'm not sure how best to indicate which source line is the actual line table # versus context lines. I'm using '**' right now. Both Kate and Greg had the initial idea to reuse '->' (normally used to indicate "currently executing source line") - I tried it but I wasn't thrilled, I'm too used to the established meaning of ->. Greg had the interesting idea of avoiding context source lines only in two line table entries in the same source file. So we'd print two lines before & after a source line, and then the next line table entry (if it was on the next source line after those two context lines) we'd display only the following two lines -- the previous two had just been printed. If an inline source line was printed between these two, though, we'd print the context lines for both of them. It's an interesting idea, and I want to see how it works with both -O0 and -O3 codegen where we have different amounts of inlining. <rdar://problem/27961419> llvm-svn: 280906
2016-09-08 13:12:41 +08:00
SourceLine next_line;
next_line.file = this_line.file;
next_line.line = this_line.line + i + 1;
auto pos = source_lines_seen.find(next_line.file);
if (pos != source_lines_seen.end()) {
if (pos->second.count(next_line.line) == 1)
break;
pos->second.insert(next_line.line);
}
source_lines_to_display.lines.push_back(next_line);
}
}
previous_line = this_line;
Add the ability to disassemble "n" instructions from the current PC, or the first "n" instructions in a function. Also added a "-p" flag that disassembles from the current pc. llvm-svn: 128063
2011-03-22 09:48:42 +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
}
*** 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 {
sc.Clear(true);
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
}
I'm experimenting with changing how the mixed source & assembly mode in lldb works. I've been discussing this with Jim Ingham, Greg Clayton, and Kate Stone for the past week or two. Previously lldb would print three source lines (centered on the line table entry line for the current line) followed by the assembly. It would print the context information (module`function + offset) before those three lines of source. Now lldb will print up to two lines before/after the line table entry. It prints two '*' characters for the line table line to make it clear what line is showing assembly. There is one line of whitespace before/after the source lines so the separation between source & assembly is clearer. I don't print the context line (module`function + offset). I stop printing context lines if it's a different line table entry, or if it's a source line I've already printed as context to another source line. If I have two line table entries one after another for the same source line (I get these often with clang - with different column information in them), I only print the source line once. I'm also using the target.process.thread.step-avoid-regexp setting (which keeps you from stepping into STL functions that have been inlined into your own code) and avoid printing any source lines from functions that match that regexp. When lldb disassembles into a new function, it will try to find the declaration line # for the function and print all of the source lines between the decl and the first line table entry (usually a { curly brace) so we have a good chance of including the arguments, at least with the debug info emitted by clang. Finally, the # of source lines of context to show has been separated from whether we're doing mixed source & assembly or not. Previously specifying 0 lines of context would turn off mixed source & assembly. I think there's room for improvement, and maybe some bugs I haven't found yet, but it's in good enough shape to upstream and iterate at this point. I'm not sure how best to indicate which source line is the actual line table # versus context lines. I'm using '**' right now. Both Kate and Greg had the initial idea to reuse '->' (normally used to indicate "currently executing source line") - I tried it but I wasn't thrilled, I'm too used to the established meaning of ->. Greg had the interesting idea of avoiding context source lines only in two line table entries in the same source file. So we'd print two lines before & after a source line, and then the next line table entry (if it was on the next source line after those two context lines) we'd display only the following two lines -- the previous two had just been printed. If an inline source line was printed between these two, though, we'd print the context lines for both of them. It's an interesting idea, and I want to see how it works with both -O0 and -O3 codegen where we have different amounts of inlining. <rdar://problem/27961419> llvm-svn: 280906
2016-09-08 13:12:41 +08:00
if (source_lines_to_display.lines.size() > 0) {
strm.EOL();
for (size_t idx = 0; idx < source_lines_to_display.lines.size();
idx++) {
SourceLine ln = source_lines_to_display.lines[idx];
const char *line_highlight = "";
if (inst_is_at_pc && (options & eOptionMarkPCSourceLine)) {
line_highlight = "->";
} else if (idx == source_lines_to_display.current_source_line) {
line_highlight = "**";
}
source_manager.DisplaySourceLinesWithLineNumbers(
add stop column highlighting support This change introduces optional marking of the column within a source line where a thread is stopped. This marking will show up when the source code for a thread stop is displayed, when the debug info knows the column information, and if the optional column marking is enabled. There are two separate methods for handling the marking of the stop column: * via ANSI terminal codes, which are added inline to the source line display. The default ANSI mark-up is to underline the column. * via a pure text-based caret that is added in the appropriate column in a newly-inserted blank line underneath the source line in question. There are some new options that control how this all works. * settings set stop-show-column This takes one of 4 values: * ansi-or-caret: use the ANSI terminal code mechanism if LLDB is running with color enabled; if not, use the caret-based, pure text method (see the "caret" mode below). * ansi: only use the ANSI terminal code mechanism to highlight the stop line. If LLDB is running with color disabled, no stop column marking will occur. * caret: only use the pure text caret method, which introduces a newly-inserted line underneath the current line, where the only character in the new line is a caret that highlights the stop column in question. * none: no stop column marking will be attempted. * settings set stop-show-column-ansi-prefix This is a text format that indicates the ANSI formatting code to insert into the stream immediately preceding the column where the stop column character will be marked up. It defaults to ${ansi.underline}; however, it can contain any valid LLDB format codes, e.g. ${ansi.fg.red}${ansi.bold}${ansi.underline} * settings set stop-show-column-ansi-suffix This is the text format that specifies the ANSI terminal codes to end the markup that was started with the prefix described above. It defaults to: ${ansi.normal}. This should be sufficient for the common cases. Significant leg-work was done by Adrian Prantl. (Thanks, Adrian!) differential review: https://reviews.llvm.org/D20835 reviewers: clayborg, jingham llvm-svn: 282105
2016-09-22 04:13:14 +08:00
ln.file, ln.line, ln.column, 0, 0, line_highlight, &strm);
I'm experimenting with changing how the mixed source & assembly mode in lldb works. I've been discussing this with Jim Ingham, Greg Clayton, and Kate Stone for the past week or two. Previously lldb would print three source lines (centered on the line table entry line for the current line) followed by the assembly. It would print the context information (module`function + offset) before those three lines of source. Now lldb will print up to two lines before/after the line table entry. It prints two '*' characters for the line table line to make it clear what line is showing assembly. There is one line of whitespace before/after the source lines so the separation between source & assembly is clearer. I don't print the context line (module`function + offset). I stop printing context lines if it's a different line table entry, or if it's a source line I've already printed as context to another source line. If I have two line table entries one after another for the same source line (I get these often with clang - with different column information in them), I only print the source line once. I'm also using the target.process.thread.step-avoid-regexp setting (which keeps you from stepping into STL functions that have been inlined into your own code) and avoid printing any source lines from functions that match that regexp. When lldb disassembles into a new function, it will try to find the declaration line # for the function and print all of the source lines between the decl and the first line table entry (usually a { curly brace) so we have a good chance of including the arguments, at least with the debug info emitted by clang. Finally, the # of source lines of context to show has been separated from whether we're doing mixed source & assembly or not. Previously specifying 0 lines of context would turn off mixed source & assembly. I think there's room for improvement, and maybe some bugs I haven't found yet, but it's in good enough shape to upstream and iterate at this point. I'm not sure how best to indicate which source line is the actual line table # versus context lines. I'm using '**' right now. Both Kate and Greg had the initial idea to reuse '->' (normally used to indicate "currently executing source line") - I tried it but I wasn't thrilled, I'm too used to the established meaning of ->. Greg had the interesting idea of avoiding context source lines only in two line table entries in the same source file. So we'd print two lines before & after a source line, and then the next line table entry (if it was on the next source line after those two context lines) we'd display only the following two lines -- the previous two had just been printed. If an inline source line was printed between these two, though, we'd print the context lines for both of them. It's an interesting idea, and I want to see how it works with both -O0 and -O3 codegen where we have different amounts of inlining. <rdar://problem/27961419> llvm-svn: 280906
2016-09-08 13:12:41 +08:00
}
if (source_lines_to_display.print_source_context_end_eol)
strm.EOL();
}
*** 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
const bool show_bytes = (options & eOptionShowBytes) != 0;
inst->Dump(&strm, max_opcode_byte_size, true, show_bytes, &exe_ctx, &sc,
&prev_sc, nullptr, address_text_size);
strm.EOL();
} else {
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
}
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
return true;
}
Centralized all disassembly into static functions in source/Core/Disassembler.cpp. Added the ability to read memory from the target's object files when we aren't running, so disassembling works before you run! Cleaned up the API to lldb_private::Target::ReadMemory(). Cleaned up the API to the Disassembler to use actual "lldb_private::Address" objects instead of just an "addr_t". This is nice because the Address objects when resolved carry along their section and module which can get us the object file. This allows Target::ReadMemory to be used when we are not running. Added a new lldb_private::Address dump style: DumpStyleDetailedSymbolContext This will show a full breakdown of what an address points to. To see some sample output, execute a "image lookup --address <addr>". Fixed SymbolContext::DumpStopContext(...) to not require a live process in order to be able to print function and symbol offsets. llvm-svn: 107350
2010-07-01 07:03:03 +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
bool Disassembler::Disassemble(Debugger &debugger, const ArchSpec &arch,
const char *plugin_name, const char *flavor,
const ExecutionContext &exe_ctx,
uint32_t num_instructions,
I'm experimenting with changing how the mixed source & assembly mode in lldb works. I've been discussing this with Jim Ingham, Greg Clayton, and Kate Stone for the past week or two. Previously lldb would print three source lines (centered on the line table entry line for the current line) followed by the assembly. It would print the context information (module`function + offset) before those three lines of source. Now lldb will print up to two lines before/after the line table entry. It prints two '*' characters for the line table line to make it clear what line is showing assembly. There is one line of whitespace before/after the source lines so the separation between source & assembly is clearer. I don't print the context line (module`function + offset). I stop printing context lines if it's a different line table entry, or if it's a source line I've already printed as context to another source line. If I have two line table entries one after another for the same source line (I get these often with clang - with different column information in them), I only print the source line once. I'm also using the target.process.thread.step-avoid-regexp setting (which keeps you from stepping into STL functions that have been inlined into your own code) and avoid printing any source lines from functions that match that regexp. When lldb disassembles into a new function, it will try to find the declaration line # for the function and print all of the source lines between the decl and the first line table entry (usually a { curly brace) so we have a good chance of including the arguments, at least with the debug info emitted by clang. Finally, the # of source lines of context to show has been separated from whether we're doing mixed source & assembly or not. Previously specifying 0 lines of context would turn off mixed source & assembly. I think there's room for improvement, and maybe some bugs I haven't found yet, but it's in good enough shape to upstream and iterate at this point. I'm not sure how best to indicate which source line is the actual line table # versus context lines. I'm using '**' right now. Both Kate and Greg had the initial idea to reuse '->' (normally used to indicate "currently executing source line") - I tried it but I wasn't thrilled, I'm too used to the established meaning of ->. Greg had the interesting idea of avoiding context source lines only in two line table entries in the same source file. So we'd print two lines before & after a source line, and then the next line table entry (if it was on the next source line after those two context lines) we'd display only the following two lines -- the previous two had just been printed. If an inline source line was printed between these two, though, we'd print the context lines for both of them. It's an interesting idea, and I want to see how it works with both -O0 and -O3 codegen where we have different amounts of inlining. <rdar://problem/27961419> llvm-svn: 280906
2016-09-08 13:12:41 +08:00
bool mixed_source_and_assembly,
*** 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
uint32_t num_mixed_context_lines,
uint32_t options, Stream &strm) {
AddressRange range;
StackFrame *frame = exe_ctx.GetFramePtr();
if (frame) {
SymbolContext sc(
frame->GetSymbolContext(eSymbolContextFunction | eSymbolContextSymbol));
if (sc.function) {
range = sc.function->GetAddressRange();
} else if (sc.symbol && sc.symbol->ValueIsAddress()) {
range.GetBaseAddress() = sc.symbol->GetAddressRef();
range.SetByteSize(sc.symbol->GetByteSize());
} else {
range.GetBaseAddress() = frame->GetFrameCodeAddress();
Centralized all disassembly into static functions in source/Core/Disassembler.cpp. Added the ability to read memory from the target's object files when we aren't running, so disassembling works before you run! Cleaned up the API to lldb_private::Target::ReadMemory(). Cleaned up the API to the Disassembler to use actual "lldb_private::Address" objects instead of just an "addr_t". This is nice because the Address objects when resolved carry along their section and module which can get us the object file. This allows Target::ReadMemory to be used when we are not running. Added a new lldb_private::Address dump style: DumpStyleDetailedSymbolContext This will show a full breakdown of what an address points to. To see some sample output, execute a "image lookup --address <addr>". Fixed SymbolContext::DumpStopContext(...) to not require a live process in order to be able to print function and symbol offsets. llvm-svn: 107350
2010-07-01 07:03:03 +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
if (range.GetBaseAddress().IsValid() && range.GetByteSize() == 0)
range.SetByteSize(DEFAULT_DISASM_BYTE_SIZE);
}
Centralized all disassembly into static functions in source/Core/Disassembler.cpp. Added the ability to read memory from the target's object files when we aren't running, so disassembling works before you run! Cleaned up the API to lldb_private::Target::ReadMemory(). Cleaned up the API to the Disassembler to use actual "lldb_private::Address" objects instead of just an "addr_t". This is nice because the Address objects when resolved carry along their section and module which can get us the object file. This allows Target::ReadMemory to be used when we are not running. Added a new lldb_private::Address dump style: DumpStyleDetailedSymbolContext This will show a full breakdown of what an address points to. To see some sample output, execute a "image lookup --address <addr>". Fixed SymbolContext::DumpStopContext(...) to not require a live process in order to be able to print function and symbol offsets. llvm-svn: 107350
2010-07-01 07:03:03 +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
return Disassemble(debugger, arch, plugin_name, flavor, exe_ctx, range,
I'm experimenting with changing how the mixed source & assembly mode in lldb works. I've been discussing this with Jim Ingham, Greg Clayton, and Kate Stone for the past week or two. Previously lldb would print three source lines (centered on the line table entry line for the current line) followed by the assembly. It would print the context information (module`function + offset) before those three lines of source. Now lldb will print up to two lines before/after the line table entry. It prints two '*' characters for the line table line to make it clear what line is showing assembly. There is one line of whitespace before/after the source lines so the separation between source & assembly is clearer. I don't print the context line (module`function + offset). I stop printing context lines if it's a different line table entry, or if it's a source line I've already printed as context to another source line. If I have two line table entries one after another for the same source line (I get these often with clang - with different column information in them), I only print the source line once. I'm also using the target.process.thread.step-avoid-regexp setting (which keeps you from stepping into STL functions that have been inlined into your own code) and avoid printing any source lines from functions that match that regexp. When lldb disassembles into a new function, it will try to find the declaration line # for the function and print all of the source lines between the decl and the first line table entry (usually a { curly brace) so we have a good chance of including the arguments, at least with the debug info emitted by clang. Finally, the # of source lines of context to show has been separated from whether we're doing mixed source & assembly or not. Previously specifying 0 lines of context would turn off mixed source & assembly. I think there's room for improvement, and maybe some bugs I haven't found yet, but it's in good enough shape to upstream and iterate at this point. I'm not sure how best to indicate which source line is the actual line table # versus context lines. I'm using '**' right now. Both Kate and Greg had the initial idea to reuse '->' (normally used to indicate "currently executing source line") - I tried it but I wasn't thrilled, I'm too used to the established meaning of ->. Greg had the interesting idea of avoiding context source lines only in two line table entries in the same source file. So we'd print two lines before & after a source line, and then the next line table entry (if it was on the next source line after those two context lines) we'd display only the following two lines -- the previous two had just been printed. If an inline source line was printed between these two, though, we'd print the context lines for both of them. It's an interesting idea, and I want to see how it works with both -O0 and -O3 codegen where we have different amounts of inlining. <rdar://problem/27961419> llvm-svn: 280906
2016-09-08 13:12:41 +08:00
num_instructions, mixed_source_and_assembly,
num_mixed_context_lines, options, strm);
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
Instruction::Instruction(const Address &address, AddressClass addr_class)
: m_address(address), m_address_class(addr_class), m_opcode(),
m_calculated_strings(false) {}
Fix Clang-tidy modernize-use-nullptr warnings in some files in source/Core; other minor fixes. llvm-svn: 262570
2016-03-03 08:51:40 +08:00
Instruction::~Instruction() = default;
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
AddressClass Instruction::GetAddressClass() {
if (m_address_class == eAddressClassInvalid)
m_address_class = m_address.GetAddressClass();
return m_address_class;
Added the ability to get the min and max instruction byte size for an architecture into ArchSpec: uint32_t ArchSpec::GetMinimumOpcodeByteSize() const; uint32_t ArchSpec::GetMaximumOpcodeByteSize() const; Added an AddressClass to the Instruction class in Disassembler.h. This allows decoded instructions to know know if they are code, code with alternate ISA (thumb), or even data which can be mixed into code. The instruction does have an address, but it is a good idea to cache this value so we don't have to look it up more than once. Fixed an issue in Opcode::SetOpcodeBytes() where the length wasn't getting set. Changed: bool SymbolContextList::AppendIfUnique (const SymbolContext& sc); To: bool SymbolContextList::AppendIfUnique (const SymbolContext& sc, bool merge_symbol_into_function); This function was typically being used when looking up functions and symbols. Now if you lookup a function, then find the symbol, they can be merged into the same symbol context and not cause multiple symbol contexts to appear in a symbol context list that describes the same function. Fixed the SymbolContext not equal operator which was causing mixed mode disassembly to not work ("disassembler --mixed --name main"). Modified the disassembler classes to know about the fact we know, for a given architecture, what the min and max opcode byte sizes are. The InstructionList class was modified to return the max opcode byte size for all of the instructions in its list. These two fixes means when disassemble a list of instructions and dump them and show the opcode bytes, we can format the output more intelligently when showing opcode bytes. This affects any architectures that have varying opcode byte sizes (x86_64 and i386). Knowing the max opcode byte size also helps us to be able to disassemble N instructions without having to re-read data if we didn't read enough bytes. Added the ability to set the architecture for the disassemble command. This means you can easily cross disassemble data for any supported architecture. I also added the ability to specify "thumb" as an architecture so that we can force disassembly into thumb mode when needed. In GDB this was done using a hack of specifying an odd address when disassembling. I don't want to repeat this hack in LLDB, so the auto detection between ARM and thumb is failing, just specify thumb when disassembling: (lldb) disassemble --arch thumb --name main You can also have data in say an x86_64 file executable and disassemble data as any other supported architecture: % lldb a.out Current executable set to 'a.out' (x86_64). (lldb) b main (lldb) run (lldb) disassemble --arch thumb --count 2 --start-address 0x0000000100001080 --bytes 0x100001080: 0xb580 push {r7, lr} 0x100001082: 0xaf00 add r7, sp, #0 Fixed Target::ReadMemory(...) to be able to deal with Address argument object that isn't section offset. When an address object was supplied that was out on the heap or stack, target read memory would fail. Disassembly uses Target::ReadMemory(...), and the example above where we disassembler thumb opcodes in an x86 binary was failing do to this bug. llvm-svn: 128347
2011-03-27 03:14:58 +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
void Instruction::Dump(lldb_private::Stream *s, uint32_t max_opcode_byte_size,
bool show_address, bool show_bytes,
const ExecutionContext *exe_ctx,
const SymbolContext *sym_ctx,
const SymbolContext *prev_sym_ctx,
const FormatEntity::Entry *disassembly_addr_format,
size_t max_address_text_size) {
size_t opcode_column_width = 7;
const size_t operand_column_width = 25;
CalculateMnemonicOperandsAndCommentIfNeeded(exe_ctx);
StreamString ss;
if (show_address) {
Debugger::FormatDisassemblerAddress(disassembly_addr_format, sym_ctx,
prev_sym_ctx, exe_ctx, &m_address, ss);
ss.FillLastLineToColumn(max_address_text_size, ' ');
}
if (show_bytes) {
if (m_opcode.GetType() == Opcode::eTypeBytes) {
// x86_64 and i386 are the only ones that use bytes right now so
// pad out the byte dump to be able to always show 15 bytes (3 chars each)
// plus a space
if (max_opcode_byte_size > 0)
m_opcode.Dump(&ss, max_opcode_byte_size * 3 + 1);
else
m_opcode.Dump(&ss, 15 * 3 + 1);
} else {
// Else, we have ARM or MIPS which can show up to a uint32_t
// 0x00000000 (10 spaces) plus two for padding...
if (max_opcode_byte_size > 0)
m_opcode.Dump(&ss, max_opcode_byte_size * 3 + 1);
else
m_opcode.Dump(&ss, 12);
<rdar://problem/11330621> Fixed the DisassemblerLLVMC disassembler to parse more efficiently instead of parsing opcodes over and over. The InstructionLLVMC class now only reads the opcode in the InstructionLLVMC::Decode function. This can be done very efficiently for ARM and architectures that have fixed opcode sizes. For x64 it still calls the disassembler to get the byte size. Moved the lldb_private::Instruction::Dump(...) function up into the lldb_private::Instruction class and it now uses the function that gets the mnemonic, operandes and comments so that all disassembly is using the same code. Added StreamString::FillLastLineToColumn() to allow filling a line up to a column with a character (which is used by the lldb_private::Instruction::Dump(...) function). Modified the Opcode::GetData() fucntion to "do the right thing" for thumb instructions. llvm-svn: 156532
2012-05-10 10:52:23 +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
}
const size_t opcode_pos = ss.GetSizeOfLastLine();
// The default opcode size of 7 characters is plenty for most architectures
// but some like arm can pull out the occasional vqrshrun.s16. We won't get
// consistent column spacing in these cases, unfortunately.
if (m_opcode_name.length() >= opcode_column_width) {
opcode_column_width = m_opcode_name.length() + 1;
}
ss.PutCString(m_opcode_name.c_str());
ss.FillLastLineToColumn(opcode_pos + opcode_column_width, ' ');
ss.PutCString(m_mnemonics.c_str());
if (!m_comment.empty()) {
ss.FillLastLineToColumn(
opcode_pos + opcode_column_width + operand_column_width, ' ');
ss.PutCString(" ; ");
ss.PutCString(m_comment.c_str());
}
s->Write(ss.GetData(), ss.GetSize());
<rdar://problem/11330621> Fixed the DisassemblerLLVMC disassembler to parse more efficiently instead of parsing opcodes over and over. The InstructionLLVMC class now only reads the opcode in the InstructionLLVMC::Decode function. This can be done very efficiently for ARM and architectures that have fixed opcode sizes. For x64 it still calls the disassembler to get the byte size. Moved the lldb_private::Instruction::Dump(...) function up into the lldb_private::Instruction class and it now uses the function that gets the mnemonic, operandes and comments so that all disassembly is using the same code. Added StreamString::FillLastLineToColumn() to allow filling a line up to a column with a character (which is used by the lldb_private::Instruction::Dump(...) function). Modified the Opcode::GetData() fucntion to "do the right thing" for thumb instructions. llvm-svn: 156532
2012-05-10 10:52:23 +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
bool Instruction::DumpEmulation(const ArchSpec &arch) {
std::unique_ptr<EmulateInstruction> insn_emulator_ap(
EmulateInstruction::FindPlugin(arch, eInstructionTypeAny, nullptr));
if (insn_emulator_ap) {
insn_emulator_ap->SetInstruction(GetOpcode(), GetAddress(), nullptr);
return insn_emulator_ap->EvaluateInstruction(0);
}
Add Emulate and DumpEmulation to Instruction class. Move InstructionLLVM out of DisassemblerLLVM class. Add instruction emulation function calls to SBInstruction and SBInstructionList APIs. llvm-svn: 128956
2011-04-06 07:22:54 +08:00
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
return false;
Add Emulate and DumpEmulation to Instruction class. Move InstructionLLVM out of DisassemblerLLVM class. Add instruction emulation function calls to SBInstruction and SBInstructionList APIs. llvm-svn: 128956
2011-04-06 07:22:54 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
bool Instruction::HasDelaySlot() {
// Default is false.
return false;
[MIPS] Avoid breakpoint in delay slot SUMMARY: This patch implements Target::GetBreakableLoadAddress() method that takes an address and checks for any reason there is a better address than this to put a breakpoint on. If there is then return that address. MIPS uses this method to avoid breakpoint in delay slot. Reviewers: clayborg, jingham Subscribers: jingham, mohit.bhakkad, sagar, jaydeep, nitesh.jain, lldb-commits Differential Revision: http://http://reviews.llvm.org/D12184 llvm-svn: 246015
2015-08-26 14:04:54 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
OptionValueSP Instruction::ReadArray(FILE *in_file, Stream *out_stream,
OptionValue::Type data_type) {
bool done = false;
char buffer[1024];
Change code for reading emulation data files to read the new file format. (The newly formatted files will go in as a separate commit in a few minutes). llvm-svn: 129981
2011-04-22 13:08:45 +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
OptionValueSP option_value_sp(new OptionValueArray(1u << data_type));
Change code for reading emulation data files to read the new file format. (The newly formatted files will go in as a separate commit in a few minutes). llvm-svn: 129981
2011-04-22 13:08:45 +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
int idx = 0;
while (!done) {
if (!fgets(buffer, 1023, in_file)) {
out_stream->Printf(
"Instruction::ReadArray: Error reading file (fgets).\n");
option_value_sp.reset();
return option_value_sp;
}
Change code for reading emulation data files to read the new file format. (The newly formatted files will go in as a separate commit in a few minutes). llvm-svn: 129981
2011-04-22 13:08:45 +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
std::string line(buffer);
Change code for reading emulation data files to read the new file format. (The newly formatted files will go in as a separate commit in a few minutes). llvm-svn: 129981
2011-04-22 13:08:45 +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
size_t len = line.size();
if (line[len - 1] == '\n') {
line[len - 1] = '\0';
line.resize(len - 1);
Change code for reading emulation data files to read the new file format. (The newly formatted files will go in as a separate commit in a few minutes). llvm-svn: 129981
2011-04-22 13:08:45 +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
if ((line.size() == 1) && line[0] == ']') {
done = true;
line.clear();
}
Change code for reading emulation data files to read the new file format. (The newly formatted files will go in as a separate commit in a few minutes). llvm-svn: 129981
2011-04-22 13:08:45 +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
if (!line.empty()) {
std::string value;
Make lldb::Regex use StringRef. This updates getters and setters to use StringRef instead of const char *. I tested the build on Linux, Windows, and OSX and saw no build or test failures. I cannot test any BSD or Android variants, however I expect the required changes to be minimal or non-existant. llvm-svn: 282079
2016-09-22 00:01:28 +08:00
static RegularExpression g_reg_exp(
llvm::StringRef("^[ \t]*([^ \t]+)[ \t]*$"));
*** 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
RegularExpression::Match regex_match(1);
Make lldb::Regex use StringRef. This updates getters and setters to use StringRef instead of const char *. I tested the build on Linux, Windows, and OSX and saw no build or test failures. I cannot test any BSD or Android variants, however I expect the required changes to be minimal or non-existant. llvm-svn: 282079
2016-09-22 00:01:28 +08:00
bool reg_exp_success = g_reg_exp.Execute(line, &regex_match);
*** 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 (reg_exp_success)
regex_match.GetMatchAtIndex(line.c_str(), 1, value);
else
value = line;
OptionValueSP data_value_sp;
switch (data_type) {
case OptionValue::eTypeUInt64:
data_value_sp.reset(new OptionValueUInt64(0, 0));
data_value_sp->SetValueFromString(value);
break;
// Other types can be added later as needed.
default:
data_value_sp.reset(new OptionValueString(value.c_str(), ""));
break;
}
option_value_sp->GetAsArray()->InsertValue(idx, data_value_sp);
++idx;
Change code for reading emulation data files to read the new file format. (The newly formatted files will go in as a separate commit in a few minutes). llvm-svn: 129981
2011-04-22 13:08:45 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
}
Change code for reading emulation data files to read the new file format. (The newly formatted files will go in as a separate commit in a few minutes). llvm-svn: 129981
2011-04-22 13:08:45 +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
return option_value_sp;
}
Add the infrastructure to test instruction emulations automatically. The idea is that the instruction to be emulated is actually executed on the hardware to be emulated, with the before and after state of the hardware being captured and 'freeze-dried' into .dat files. The emulation testing code then loads the before & after state from the .dat file, emulates the instruction using the before state, and compares the resulting state to the 'after' state. If they match, the emulation is accurate, otherwise there is a problem. The final format of the .dat files needs a bit more work; the plan is to generalize them a bit and to convert the plain values to key-value pairs. But I wanted to get this first pass committed. This commit adds arm instruction emulation testing to the testsuite, along with many initial .dat files. It also fixes a bug in the llvm disassembler, where 32-bit thumb opcodes were getting their upper & lower 16-bits reversed. There is a new Instruction sub-class, that is intended to be loaded from a .dat file rather than read from an executable. There is also a new EmulationStateARM class, for handling the before & after states. EmulationStates for other architetures can be added later when we emulate their instructions. llvm-svn: 129832
2011-04-20 07:30:03 +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
OptionValueSP Instruction::ReadDictionary(FILE *in_file, Stream *out_stream) {
bool done = false;
char buffer[1024];
OptionValueSP option_value_sp(new OptionValueDictionary());
static ConstString encoding_key("data_encoding");
OptionValue::Type data_type = OptionValue::eTypeInvalid;
while (!done) {
// Read the next line in the file
if (!fgets(buffer, 1023, in_file)) {
out_stream->Printf(
"Instruction::ReadDictionary: Error reading file (fgets).\n");
option_value_sp.reset();
return option_value_sp;
Add the infrastructure to test instruction emulations automatically. The idea is that the instruction to be emulated is actually executed on the hardware to be emulated, with the before and after state of the hardware being captured and 'freeze-dried' into .dat files. The emulation testing code then loads the before & after state from the .dat file, emulates the instruction using the before state, and compares the resulting state to the 'after' state. If they match, the emulation is accurate, otherwise there is a problem. The final format of the .dat files needs a bit more work; the plan is to generalize them a bit and to convert the plain values to key-value pairs. But I wanted to get this first pass committed. This commit adds arm instruction emulation testing to the testsuite, along with many initial .dat files. It also fixes a bug in the llvm disassembler, where 32-bit thumb opcodes were getting their upper & lower 16-bits reversed. There is a new Instruction sub-class, that is intended to be loaded from a .dat file rather than read from an executable. There is also a new EmulationStateARM class, for handling the before & after states. EmulationStates for other architetures can be added later when we emulate their instructions. llvm-svn: 129832
2011-04-20 07:30:03 +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
// Check to see if the line contains the end-of-dictionary marker ("}")
std::string line(buffer);
size_t len = line.size();
if (line[len - 1] == '\n') {
line[len - 1] = '\0';
line.resize(len - 1);
Add the infrastructure to test instruction emulations automatically. The idea is that the instruction to be emulated is actually executed on the hardware to be emulated, with the before and after state of the hardware being captured and 'freeze-dried' into .dat files. The emulation testing code then loads the before & after state from the .dat file, emulates the instruction using the before state, and compares the resulting state to the 'after' state. If they match, the emulation is accurate, otherwise there is a problem. The final format of the .dat files needs a bit more work; the plan is to generalize them a bit and to convert the plain values to key-value pairs. But I wanted to get this first pass committed. This commit adds arm instruction emulation testing to the testsuite, along with many initial .dat files. It also fixes a bug in the llvm disassembler, where 32-bit thumb opcodes were getting their upper & lower 16-bits reversed. There is a new Instruction sub-class, that is intended to be loaded from a .dat file rather than read from an executable. There is also a new EmulationStateARM class, for handling the before & after states. EmulationStates for other architetures can be added later when we emulate their instructions. llvm-svn: 129832
2011-04-20 07:30:03 +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
if ((line.size() == 1) && (line[0] == '}')) {
done = true;
line.clear();
Add the infrastructure to test instruction emulations automatically. The idea is that the instruction to be emulated is actually executed on the hardware to be emulated, with the before and after state of the hardware being captured and 'freeze-dried' into .dat files. The emulation testing code then loads the before & after state from the .dat file, emulates the instruction using the before state, and compares the resulting state to the 'after' state. If they match, the emulation is accurate, otherwise there is a problem. The final format of the .dat files needs a bit more work; the plan is to generalize them a bit and to convert the plain values to key-value pairs. But I wanted to get this first pass committed. This commit adds arm instruction emulation testing to the testsuite, along with many initial .dat files. It also fixes a bug in the llvm disassembler, where 32-bit thumb opcodes were getting their upper & lower 16-bits reversed. There is a new Instruction sub-class, that is intended to be loaded from a .dat file rather than read from an executable. There is also a new EmulationStateARM class, for handling the before & after states. EmulationStates for other architetures can be added later when we emulate their instructions. llvm-svn: 129832
2011-04-20 07:30:03 +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
// Try to find a key-value pair in the current line and add it to the
// dictionary.
if (!line.empty()) {
Make lldb::Regex use StringRef. This updates getters and setters to use StringRef instead of const char *. I tested the build on Linux, Windows, and OSX and saw no build or test failures. I cannot test any BSD or Android variants, however I expect the required changes to be minimal or non-existant. llvm-svn: 282079
2016-09-22 00:01:28 +08:00
static RegularExpression g_reg_exp(llvm::StringRef(
"^[ \t]*([a-zA-Z_][a-zA-Z0-9_]*)[ \t]*=[ \t]*(.*)[ \t]*$"));
*** 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
RegularExpression::Match regex_match(2);
Make lldb::Regex use StringRef. This updates getters and setters to use StringRef instead of const char *. I tested the build on Linux, Windows, and OSX and saw no build or test failures. I cannot test any BSD or Android variants, however I expect the required changes to be minimal or non-existant. llvm-svn: 282079
2016-09-22 00:01:28 +08:00
bool reg_exp_success = g_reg_exp.Execute(line, &regex_match);
*** 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
std::string key;
std::string value;
if (reg_exp_success) {
regex_match.GetMatchAtIndex(line.c_str(), 1, key);
regex_match.GetMatchAtIndex(line.c_str(), 2, value);
} else {
out_stream->Printf("Instruction::ReadDictionary: Failure executing "
"regular expression.\n");
option_value_sp.reset();
return option_value_sp;
}
ConstString const_key(key.c_str());
// Check value to see if it's the start of an array or dictionary.
lldb::OptionValueSP value_sp;
assert(value.empty() == false);
assert(key.empty() == false);
if (value[0] == '{') {
assert(value.size() == 1);
// value is a dictionary
value_sp = ReadDictionary(in_file, out_stream);
if (!value_sp) {
option_value_sp.reset();
return option_value_sp;
}
} else if (value[0] == '[') {
assert(value.size() == 1);
// value is an array
value_sp = ReadArray(in_file, out_stream, data_type);
if (!value_sp) {
option_value_sp.reset();
return option_value_sp;
}
// We've used the data_type to read an array; re-set the type to Invalid
data_type = OptionValue::eTypeInvalid;
} else if ((value[0] == '0') && (value[1] == 'x')) {
value_sp.reset(new OptionValueUInt64(0, 0));
value_sp->SetValueFromString(value);
} else {
size_t len = value.size();
if ((value[0] == '"') && (value[len - 1] == '"'))
value = value.substr(1, len - 2);
value_sp.reset(new OptionValueString(value.c_str(), ""));
}
if (const_key == encoding_key) {
// A 'data_encoding=..." is NOT a normal key-value pair; it is meta-data
// indicating the
// data type of an upcoming array (usually the next bit of data to be
// read in).
if (strcmp(value.c_str(), "uint32_t") == 0)
data_type = OptionValue::eTypeUInt64;
} else
option_value_sp->GetAsDictionary()->SetValueForKey(const_key, value_sp,
false);
Change code for reading emulation data files to read the new file format. (The newly formatted files will go in as a separate commit in a few minutes). llvm-svn: 129981
2011-04-22 13:08:45 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
}
Change code for reading emulation data files to read the new file format. (The newly formatted files will go in as a separate commit in a few minutes). llvm-svn: 129981
2011-04-22 13:08:45 +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
return option_value_sp;
}
Change code for reading emulation data files to read the new file format. (The newly formatted files will go in as a separate commit in a few minutes). llvm-svn: 129981
2011-04-22 13:08:45 +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
bool Instruction::TestEmulation(Stream *out_stream, const char *file_name) {
if (!out_stream)
return false;
Change code for reading emulation data files to read the new file format. (The newly formatted files will go in as a separate commit in a few minutes). llvm-svn: 129981
2011-04-22 13:08:45 +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
if (!file_name) {
out_stream->Printf("Instruction::TestEmulation: Missing file_name.");
return false;
}
FILE *test_file = FileSystem::Fopen(file_name, "r");
if (!test_file) {
out_stream->Printf(
"Instruction::TestEmulation: Attempt to open test file failed.");
return false;
}
Change code for reading emulation data files to read the new file format. (The newly formatted files will go in as a separate commit in a few minutes). llvm-svn: 129981
2011-04-22 13:08:45 +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
char buffer[256];
if (!fgets(buffer, 255, test_file)) {
out_stream->Printf(
"Instruction::TestEmulation: Error reading first line of test file.\n");
fclose(test_file);
return false;
}
Change code for reading emulation data files to read the new file format. (The newly formatted files will go in as a separate commit in a few minutes). llvm-svn: 129981
2011-04-22 13:08:45 +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
if (strncmp(buffer, "InstructionEmulationState={", 27) != 0) {
out_stream->Printf("Instructin::TestEmulation: Test file does not contain "
"emulation state dictionary\n");
fclose(test_file);
return false;
}
Change code for reading emulation data files to read the new file format. (The newly formatted files will go in as a separate commit in a few minutes). llvm-svn: 129981
2011-04-22 13:08:45 +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
// Read all the test information from the test file into an
// OptionValueDictionary.
Fix Clang-tidy modernize-use-nullptr warnings in some files in source/Core; other minor fixes. llvm-svn: 262570
2016-03-03 08:51:40 +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
OptionValueSP data_dictionary_sp(ReadDictionary(test_file, out_stream));
if (!data_dictionary_sp) {
out_stream->Printf(
"Instruction::TestEmulation: Error reading Dictionary Object.\n");
fclose(test_file);
return false;
}
Add the infrastructure to test instruction emulations automatically. The idea is that the instruction to be emulated is actually executed on the hardware to be emulated, with the before and after state of the hardware being captured and 'freeze-dried' into .dat files. The emulation testing code then loads the before & after state from the .dat file, emulates the instruction using the before state, and compares the resulting state to the 'after' state. If they match, the emulation is accurate, otherwise there is a problem. The final format of the .dat files needs a bit more work; the plan is to generalize them a bit and to convert the plain values to key-value pairs. But I wanted to get this first pass committed. This commit adds arm instruction emulation testing to the testsuite, along with many initial .dat files. It also fixes a bug in the llvm disassembler, where 32-bit thumb opcodes were getting their upper & lower 16-bits reversed. There is a new Instruction sub-class, that is intended to be loaded from a .dat file rather than read from an executable. There is also a new EmulationStateARM class, for handling the before & after states. EmulationStates for other architetures can be added later when we emulate their instructions. llvm-svn: 129832
2011-04-20 07:30:03 +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
fclose(test_file);
OptionValueDictionary *data_dictionary =
data_dictionary_sp->GetAsDictionary();
static ConstString description_key("assembly_string");
static ConstString triple_key("triple");
Add Emulate and DumpEmulation to Instruction class. Move InstructionLLVM out of DisassemblerLLVM class. Add instruction emulation function calls to SBInstruction and SBInstructionList APIs. llvm-svn: 128956
2011-04-06 07:22:54 +08:00
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
OptionValueSP value_sp = data_dictionary->GetValueForKey(description_key);
if (!value_sp) {
out_stream->Printf("Instruction::TestEmulation: Test file does not "
"contain description string.\n");
Add Emulate and DumpEmulation to Instruction class. Move InstructionLLVM out of DisassemblerLLVM class. Add instruction emulation function calls to SBInstruction and SBInstructionList APIs. llvm-svn: 128956
2011-04-06 07:22:54 +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
}
Add Emulate and DumpEmulation to Instruction class. Move InstructionLLVM out of DisassemblerLLVM class. Add instruction emulation function calls to SBInstruction and SBInstructionList APIs. llvm-svn: 128956
2011-04-06 07:22:54 +08:00
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
SetDescription(value_sp->GetStringValue());
<rdar://problem/11330621> Fixed the DisassemblerLLVMC disassembler to parse more efficiently instead of parsing opcodes over and over. The InstructionLLVMC class now only reads the opcode in the InstructionLLVMC::Decode function. This can be done very efficiently for ARM and architectures that have fixed opcode sizes. For x64 it still calls the disassembler to get the byte size. Moved the lldb_private::Instruction::Dump(...) function up into the lldb_private::Instruction class and it now uses the function that gets the mnemonic, operandes and comments so that all disassembly is using the same code. Added StreamString::FillLastLineToColumn() to allow filling a line up to a column with a character (which is used by the lldb_private::Instruction::Dump(...) function). Modified the Opcode::GetData() fucntion to "do the right thing" for thumb instructions. llvm-svn: 156532
2012-05-10 10:52:23 +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
value_sp = data_dictionary->GetValueForKey(triple_key);
if (!value_sp) {
out_stream->Printf(
"Instruction::TestEmulation: Test file does not contain triple.\n");
return false;
}
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
ArchSpec arch;
arch.SetTriple(llvm::Triple(value_sp->GetStringValue()));
bool success = false;
std::unique_ptr<EmulateInstruction> insn_emulator_ap(
EmulateInstruction::FindPlugin(arch, eInstructionTypeAny, nullptr));
if (insn_emulator_ap)
success =
insn_emulator_ap->TestEmulation(out_stream, arch, data_dictionary);
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
if (success)
out_stream->Printf("Emulation test succeeded.");
else
out_stream->Printf("Emulation test failed.");
return success;
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
bool Instruction::Emulate(
const ArchSpec &arch, uint32_t evaluate_options, void *baton,
EmulateInstruction::ReadMemoryCallback read_mem_callback,
EmulateInstruction::WriteMemoryCallback write_mem_callback,
EmulateInstruction::ReadRegisterCallback read_reg_callback,
EmulateInstruction::WriteRegisterCallback write_reg_callback) {
std::unique_ptr<EmulateInstruction> insn_emulator_ap(
EmulateInstruction::FindPlugin(arch, eInstructionTypeAny, nullptr));
if (insn_emulator_ap) {
insn_emulator_ap->SetBaton(baton);
insn_emulator_ap->SetCallbacks(read_mem_callback, write_mem_callback,
read_reg_callback, write_reg_callback);
insn_emulator_ap->SetInstruction(GetOpcode(), GetAddress(), nullptr);
return insn_emulator_ap->EvaluateInstruction(evaluate_options);
}
return false;
Added the ability to get the min and max instruction byte size for an architecture into ArchSpec: uint32_t ArchSpec::GetMinimumOpcodeByteSize() const; uint32_t ArchSpec::GetMaximumOpcodeByteSize() const; Added an AddressClass to the Instruction class in Disassembler.h. This allows decoded instructions to know know if they are code, code with alternate ISA (thumb), or even data which can be mixed into code. The instruction does have an address, but it is a good idea to cache this value so we don't have to look it up more than once. Fixed an issue in Opcode::SetOpcodeBytes() where the length wasn't getting set. Changed: bool SymbolContextList::AppendIfUnique (const SymbolContext& sc); To: bool SymbolContextList::AppendIfUnique (const SymbolContext& sc, bool merge_symbol_into_function); This function was typically being used when looking up functions and symbols. Now if you lookup a function, then find the symbol, they can be merged into the same symbol context and not cause multiple symbol contexts to appear in a symbol context list that describes the same function. Fixed the SymbolContext not equal operator which was causing mixed mode disassembly to not work ("disassembler --mixed --name main"). Modified the disassembler classes to know about the fact we know, for a given architecture, what the min and max opcode byte sizes are. The InstructionList class was modified to return the max opcode byte size for all of the instructions in its list. These two fixes means when disassemble a list of instructions and dump them and show the opcode bytes, we can format the output more intelligently when showing opcode bytes. This affects any architectures that have varying opcode byte sizes (x86_64 and i386). Knowing the max opcode byte size also helps us to be able to disassemble N instructions without having to re-read data if we didn't read enough bytes. Added the ability to set the architecture for the disassemble command. This means you can easily cross disassemble data for any supported architecture. I also added the ability to specify "thumb" as an architecture so that we can force disassembly into thumb mode when needed. In GDB this was done using a hack of specifying an odd address when disassembling. I don't want to repeat this hack in LLDB, so the auto detection between ARM and thumb is failing, just specify thumb when disassembling: (lldb) disassemble --arch thumb --name main You can also have data in say an x86_64 file executable and disassemble data as any other supported architecture: % lldb a.out Current executable set to 'a.out' (x86_64). (lldb) b main (lldb) run (lldb) disassemble --arch thumb --count 2 --start-address 0x0000000100001080 --bytes 0x100001080: 0xb580 push {r7, lr} 0x100001082: 0xaf00 add r7, sp, #0 Fixed Target::ReadMemory(...) to be able to deal with Address argument object that isn't section offset. When an address object was supplied that was out on the heap or stack, target read memory would fail. Disassembly uses Target::ReadMemory(...), and the example above where we disassembler thumb opcodes in an x86 binary was failing do to this bug. llvm-svn: 128347
2011-03-27 03:14:58 +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
uint32_t Instruction::GetData(DataExtractor &data) {
return m_opcode.GetData(data);
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
InstructionList::InstructionList() : m_instructions() {}
Get rid of Debugger::FormatPrompt() and replace it with the new FormatEntity class. Why? Debugger::FormatPrompt() would run through the format prompt every time and parse it and emit it piece by piece. It also did formatting differently depending on which key/value pair it was parsing. The new code improves on this with the following features: 1 - Allow format strings to be parsed into a FormatEntity::Entry which can contain multiple child FormatEntity::Entry objects. This FormatEntity::Entry is a parsed version of what was previously always done in Debugger::FormatPrompt() so it is more efficient to emit formatted strings using the new parsed FormatEntity::Entry. 2 - Allows errors in format strings to be shown immediately when setting the settings (frame-format, thread-format, disassembly-format 3 - Allows auto completion by implementing a new OptionValueFormatEntity and switching frame-format, thread-format, and disassembly-format settings over to using it. 4 - The FormatEntity::Entry for each of the frame-format, thread-format, disassembly-format settings only replaces the old one if the format parses correctly 5 - Combines all consecutive string values together for efficient output. This means all "${ansi.*}" keys and all desensitized characters like "\n" "\t" "\0721" "\x23" will get combined with their previous strings 6 - ${*.script:} (like "${var.script:mymodule.my_var_function}") have all been switched over to use ${script.*:} "${script.var:mymodule.my_var_function}") to make the format easier to parse as I don't believe anyone was using these format string power user features. 7 - All key values pairs are defined in simple C arrays of entries so it is much easier to add new entries. These changes pave the way for subsequent modifications where we can modify formats to do more (like control the width of value strings can do more and add more functionality more easily like string formatting to control the width, printf formats and more). llvm-svn: 228207
2015-02-05 06:00:53 +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
InstructionList::~InstructionList() = default;
size_t InstructionList::GetSize() const { return m_instructions.size(); }
uint32_t InstructionList::GetMaxOpcocdeByteSize() const {
uint32_t max_inst_size = 0;
collection::const_iterator pos, end;
for (pos = m_instructions.begin(), end = m_instructions.end(); pos != end;
++pos) {
uint32_t inst_size = (*pos)->GetOpcode().GetByteSize();
if (max_inst_size < inst_size)
max_inst_size = inst_size;
}
return max_inst_size;
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
}
*** 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
InstructionSP InstructionList::GetInstructionAtIndex(size_t idx) const {
InstructionSP inst_sp;
if (idx < m_instructions.size())
inst_sp = m_instructions[idx];
return inst_sp;
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
void InstructionList::Dump(Stream *s, bool show_address, bool show_bytes,
const ExecutionContext *exe_ctx) {
const uint32_t max_opcode_byte_size = GetMaxOpcocdeByteSize();
collection::const_iterator pos, begin, end;
const FormatEntity::Entry *disassembly_format = nullptr;
FormatEntity::Entry format;
if (exe_ctx && exe_ctx->HasTargetScope()) {
disassembly_format =
exe_ctx->GetTargetRef().GetDebugger().GetDisassemblyFormat();
} else {
FormatEntity::Parse("${addr}: ", format);
disassembly_format = &format;
}
for (begin = m_instructions.begin(), end = m_instructions.end(), pos = begin;
pos != end; ++pos) {
if (pos != begin)
s->EOL();
(*pos)->Dump(s, max_opcode_byte_size, show_address, show_bytes, exe_ctx,
nullptr, nullptr, disassembly_format, 0);
}
}
void InstructionList::Clear() { m_instructions.clear(); }
void InstructionList::Append(lldb::InstructionSP &inst_sp) {
if (inst_sp)
m_instructions.push_back(inst_sp);
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
First stage of implementing step by "run to next branch". Doesn't work yet, is turned off. <rdar://problem/10975912> llvm-svn: 152376
2012-03-09 12:10:47 +08:00
uint32_t
*** 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
InstructionList::GetIndexOfNextBranchInstruction(uint32_t start,
Target &target) const {
size_t num_instructions = m_instructions.size();
uint32_t next_branch = UINT32_MAX;
size_t i;
for (i = start; i < num_instructions; i++) {
if (m_instructions[i]->DoesBranch()) {
next_branch = i;
break;
}
}
// Hexagon needs the first instruction of the packet with the branch.
// Go backwards until we find an instruction marked end-of-packet, or
// until we hit start.
if (target.GetArchitecture().GetTriple().getArch() == llvm::Triple::hexagon) {
// If we didn't find a branch, find the last packet start.
if (next_branch == UINT32_MAX) {
i = num_instructions - 1;
First stage of implementing step by "run to next branch". Doesn't work yet, is turned off. <rdar://problem/10975912> llvm-svn: 152376
2012-03-09 12:10:47 +08:00
}
Add Hexagon packet support to ThreadPlanStepRange Summary: Hexagon is a VLIW processor. It can execute multiple instructions at once, called a packet. Breakpoints need to be alone in a packet. This patch will make sure that temporary breakpoints used for stepping are set at the start of a packet, which will put the breakpoint in a packet by itself. Patch by Deepak Panickal of CodePlay and Ted Woodward of Qualcomm. Reviewers: deepak2427, clayborg Reviewed By: clayborg Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D9437 llvm-svn: 237047
2015-05-12 05:12:33 +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
while (i > start) {
--i;
Error error;
uint32_t inst_bytes;
bool prefer_file_cache = false; // Read from process if process is running
lldb::addr_t load_addr = LLDB_INVALID_ADDRESS;
target.ReadMemory(m_instructions[i]->GetAddress(), prefer_file_cache,
&inst_bytes, sizeof(inst_bytes), error, &load_addr);
// If we have an error reading memory, return start
if (!error.Success())
return start;
// check if this is the last instruction in a packet
// bits 15:14 will be 11b or 00b for a duplex
if (((inst_bytes & 0xC000) == 0xC000) ||
((inst_bytes & 0xC000) == 0x0000)) {
// instruction after this should be the start of next packet
next_branch = i + 1;
break;
}
}
Add Hexagon packet support to ThreadPlanStepRange Summary: Hexagon is a VLIW processor. It can execute multiple instructions at once, called a packet. Breakpoints need to be alone in a packet. This patch will make sure that temporary breakpoints used for stepping are set at the start of a packet, which will put the breakpoint in a packet by itself. Patch by Deepak Panickal of CodePlay and Ted Woodward of Qualcomm. Reviewers: deepak2427, clayborg Reviewed By: clayborg Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D9437 llvm-svn: 237047
2015-05-12 05:12:33 +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
if (next_branch == UINT32_MAX) {
// We couldn't find the previous packet, so return start
next_branch = start;
Add Hexagon packet support to ThreadPlanStepRange Summary: Hexagon is a VLIW processor. It can execute multiple instructions at once, called a packet. Breakpoints need to be alone in a packet. This patch will make sure that temporary breakpoints used for stepping are set at the start of a packet, which will put the breakpoint in a packet by itself. Patch by Deepak Panickal of CodePlay and Ted Woodward of Qualcomm. Reviewers: deepak2427, clayborg Reviewed By: clayborg Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D9437 llvm-svn: 237047
2015-05-12 05:12:33 +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
}
return next_branch;
First stage of implementing step by "run to next branch". Doesn't work yet, is turned off. <rdar://problem/10975912> llvm-svn: 152376
2012-03-09 12:10:47 +08:00
}
uint32_t
*** 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
InstructionList::GetIndexOfInstructionAtAddress(const Address &address) {
size_t num_instructions = m_instructions.size();
uint32_t index = UINT32_MAX;
for (size_t i = 0; i < num_instructions; i++) {
if (m_instructions[i]->GetAddress() == address) {
index = i;
break;
First stage of implementing step by "run to next branch". Doesn't work yet, is turned off. <rdar://problem/10975912> llvm-svn: 152376
2012-03-09 12:10:47 +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
}
return index;
First stage of implementing step by "run to next branch". Doesn't work yet, is turned off. <rdar://problem/10975912> llvm-svn: 152376
2012-03-09 12:10:47 +08:00
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
Merging the iohandler branch back into main. The many many benefits include: 1 - Input/Output/Error streams are now handled as real streams not a push style input 2 - auto completion in python embedded interpreter 3 - multi-line input for "script" and "expression" commands now allow you to edit previous/next lines using up and down arrow keys and this makes multi-line input actually a viable thing to use 4 - it is now possible to use curses to drive LLDB (please try the "gui" command) We will need to deal with and fix any buildbot failures and tests and arise now that input/output and error are correctly hooked up in all cases. llvm-svn: 200263
2014-01-28 07:43:24 +08:00
uint32_t
*** 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
InstructionList::GetIndexOfInstructionAtLoadAddress(lldb::addr_t load_addr,
Target &target) {
Address address;
address.SetLoadAddress(load_addr, &target);
return GetIndexOfInstructionAtAddress(address);
Merging the iohandler branch back into main. The many many benefits include: 1 - Input/Output/Error streams are now handled as real streams not a push style input 2 - auto completion in python embedded interpreter 3 - multi-line input for "script" and "expression" commands now allow you to edit previous/next lines using up and down arrow keys and this makes multi-line input actually a viable thing to use 4 - it is now possible to use curses to drive LLDB (please try the "gui" command) We will need to deal with and fix any buildbot failures and tests and arise now that input/output and error are correctly hooked up in all cases. llvm-svn: 200263
2014-01-28 07:43: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
size_t Disassembler::ParseInstructions(const ExecutionContext *exe_ctx,
const AddressRange &range,
Stream *error_strm_ptr,
bool prefer_file_cache) {
if (exe_ctx) {
Target *target = exe_ctx->GetTargetPtr();
const addr_t byte_size = range.GetByteSize();
if (target == nullptr || byte_size == 0 ||
!range.GetBaseAddress().IsValid())
return 0;
DataBufferHeap *heap_buffer = new DataBufferHeap(byte_size, '\0');
DataBufferSP data_sp(heap_buffer);
Error error;
lldb::addr_t load_addr = LLDB_INVALID_ADDRESS;
const size_t bytes_read = target->ReadMemory(
range.GetBaseAddress(), prefer_file_cache, heap_buffer->GetBytes(),
heap_buffer->GetByteSize(), error, &load_addr);
if (bytes_read > 0) {
if (bytes_read != heap_buffer->GetByteSize())
heap_buffer->SetByteSize(bytes_read);
DataExtractor data(data_sp, m_arch.GetByteOrder(),
m_arch.GetAddressByteSize());
const bool data_from_file = load_addr == LLDB_INVALID_ADDRESS;
return DecodeInstructions(range.GetBaseAddress(), data, 0, UINT32_MAX,
false, data_from_file);
} else if (error_strm_ptr) {
const char *error_cstr = error.AsCString();
if (error_cstr) {
error_strm_ptr->Printf("error: %s\n", error_cstr);
}
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 if (error_strm_ptr) {
error_strm_ptr->PutCString("error: invalid execution context\n");
}
return 0;
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
size_t Disassembler::ParseInstructions(const ExecutionContext *exe_ctx,
const Address &start,
uint32_t num_instructions,
bool prefer_file_cache) {
m_instruction_list.Clear();
Added the ability to get the min and max instruction byte size for an architecture into ArchSpec: uint32_t ArchSpec::GetMinimumOpcodeByteSize() const; uint32_t ArchSpec::GetMaximumOpcodeByteSize() const; Added an AddressClass to the Instruction class in Disassembler.h. This allows decoded instructions to know know if they are code, code with alternate ISA (thumb), or even data which can be mixed into code. The instruction does have an address, but it is a good idea to cache this value so we don't have to look it up more than once. Fixed an issue in Opcode::SetOpcodeBytes() where the length wasn't getting set. Changed: bool SymbolContextList::AppendIfUnique (const SymbolContext& sc); To: bool SymbolContextList::AppendIfUnique (const SymbolContext& sc, bool merge_symbol_into_function); This function was typically being used when looking up functions and symbols. Now if you lookup a function, then find the symbol, they can be merged into the same symbol context and not cause multiple symbol contexts to appear in a symbol context list that describes the same function. Fixed the SymbolContext not equal operator which was causing mixed mode disassembly to not work ("disassembler --mixed --name main"). Modified the disassembler classes to know about the fact we know, for a given architecture, what the min and max opcode byte sizes are. The InstructionList class was modified to return the max opcode byte size for all of the instructions in its list. These two fixes means when disassemble a list of instructions and dump them and show the opcode bytes, we can format the output more intelligently when showing opcode bytes. This affects any architectures that have varying opcode byte sizes (x86_64 and i386). Knowing the max opcode byte size also helps us to be able to disassemble N instructions without having to re-read data if we didn't read enough bytes. Added the ability to set the architecture for the disassemble command. This means you can easily cross disassemble data for any supported architecture. I also added the ability to specify "thumb" as an architecture so that we can force disassembly into thumb mode when needed. In GDB this was done using a hack of specifying an odd address when disassembling. I don't want to repeat this hack in LLDB, so the auto detection between ARM and thumb is failing, just specify thumb when disassembling: (lldb) disassemble --arch thumb --name main You can also have data in say an x86_64 file executable and disassemble data as any other supported architecture: % lldb a.out Current executable set to 'a.out' (x86_64). (lldb) b main (lldb) run (lldb) disassemble --arch thumb --count 2 --start-address 0x0000000100001080 --bytes 0x100001080: 0xb580 push {r7, lr} 0x100001082: 0xaf00 add r7, sp, #0 Fixed Target::ReadMemory(...) to be able to deal with Address argument object that isn't section offset. When an address object was supplied that was out on the heap or stack, target read memory would fail. Disassembly uses Target::ReadMemory(...), and the example above where we disassembler thumb opcodes in an x86 binary was failing do to this bug. llvm-svn: 128347
2011-03-27 03:14:58 +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
if (exe_ctx == nullptr || num_instructions == 0 || !start.IsValid())
return 0;
Add the ability to disassemble "n" instructions from the current PC, or the first "n" instructions in a function. Also added a "-p" flag that disassembles from the current pc. llvm-svn: 128063
2011-03-22 09:48:42 +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
Target *target = exe_ctx->GetTargetPtr();
// Calculate the max buffer size we will need in order to disassemble
const addr_t byte_size = num_instructions * m_arch.GetMaximumOpcodeByteSize();
Add the ability to disassemble "n" instructions from the current PC, or the first "n" instructions in a function. Also added a "-p" flag that disassembles from the current pc. llvm-svn: 128063
2011-03-22 09:48:42 +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
if (target == nullptr || byte_size == 0)
return 0;
DataBufferHeap *heap_buffer = new DataBufferHeap(byte_size, '\0');
DataBufferSP data_sp(heap_buffer);
Error error;
lldb::addr_t load_addr = LLDB_INVALID_ADDRESS;
const size_t bytes_read =
target->ReadMemory(start, prefer_file_cache, heap_buffer->GetBytes(),
byte_size, error, &load_addr);
const bool data_from_file = load_addr == LLDB_INVALID_ADDRESS;
if (bytes_read == 0)
return 0;
DataExtractor data(data_sp, m_arch.GetByteOrder(),
m_arch.GetAddressByteSize());
const bool append_instructions = true;
DecodeInstructions(start, data, 0, num_instructions, append_instructions,
data_from_file);
return m_instruction_list.GetSize();
Add the ability to disassemble "n" instructions from the current PC, or the first "n" instructions in a function. Also added a "-p" flag that disassembles from the current pc. llvm-svn: 128063
2011-03-22 09:48:42 +08:00
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
//----------------------------------------------------------------------
// Disassembler copy constructor
//----------------------------------------------------------------------
*** 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
Disassembler::Disassembler(const ArchSpec &arch, const char *flavor)
: m_arch(arch), m_instruction_list(), m_base_addr(LLDB_INVALID_ADDRESS),
m_flavor() {
if (flavor == nullptr)
m_flavor.assign("default");
else
m_flavor.assign(flavor);
// If this is an arm variant that can only include thumb (T16, T32)
// instructions, force the arch triple to be "thumbv.." instead of
// "armv..."
if (arch.IsAlwaysThumbInstructions()) {
std::string thumb_arch_name(arch.GetTriple().getArchName().str());
// Replace "arm" with "thumb" so we get all thumb variants correct
if (thumb_arch_name.size() > 3) {
thumb_arch_name.erase(0, 3);
thumb_arch_name.insert(0, "thumb");
When creating a disassembler for one of the arm variants that can only execute thumb instructions, force the arch triple string to be "thumbv..." instead of "armv..." so we do the right thing by default when disassembling arbitrary chunks of code. <rdar://problem/15126397> llvm-svn: 228486
2015-02-07 14:03:49 +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
m_arch.SetTriple(thumb_arch_name.c_str());
}
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 warnings in some files in source/Core; other minor fixes. llvm-svn: 262570
2016-03-03 08:51:40 +08:00
Disassembler::~Disassembler() = default;
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
InstructionList &Disassembler::GetInstructionList() {
return m_instruction_list;
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
const InstructionList &Disassembler::GetInstructionList() const {
return m_instruction_list;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
Add the infrastructure to test instruction emulations automatically. The idea is that the instruction to be emulated is actually executed on the hardware to be emulated, with the before and after state of the hardware being captured and 'freeze-dried' into .dat files. The emulation testing code then loads the before & after state from the .dat file, emulates the instruction using the before state, and compares the resulting state to the 'after' state. If they match, the emulation is accurate, otherwise there is a problem. The final format of the .dat files needs a bit more work; the plan is to generalize them a bit and to convert the plain values to key-value pairs. But I wanted to get this first pass committed. This commit adds arm instruction emulation testing to the testsuite, along with many initial .dat files. It also fixes a bug in the llvm disassembler, where 32-bit thumb opcodes were getting their upper & lower 16-bits reversed. There is a new Instruction sub-class, that is intended to be loaded from a .dat file rather than read from an executable. There is also a new EmulationStateARM class, for handling the before & after states. EmulationStates for other architetures can be added later when we emulate their instructions. llvm-svn: 129832
2011-04-20 07:30:03 +08:00
//----------------------------------------------------------------------
// Class PseudoInstruction
//----------------------------------------------------------------------
Fix Clang-tidy modernize-use-nullptr warnings in some files in source/Core; other minor fixes. llvm-svn: 262570
2016-03-03 08:51:40 +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
PseudoInstruction::PseudoInstruction()
: Instruction(Address(), eAddressClassUnknown), m_description() {}
Add the infrastructure to test instruction emulations automatically. The idea is that the instruction to be emulated is actually executed on the hardware to be emulated, with the before and after state of the hardware being captured and 'freeze-dried' into .dat files. The emulation testing code then loads the before & after state from the .dat file, emulates the instruction using the before state, and compares the resulting state to the 'after' state. If they match, the emulation is accurate, otherwise there is a problem. The final format of the .dat files needs a bit more work; the plan is to generalize them a bit and to convert the plain values to key-value pairs. But I wanted to get this first pass committed. This commit adds arm instruction emulation testing to the testsuite, along with many initial .dat files. It also fixes a bug in the llvm disassembler, where 32-bit thumb opcodes were getting their upper & lower 16-bits reversed. There is a new Instruction sub-class, that is intended to be loaded from a .dat file rather than read from an executable. There is also a new EmulationStateARM class, for handling the before & after states. EmulationStates for other architetures can be added later when we emulate their instructions. llvm-svn: 129832
2011-04-20 07:30:03 +08:00
Fix Clang-tidy modernize-use-nullptr warnings in some files in source/Core; other minor fixes. llvm-svn: 262570
2016-03-03 08:51:40 +08:00
PseudoInstruction::~PseudoInstruction() = 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
bool PseudoInstruction::DoesBranch() {
// This is NOT a valid question for a pseudo instruction.
return false;
[MIPS] Avoid breakpoint in delay slot SUMMARY: This patch implements Target::GetBreakableLoadAddress() method that takes an address and checks for any reason there is a better address than this to put a breakpoint on. If there is then return that address. MIPS uses this method to avoid breakpoint in delay slot. Reviewers: clayborg, jingham Subscribers: jingham, mohit.bhakkad, sagar, jaydeep, nitesh.jain, lldb-commits Differential Revision: http://http://reviews.llvm.org/D12184 llvm-svn: 246015
2015-08-26 14:04:54 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
bool PseudoInstruction::HasDelaySlot() {
// This is NOT a valid question for a pseudo instruction.
return false;
Add the infrastructure to test instruction emulations automatically. The idea is that the instruction to be emulated is actually executed on the hardware to be emulated, with the before and after state of the hardware being captured and 'freeze-dried' into .dat files. The emulation testing code then loads the before & after state from the .dat file, emulates the instruction using the before state, and compares the resulting state to the 'after' state. If they match, the emulation is accurate, otherwise there is a problem. The final format of the .dat files needs a bit more work; the plan is to generalize them a bit and to convert the plain values to key-value pairs. But I wanted to get this first pass committed. This commit adds arm instruction emulation testing to the testsuite, along with many initial .dat files. It also fixes a bug in the llvm disassembler, where 32-bit thumb opcodes were getting their upper & lower 16-bits reversed. There is a new Instruction sub-class, that is intended to be loaded from a .dat file rather than read from an executable. There is also a new EmulationStateARM class, for handling the before & after states. EmulationStates for other architetures can be added later when we emulate their instructions. llvm-svn: 129832
2011-04-20 07:30:03 +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
size_t PseudoInstruction::Decode(const lldb_private::Disassembler &disassembler,
const lldb_private::DataExtractor &data,
lldb::offset_t data_offset) {
return m_opcode.GetByteSize();
}
Add the infrastructure to test instruction emulations automatically. The idea is that the instruction to be emulated is actually executed on the hardware to be emulated, with the before and after state of the hardware being captured and 'freeze-dried' into .dat files. The emulation testing code then loads the before & after state from the .dat file, emulates the instruction using the before state, and compares the resulting state to the 'after' state. If they match, the emulation is accurate, otherwise there is a problem. The final format of the .dat files needs a bit more work; the plan is to generalize them a bit and to convert the plain values to key-value pairs. But I wanted to get this first pass committed. This commit adds arm instruction emulation testing to the testsuite, along with many initial .dat files. It also fixes a bug in the llvm disassembler, where 32-bit thumb opcodes were getting their upper & lower 16-bits reversed. There is a new Instruction sub-class, that is intended to be loaded from a .dat file rather than read from an executable. There is also a new EmulationStateARM class, for handling the before & after states. EmulationStates for other architetures can be added later when we emulate their instructions. llvm-svn: 129832
2011-04-20 07:30:03 +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
void PseudoInstruction::SetOpcode(size_t opcode_size, void *opcode_data) {
if (!opcode_data)
return;
switch (opcode_size) {
case 8: {
uint8_t value8 = *((uint8_t *)opcode_data);
m_opcode.SetOpcode8(value8, eByteOrderInvalid);
break;
}
case 16: {
uint16_t value16 = *((uint16_t *)opcode_data);
m_opcode.SetOpcode16(value16, eByteOrderInvalid);
break;
}
case 32: {
uint32_t value32 = *((uint32_t *)opcode_data);
m_opcode.SetOpcode32(value32, eByteOrderInvalid);
break;
}
case 64: {
uint64_t value64 = *((uint64_t *)opcode_data);
m_opcode.SetOpcode64(value64, eByteOrderInvalid);
break;
}
default:
break;
}
Add the infrastructure to test instruction emulations automatically. The idea is that the instruction to be emulated is actually executed on the hardware to be emulated, with the before and after state of the hardware being captured and 'freeze-dried' into .dat files. The emulation testing code then loads the before & after state from the .dat file, emulates the instruction using the before state, and compares the resulting state to the 'after' state. If they match, the emulation is accurate, otherwise there is a problem. The final format of the .dat files needs a bit more work; the plan is to generalize them a bit and to convert the plain values to key-value pairs. But I wanted to get this first pass committed. This commit adds arm instruction emulation testing to the testsuite, along with many initial .dat files. It also fixes a bug in the llvm disassembler, where 32-bit thumb opcodes were getting their upper & lower 16-bits reversed. There is a new Instruction sub-class, that is intended to be loaded from a .dat file rather than read from an executable. There is also a new EmulationStateARM class, for handling the before & after states. EmulationStates for other architetures can be added later when we emulate their instructions. llvm-svn: 129832
2011-04-20 07:30:03 +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
void PseudoInstruction::SetDescription(const char *description) {
if (description && strlen(description) > 0)
m_description = description;
Add the infrastructure to test instruction emulations automatically. The idea is that the instruction to be emulated is actually executed on the hardware to be emulated, with the before and after state of the hardware being captured and 'freeze-dried' into .dat files. The emulation testing code then loads the before & after state from the .dat file, emulates the instruction using the before state, and compares the resulting state to the 'after' state. If they match, the emulation is accurate, otherwise there is a problem. The final format of the .dat files needs a bit more work; the plan is to generalize them a bit and to convert the plain values to key-value pairs. But I wanted to get this first pass committed. This commit adds arm instruction emulation testing to the testsuite, along with many initial .dat files. It also fixes a bug in the llvm disassembler, where 32-bit thumb opcodes were getting their upper & lower 16-bits reversed. There is a new Instruction sub-class, that is intended to be loaded from a .dat file rather than read from an executable. There is also a new EmulationStateARM class, for handling the before & after states. EmulationStates for other architetures can be added later when we emulate their instructions. llvm-svn: 129832
2011-04-20 07:30:03 +08:00
}
Cleaned up some of the "frame diagnose" code to use Operands as currency. Also added some utility functions around Operands to make code easier and more compact to write. llvm-svn: 281398
2016-09-14 05:18:27 +08:00
Instruction::Operand Instruction::Operand::BuildRegister(ConstString &r) {
Operand ret;
ret.m_type = Type::Register;
ret.m_register = r;
return ret;
}
Instruction::Operand Instruction::Operand::BuildImmediate(lldb::addr_t imm,
bool neg) {
Operand ret;
ret.m_type = Type::Immediate;
ret.m_immediate = imm;
ret.m_negative = neg;
return ret;
}
Instruction::Operand Instruction::Operand::BuildImmediate(int64_t imm) {
Operand ret;
ret.m_type = Type::Immediate;
if (imm < 0) {
ret.m_immediate = -imm;
ret.m_negative = true;
} else {
ret.m_immediate = imm;
ret.m_negative = false;
}
return ret;
}
Instruction::Operand
Instruction::Operand::BuildDereference(const Operand &ref) {
Operand ret;
ret.m_type = Type::Dereference;
ret.m_children = {ref};
return ret;
}
Instruction::Operand Instruction::Operand::BuildSum(const Operand &lhs,
const Operand &rhs) {
Operand ret;
ret.m_type = Type::Sum;
ret.m_children = {lhs, rhs};
return ret;
}
Instruction::Operand Instruction::Operand::BuildProduct(const Operand &lhs,
const Operand &rhs) {
Operand ret;
ret.m_type = Type::Product;
ret.m_children = {lhs, rhs};
return ret;
}
std::function<bool(const Instruction::Operand &)>
lldb_private::OperandMatchers::MatchBinaryOp(
std::function<bool(const Instruction::Operand &)> base,
std::function<bool(const Instruction::Operand &)> left,
std::function<bool(const Instruction::Operand &)> right) {
return [base, left, right](const Instruction::Operand &op) -> bool {
return (base(op) && op.m_children.size() == 2 &&
((left(op.m_children[0]) && right(op.m_children[1])) ||
(left(op.m_children[1]) && right(op.m_children[0]))));
};
}
std::function<bool(const Instruction::Operand &)>
lldb_private::OperandMatchers::MatchUnaryOp(
std::function<bool(const Instruction::Operand &)> base,
std::function<bool(const Instruction::Operand &)> child) {
return [base, child](const Instruction::Operand &op) -> bool {
return (base(op) && op.m_children.size() == 1 && child(op.m_children[0]));
};
}
std::function<bool(const Instruction::Operand &)>
lldb_private::OperandMatchers::MatchRegOp(const RegisterInfo &info) {
return [&info](const Instruction::Operand &op) {
return (op.m_type == Instruction::Operand::Type::Register &&
(op.m_register == ConstString(info.name) ||
op.m_register == ConstString(info.alt_name)));
};
}
More cleanup in `frame diagnose,` eliminating a bunch of messy cases. llvm-svn: 281545
2016-09-15 05:54:28 +08:00
std::function<bool(const Instruction::Operand &)>
lldb_private::OperandMatchers::FetchRegOp(ConstString &reg) {
return [&reg](const Instruction::Operand &op) {
if (op.m_type != Instruction::Operand::Type::Register) {
return false;
}
reg = op.m_register;
return true;
};
}
Cleaned up some of the "frame diagnose" code to use Operands as currency. Also added some utility functions around Operands to make code easier and more compact to write. llvm-svn: 281398
2016-09-14 05:18:27 +08:00
std::function<bool(const Instruction::Operand &)>
lldb_private::OperandMatchers::MatchImmOp(int64_t imm) {
return [imm](const Instruction::Operand &op) {
return (op.m_type == Instruction::Operand::Type::Immediate &&
((op.m_negative && op.m_immediate == (uint64_t)-imm) ||
(!op.m_negative && op.m_immediate == (uint64_t)imm)));
};
}
std::function<bool(const Instruction::Operand &)>
lldb_private::OperandMatchers::FetchImmOp(int64_t &imm) {
return [&imm](const Instruction::Operand &op) {
if (op.m_type != Instruction::Operand::Type::Immediate) {
return false;
}
if (op.m_negative) {
imm = -((int64_t)op.m_immediate);
} else {
imm = ((int64_t)op.m_immediate);
}
return true;
};
}
std::function<bool(const Instruction::Operand &)>
lldb_private::OperandMatchers::MatchOpType(Instruction::Operand::Type type) {
return [type](const Instruction::Operand &op) { return op.m_type == type; };
}