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"
|
|
|
|
|
|
2017-04-07 05:28:29 +08:00
|
|
|
#include "lldb/Core/AddressRange.h" // for AddressRange
|
2010-06-09 00:52:24 +08:00
|
|
|
#include "lldb/Core/Debugger.h"
|
2011-04-06 02:46:00 +08:00
|
|
|
#include "lldb/Core/EmulateInstruction.h"
|
2017-04-07 05:28:29 +08:00
|
|
|
#include "lldb/Core/Mangled.h" // for Mangled, Mangled...
|
2010-06-09 00:52:24 +08:00
|
|
|
#include "lldb/Core/Module.h"
|
2017-04-07 05:28:29 +08:00
|
|
|
#include "lldb/Core/ModuleList.h" // for ModuleList
|
2010-06-09 00:52:24 +08:00
|
|
|
#include "lldb/Core/PluginManager.h"
|
2017-04-07 05:28:29 +08:00
|
|
|
#include "lldb/Core/SourceManager.h" // for SourceManager
|
2016-03-23 01:58:09 +08:00
|
|
|
#include "lldb/Host/FileSystem.h"
|
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"
|
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"
|
2017-04-07 05:28:29 +08:00
|
|
|
#include "lldb/Symbol/Symbol.h" // for Symbol
|
|
|
|
|
#include "lldb/Symbol/SymbolContext.h" // for SymbolContext
|
2010-06-09 00:52:24 +08:00
|
|
|
#include "lldb/Target/ExecutionContext.h"
|
2013-12-06 09:12:00 +08:00
|
|
|
#include "lldb/Target/SectionLoadList.h"
|
2013-11-04 17:33:30 +08:00
|
|
|
#include "lldb/Target/StackFrame.h"
|
2010-06-09 00:52:24 +08:00
|
|
|
#include "lldb/Target/Target.h"
|
2017-04-07 05:28:29 +08:00
|
|
|
#include "lldb/Target/Thread.h" // for Thread
|
2017-03-04 09:30:05 +08:00
|
|
|
#include "lldb/Utility/DataBufferHeap.h"
|
|
|
|
|
#include "lldb/Utility/DataExtractor.h"
|
2017-02-03 05:39:50 +08:00
|
|
|
#include "lldb/Utility/RegularExpression.h"
|
2017-05-12 12:51:55 +08:00
|
|
|
#include "lldb/Utility/Status.h"
|
2017-06-29 22:32:17 +08:00
|
|
|
#include "lldb/Utility/Stream.h" // for Stream
|
|
|
|
|
#include "lldb/Utility/StreamString.h" // for StreamString
|
|
|
|
|
#include "lldb/Utility/Timer.h"
|
2017-04-07 05:28:29 +08:00
|
|
|
#include "lldb/lldb-private-enumerations.h" // for InstructionType:...
|
|
|
|
|
#include "lldb/lldb-private-interfaces.h" // for DisassemblerCrea...
|
|
|
|
|
#include "lldb/lldb-private-types.h" // for RegisterInfo
|
|
|
|
|
#include "llvm/ADT/Triple.h" // for Triple, Triple::...
|
|
|
|
|
#include "llvm/Support/Compiler.h" // for LLVM_PRETTY_FUNC...
|
|
|
|
|
|
|
|
|
|
#include <cstdint> // for uint32_t, UINT32...
|
|
|
|
|
#include <cstring>
|
|
|
|
|
#include <utility> // for pair
|
|
|
|
|
|
|
|
|
|
#include <assert.h> // for assert
|
2010-06-09 00:52:24 +08:00
|
|
|
|
|
|
|
|
#define DEFAULT_DISASM_BYTE_SIZE 32
|
|
|
|
|
|
|
|
|
|
using namespace lldb;
|
|
|
|
|
using namespace lldb_private;
|
|
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
DisassemblerSP Disassembler::FindPlugin(const ArchSpec &arch,
|
|
|
|
|
const char *flavor,
|
|
|
|
|
const char *plugin_name) {
|
2017-05-15 21:02:37 +08:00
|
|
|
static Timer::Category func_cat(LLVM_PRETTY_FUNCTION);
|
|
|
|
|
Timer scoped_timer(func_cat,
|
2016-09-07 04:57:50 +08:00
|
|
|
"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;
|
2011-03-26 02:03:16 +08:00
|
|
|
}
|
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;
|
2010-06-09 00:52:24 +08:00
|
|
|
}
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
|
|
|
|
return DisassemblerSP();
|
2010-06-09 00:52:24 +08:00
|
|
|
}
|
|
|
|
|
|
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
|
2018-05-01 00:49:04 +08:00
|
|
|
// settings. But since we know that for now we only support flavors on x86
|
|
|
|
|
// & x86_64,
|
2016-09-07 04:57:50 +08:00
|
|
|
if (arch.GetTriple().getArch() == llvm::Triple::x86 ||
|
|
|
|
|
arch.GetTriple().getArch() == llvm::Triple::x86_64)
|
|
|
|
|
flavor = target_sp->GetDisassemblyFlavor();
|
|
|
|
|
}
|
|
|
|
|
return FindPlugin(arch, flavor, plugin_name);
|
2013-03-02 08:26:47 +08:00
|
|
|
}
|
|
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
static void ResolveAddress(const ExecutionContext &exe_ctx, const Address &addr,
|
|
|
|
|
Address &resolved_addr) {
|
|
|
|
|
if (!addr.IsSectionOffset()) {
|
2018-05-01 00:49:04 +08:00
|
|
|
// If we weren't passed in a section offset address range, try and resolve
|
|
|
|
|
// it to something
|
2016-09-07 04:57:50 +08:00
|
|
|
Target *target = exe_ctx.GetTargetPtr();
|
|
|
|
|
if (target) {
|
2018-06-22 20:24:57 +08:00
|
|
|
bool is_resolved =
|
|
|
|
|
target->GetSectionLoadList().IsEmpty() ?
|
|
|
|
|
target->GetImages().ResolveFileAddress(addr.GetOffset(),
|
|
|
|
|
resolved_addr) :
|
|
|
|
|
target->GetSectionLoadList().ResolveLoadAddress(addr.GetOffset(),
|
|
|
|
|
resolved_addr);
|
|
|
|
|
|
2018-05-01 00:49:04 +08:00
|
|
|
// We weren't able to resolve the address, just treat it as a raw address
|
2018-06-22 20:24:57 +08:00
|
|
|
if (is_resolved && resolved_addr.IsValid())
|
2016-09-07 04:57:50 +08:00
|
|
|
return;
|
2010-07-01 07:03:03 +08:00
|
|
|
}
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
|
|
|
|
resolved_addr = addr;
|
2010-07-01 07:03:03 +08:00
|
|
|
}
|
|
|
|
|
|
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,
|
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)) {
|
2016-09-07 04:57:50 +08:00
|
|
|
++success_count;
|
|
|
|
|
strm.EOL();
|
|
|
|
|
}
|
2011-01-27 14:44:37 +08:00
|
|
|
}
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
|
|
|
|
return success_count;
|
2010-07-01 07:03:03 +08:00
|
|
|
}
|
|
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
bool Disassembler::Disassemble(Debugger &debugger, const ArchSpec &arch,
|
|
|
|
|
const char *plugin_name, const char *flavor,
|
2016-03-03 08:51:40 +08:00
|
|
|
const ExecutionContext &exe_ctx,
|
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,
|
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);
|
2010-10-06 11:09:58 +08:00
|
|
|
}
|
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);
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
|
|
|
|
return false;
|
2010-10-06 11:09:58 +08:00
|
|
|
}
|
|
|
|
|
|
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();
|
2011-12-15 07:49:37 +08:00
|
|
|
}
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
|
|
|
|
return disasm_sp;
|
2011-12-15 07:49:37 +08:00
|
|
|
}
|
|
|
|
|
|
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);
|
2011-03-22 09:48:42 +08:00
|
|
|
}
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return disasm_sp;
|
2011-03-22 09:48:42 +08:00
|
|
|
}
|
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,
|
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);
|
2011-03-22 09:48:42 +08:00
|
|
|
}
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
|
|
|
|
return false;
|
2011-03-22 09:48:42 +08:00
|
|
|
}
|
2016-06-08 07:19:00 +08:00
|
|
|
|
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,
|
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);
|
2015-02-14 07:24:21 +08:00
|
|
|
}
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
|
|
|
|
return false;
|
|
|
|
|
}
|
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) {
|
2017-05-12 12:51:55 +08:00
|
|
|
Status error;
|
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
|
|
|
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, ®ex_match)) {
|
|
|
|
|
// skip this source line
|
|
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
// don't skip this source line
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
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,
|
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;
|
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;
|
|
|
|
|
}
|
|
|
|
|
|
2018-05-01 00:49:04 +08:00
|
|
|
// 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
|
2018-05-01 00:49:04 +08:00
|
|
|
// mode. Calculate the source line for each assembly instruction (eliding
|
|
|
|
|
// inlined functions which the user wants to skip).
|
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
|
|
|
|
|
|
|
|
std::map<FileSpec, std::set<uint32_t>> source_lines_seen;
|
|
|
|
|
Symbol *previous_symbol = nullptr;
|
|
|
|
|
|
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) {
|
2018-10-26 04:45:19 +08:00
|
|
|
const SymbolContextItem resolve_mask = eSymbolContextFunction |
|
|
|
|
|
eSymbolContextSymbol |
|
|
|
|
|
eSymbolContextLineEntry;
|
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);
|
|
|
|
|
}
|
|
|
|
|
}
|
2015-02-14 07:24:21 +08:00
|
|
|
}
|
2016-09-07 04:57:50 +08:00
|
|
|
sc.Clear(false);
|
|
|
|
|
}
|
2015-02-14 07:24:21 +08:00
|
|
|
}
|
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;
|
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
|
|
|
|
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;
|
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
|
2018-05-01 00:49:04 +08:00
|
|
|
// source lines from the function declaration until the first line
|
|
|
|
|
// table entry - typically the opening curly brace of the function.
|
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 (previous_symbol != sc.symbol) {
|
2018-05-01 00:49:04 +08:00
|
|
|
// 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.
|
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 (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) {
|
2018-05-01 00:49:04 +08:00
|
|
|
// Add all the lines between the function declaration and
|
|
|
|
|
// the first non-prologue source line to the list of lines
|
|
|
|
|
// to print.
|
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
|
|
|
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);
|
|
|
|
|
}
|
2018-05-01 00:49:04 +08:00
|
|
|
// Mark the last line as the "current" one. Usually this
|
|
|
|
|
// is the open curly brace.
|
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)
|
|
|
|
|
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);
|
|
|
|
|
}
|
|
|
|
|
|
2018-05-01 00:49:04 +08:00
|
|
|
// If we've left a previous source line's address range, print a
|
|
|
|
|
// new source 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
|
|
|
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
|
2018-05-01 00:49:04 +08:00
|
|
|
// the same line being printed twice in a row for a
|
|
|
|
|
// contiguous block of assembly 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
|
|
|
if (this_line != previous_line) {
|
|
|
|
|
|
|
|
|
|
std::vector<uint32_t> previous_lines;
|
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;
|
|
|
|
|
|
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;
|
2011-03-22 09:48:42 +08:00
|
|
|
}
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
2010-06-09 00:52:24 +08:00
|
|
|
}
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
|
|
|
|
} else {
|
|
|
|
|
sc.Clear(true);
|
2010-06-09 00:52:24 +08:00
|
|
|
}
|
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();
|
|
|
|
|
}
|
|
|
|
|
|
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;
|
2010-06-09 00:52:24 +08:00
|
|
|
}
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
2010-06-09 00:52:24 +08:00
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
return true;
|
|
|
|
|
}
|
2010-07-01 07:03:03 +08:00
|
|
|
|
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,
|
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();
|
2010-07-01 07:03:03 +08:00
|
|
|
}
|
|
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
if (range.GetBaseAddress().IsValid() && range.GetByteSize() == 0)
|
|
|
|
|
range.SetByteSize(DEFAULT_DISASM_BYTE_SIZE);
|
|
|
|
|
}
|
2010-07-01 07:03:03 +08:00
|
|
|
|
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);
|
2010-06-09 00:52:24 +08:00
|
|
|
}
|
|
|
|
|
|
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) {}
|
|
|
|
|
|
2016-03-03 08:51:40 +08:00
|
|
|
Instruction::~Instruction() = default;
|
2010-06-09 00:52:24 +08:00
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
AddressClass Instruction::GetAddressClass() {
|
2018-06-26 21:06:54 +08:00
|
|
|
if (m_address_class == AddressClass::eInvalid)
|
2016-09-07 04:57:50 +08:00
|
|
|
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
|
|
|
}
|
2010-06-09 00:52:24 +08:00
|
|
|
|
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) {
|
2018-05-01 00:49:04 +08:00
|
|
|
// 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
|
2016-09-07 04:57:50 +08:00
|
|
|
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 {
|
2018-05-01 00:49:04 +08:00
|
|
|
// Else, we have ARM or MIPS which can show up to a uint32_t 0x00000000
|
|
|
|
|
// (10 spaces) plus two for padding...
|
2016-09-07 04:57:50 +08:00
|
|
|
if (max_opcode_byte_size > 0)
|
|
|
|
|
m_opcode.Dump(&ss, max_opcode_byte_size * 3 + 1);
|
|
|
|
|
else
|
|
|
|
|
m_opcode.Dump(&ss, 12);
|
2012-05-10 10:52:23 +08:00
|
|
|
}
|
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;
|
|
|
|
|
}
|
|
|
|
|
|
2016-11-03 04:34:10 +08:00
|
|
|
ss.PutCString(m_opcode_name);
|
2016-09-07 04:57:50 +08:00
|
|
|
ss.FillLastLineToColumn(opcode_pos + opcode_column_width, ' ');
|
2016-11-03 04:34:10 +08:00
|
|
|
ss.PutCString(m_mnemonics);
|
2016-09-07 04:57:50 +08:00
|
|
|
|
|
|
|
|
if (!m_comment.empty()) {
|
|
|
|
|
ss.FillLastLineToColumn(
|
|
|
|
|
opcode_pos + opcode_column_width + operand_column_width, ' ');
|
|
|
|
|
ss.PutCString(" ; ");
|
2016-11-03 04:34:10 +08:00
|
|
|
ss.PutCString(m_comment);
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
2016-11-17 05:15:24 +08:00
|
|
|
s->PutCString(ss.GetString());
|
2012-05-10 10:52:23 +08:00
|
|
|
}
|
|
|
|
|
|
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);
|
|
|
|
|
}
|
2011-04-06 07:22:54 +08:00
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
return false;
|
2011-04-06 07:22:54 +08:00
|
|
|
}
|
|
|
|
|
|
2017-05-04 19:34:42 +08:00
|
|
|
bool Instruction::CanSetBreakpoint () {
|
|
|
|
|
return !HasDelaySlot();
|
|
|
|
|
}
|
|
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
bool Instruction::HasDelaySlot() {
|
|
|
|
|
// Default is false.
|
|
|
|
|
return false;
|
2015-08-26 14:04:54 +08:00
|
|
|
}
|
|
|
|
|
|
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];
|
2011-04-22 13:08:45 +08:00
|
|
|
|
2017-04-07 05:28:29 +08:00
|
|
|
auto option_value_sp = std::make_shared<OptionValueArray>(1u << data_type);
|
2011-04-22 13:08:45 +08:00
|
|
|
|
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;
|
|
|
|
|
}
|
2011-04-22 13:08:45 +08:00
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
std::string line(buffer);
|
2011-04-22 13:08:45 +08:00
|
|
|
|
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);
|
2011-04-22 13:08:45 +08:00
|
|
|
}
|
|
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
if ((line.size() == 1) && line[0] == ']') {
|
|
|
|
|
done = true;
|
|
|
|
|
line.clear();
|
|
|
|
|
}
|
2011-04-22 13:08:45 +08:00
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
if (!line.empty()) {
|
|
|
|
|
std::string value;
|
2016-09-22 00:01:28 +08:00
|
|
|
static RegularExpression g_reg_exp(
|
|
|
|
|
llvm::StringRef("^[ \t]*([^ \t]+)[ \t]*$"));
|
2016-09-07 04:57:50 +08:00
|
|
|
RegularExpression::Match regex_match(1);
|
2016-09-22 00:01:28 +08:00
|
|
|
bool reg_exp_success = g_reg_exp.Execute(line, ®ex_match);
|
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:
|
2017-04-07 05:28:29 +08:00
|
|
|
data_value_sp = std::make_shared<OptionValueUInt64>(0, 0);
|
2016-09-07 04:57:50 +08:00
|
|
|
data_value_sp->SetValueFromString(value);
|
|
|
|
|
break;
|
|
|
|
|
// Other types can be added later as needed.
|
|
|
|
|
default:
|
2017-04-07 05:28:29 +08:00
|
|
|
data_value_sp = std::make_shared<OptionValueString>(value.c_str(), "");
|
2016-09-07 04:57:50 +08:00
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
option_value_sp->GetAsArray()->InsertValue(idx, data_value_sp);
|
|
|
|
|
++idx;
|
2011-04-22 13:08:45 +08:00
|
|
|
}
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
2011-04-22 13:08:45 +08:00
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
return option_value_sp;
|
|
|
|
|
}
|
2011-04-20 07:30:03 +08:00
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
OptionValueSP Instruction::ReadDictionary(FILE *in_file, Stream *out_stream) {
|
|
|
|
|
bool done = false;
|
|
|
|
|
char buffer[1024];
|
|
|
|
|
|
2017-04-07 05:28:29 +08:00
|
|
|
auto option_value_sp = std::make_shared<OptionValueDictionary>();
|
2016-09-07 04:57:50 +08:00
|
|
|
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;
|
2011-04-20 07:30:03 +08:00
|
|
|
}
|
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);
|
2011-04-20 07:30:03 +08:00
|
|
|
}
|
|
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
if ((line.size() == 1) && (line[0] == '}')) {
|
|
|
|
|
done = true;
|
|
|
|
|
line.clear();
|
2011-04-20 07:30:03 +08:00
|
|
|
}
|
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()) {
|
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]*$"));
|
2016-09-07 04:57:50 +08:00
|
|
|
RegularExpression::Match regex_match(2);
|
|
|
|
|
|
2016-09-22 00:01:28 +08:00
|
|
|
bool reg_exp_success = g_reg_exp.Execute(line, ®ex_match);
|
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;
|
|
|
|
|
}
|
2018-05-01 00:49:04 +08:00
|
|
|
// We've used the data_type to read an array; re-set the type to
|
|
|
|
|
// Invalid
|
2016-09-07 04:57:50 +08:00
|
|
|
data_type = OptionValue::eTypeInvalid;
|
|
|
|
|
} else if ((value[0] == '0') && (value[1] == 'x')) {
|
2017-04-07 05:28:29 +08:00
|
|
|
value_sp = std::make_shared<OptionValueUInt64>(0, 0);
|
2016-09-07 04:57:50 +08:00
|
|
|
value_sp->SetValueFromString(value);
|
|
|
|
|
} else {
|
|
|
|
|
size_t len = value.size();
|
|
|
|
|
if ((value[0] == '"') && (value[len - 1] == '"'))
|
|
|
|
|
value = value.substr(1, len - 2);
|
2017-04-07 05:28:29 +08:00
|
|
|
value_sp = std::make_shared<OptionValueString>(value.c_str(), "");
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
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);
|
2011-04-22 13:08:45 +08:00
|
|
|
}
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
2011-04-22 13:08:45 +08:00
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
return option_value_sp;
|
|
|
|
|
}
|
2011-04-22 13:08:45 +08:00
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
bool Instruction::TestEmulation(Stream *out_stream, const char *file_name) {
|
|
|
|
|
if (!out_stream)
|
|
|
|
|
return false;
|
2011-04-22 13:08:45 +08:00
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
if (!file_name) {
|
|
|
|
|
out_stream->Printf("Instruction::TestEmulation: Missing file_name.");
|
|
|
|
|
return false;
|
|
|
|
|
}
|
2018-11-01 05:49:27 +08:00
|
|
|
FILE *test_file = FileSystem::Instance().Fopen(file_name, "r");
|
2016-09-07 04:57:50 +08:00
|
|
|
if (!test_file) {
|
|
|
|
|
out_stream->Printf(
|
|
|
|
|
"Instruction::TestEmulation: Attempt to open test file failed.");
|
|
|
|
|
return false;
|
|
|
|
|
}
|
2011-04-22 13:08:45 +08:00
|
|
|
|
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;
|
|
|
|
|
}
|
2011-04-22 13:08:45 +08:00
|
|
|
|
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;
|
|
|
|
|
}
|
2011-04-22 13:08:45 +08:00
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
// Read all the test information from the test file into an
|
|
|
|
|
// OptionValueDictionary.
|
2016-03-03 08:51:40 +08:00
|
|
|
|
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;
|
|
|
|
|
}
|
2011-04-20 07:30:03 +08:00
|
|
|
|
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");
|
2011-04-06 07:22:54 +08:00
|
|
|
|
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");
|
2011-04-06 07:22:54 +08:00
|
|
|
return false;
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
2011-04-06 07:22:54 +08:00
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
SetDescription(value_sp->GetStringValue());
|
2012-05-10 10:52:23 +08:00
|
|
|
|
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;
|
|
|
|
|
}
|
2010-06-09 00:52:24 +08:00
|
|
|
|
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);
|
2010-06-09 00:52:24 +08:00
|
|
|
|
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;
|
2010-06-09 00:52:24 +08:00
|
|
|
}
|
|
|
|
|
|
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
|
|
|
}
|
|
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
uint32_t Instruction::GetData(DataExtractor &data) {
|
|
|
|
|
return m_opcode.GetData(data);
|
2010-06-09 00:52:24 +08:00
|
|
|
}
|
|
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
InstructionList::InstructionList() : m_instructions() {}
|
2015-02-05 06:00:53 +08:00
|
|
|
|
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
|
|
|
}
|
|
|
|
|
|
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;
|
2010-06-09 00:52:24 +08:00
|
|
|
}
|
|
|
|
|
|
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);
|
2010-06-09 00:52:24 +08:00
|
|
|
}
|
|
|
|
|
|
2012-03-09 12:10:47 +08:00
|
|
|
uint32_t
|
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;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2018-05-01 00:49:04 +08:00
|
|
|
// 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.
|
2016-09-07 04:57:50 +08:00
|
|
|
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;
|
2012-03-09 12:10:47 +08:00
|
|
|
}
|
2015-05-12 05:12:33 +08:00
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
while (i > start) {
|
|
|
|
|
--i;
|
|
|
|
|
|
2017-05-12 12:51:55 +08:00
|
|
|
Status error;
|
2016-09-07 04:57:50 +08:00
|
|
|
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;
|
2018-05-01 00:49:04 +08:00
|
|
|
// check if this is the last instruction in a packet bits 15:14 will be
|
|
|
|
|
// 11b or 00b for a duplex
|
2016-09-07 04:57:50 +08:00
|
|
|
if (((inst_bytes & 0xC000) == 0xC000) ||
|
|
|
|
|
((inst_bytes & 0xC000) == 0x0000)) {
|
|
|
|
|
// instruction after this should be the start of next packet
|
|
|
|
|
next_branch = i + 1;
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
}
|
2015-05-12 05:12:33 +08:00
|
|
|
|
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;
|
2015-05-12 05:12:33 +08:00
|
|
|
}
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
|
|
|
|
return next_branch;
|
2012-03-09 12:10:47 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
uint32_t
|
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;
|
2012-03-09 12:10:47 +08:00
|
|
|
}
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
|
|
|
|
return index;
|
2012-03-09 12:10:47 +08:00
|
|
|
}
|
2010-06-09 00:52:24 +08:00
|
|
|
|
2014-01-28 07:43:24 +08:00
|
|
|
uint32_t
|
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);
|
2014-01-28 07:43:24 +08:00
|
|
|
}
|
|
|
|
|
|
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;
|
|
|
|
|
|
2017-04-07 05:28:29 +08:00
|
|
|
auto data_sp = std::make_shared<DataBufferHeap>(byte_size, '\0');
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2017-05-12 12:51:55 +08:00
|
|
|
Status error;
|
2016-09-07 04:57:50 +08:00
|
|
|
lldb::addr_t load_addr = LLDB_INVALID_ADDRESS;
|
|
|
|
|
const size_t bytes_read = target->ReadMemory(
|
2017-04-07 05:28:29 +08:00
|
|
|
range.GetBaseAddress(), prefer_file_cache, data_sp->GetBytes(),
|
|
|
|
|
data_sp->GetByteSize(), error, &load_addr);
|
2016-09-07 04:57:50 +08:00
|
|
|
|
|
|
|
|
if (bytes_read > 0) {
|
2017-04-07 05:28:29 +08:00
|
|
|
if (bytes_read != data_sp->GetByteSize())
|
|
|
|
|
data_sp->SetByteSize(bytes_read);
|
2016-09-07 04:57:50 +08:00
|
|
|
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);
|
|
|
|
|
}
|
2010-06-09 00:52:24 +08:00
|
|
|
}
|
2016-09-07 04:57:50 +08:00
|
|
|
} else if (error_strm_ptr) {
|
|
|
|
|
error_strm_ptr->PutCString("error: invalid execution context\n");
|
|
|
|
|
}
|
|
|
|
|
return 0;
|
2010-06-09 00:52:24 +08:00
|
|
|
}
|
|
|
|
|
|
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
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
if (exe_ctx == nullptr || num_instructions == 0 || !start.IsValid())
|
|
|
|
|
return 0;
|
2011-03-22 09:48:42 +08:00
|
|
|
|
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();
|
2011-03-22 09:48:42 +08:00
|
|
|
|
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);
|
|
|
|
|
|
2017-05-12 12:51:55 +08:00
|
|
|
Status error;
|
2016-09-07 04:57:50 +08:00
|
|
|
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();
|
2011-03-22 09:48:42 +08:00
|
|
|
}
|
|
|
|
|
|
2010-06-09 00:52:24 +08:00
|
|
|
//----------------------------------------------------------------------
|
|
|
|
|
// Disassembler copy constructor
|
|
|
|
|
//----------------------------------------------------------------------
|
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)
|
2018-05-01 00:49:04 +08:00
|
|
|
// instructions, force the arch triple to be "thumbv.." instead of "armv..."
|
2016-09-07 04:57:50 +08:00
|
|
|
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");
|
2015-02-07 14:03:49 +08:00
|
|
|
}
|
2016-09-07 04:57:50 +08:00
|
|
|
m_arch.SetTriple(thumb_arch_name.c_str());
|
|
|
|
|
}
|
2010-06-09 00:52:24 +08:00
|
|
|
}
|
|
|
|
|
|
2016-03-03 08:51:40 +08:00
|
|
|
Disassembler::~Disassembler() = default;
|
2010-06-09 00:52:24 +08:00
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
InstructionList &Disassembler::GetInstructionList() {
|
|
|
|
|
return m_instruction_list;
|
2010-06-09 00:52:24 +08:00
|
|
|
}
|
|
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
const InstructionList &Disassembler::GetInstructionList() const {
|
|
|
|
|
return m_instruction_list;
|
2010-06-09 00:52:24 +08:00
|
|
|
}
|
2011-04-20 07:30:03 +08:00
|
|
|
|
|
|
|
|
//----------------------------------------------------------------------
|
|
|
|
|
// Class PseudoInstruction
|
|
|
|
|
//----------------------------------------------------------------------
|
2016-03-03 08:51:40 +08:00
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
PseudoInstruction::PseudoInstruction()
|
2018-06-26 21:06:54 +08:00
|
|
|
: Instruction(Address(), AddressClass::eUnknown), m_description() {}
|
2011-04-20 07:30:03 +08:00
|
|
|
|
2016-03-03 08:51:40 +08:00
|
|
|
PseudoInstruction::~PseudoInstruction() = default;
|
2016-09-07 04:57:50 +08:00
|
|
|
|
|
|
|
|
bool PseudoInstruction::DoesBranch() {
|
|
|
|
|
// This is NOT a valid question for a pseudo instruction.
|
|
|
|
|
return false;
|
2015-08-26 14:04:54 +08:00
|
|
|
}
|
|
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
bool PseudoInstruction::HasDelaySlot() {
|
|
|
|
|
// This is NOT a valid question for a pseudo instruction.
|
|
|
|
|
return false;
|
2011-04-20 07:30:03 +08:00
|
|
|
}
|
|
|
|
|
|
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();
|
|
|
|
|
}
|
2011-04-20 07:30:03 +08:00
|
|
|
|
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;
|
|
|
|
|
}
|
2011-04-20 07:30:03 +08:00
|
|
|
}
|
|
|
|
|
|
2016-11-18 02:08:12 +08:00
|
|
|
void PseudoInstruction::SetDescription(llvm::StringRef description) {
|
|
|
|
|
m_description = description;
|
2011-04-20 07:30:03 +08:00
|
|
|
}
|
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)));
|
|
|
|
|
};
|
|
|
|
|
}
|
|
|
|
|
|
2016-09-15 05:54:28 +08:00
|
|
|
std::function<bool(const Instruction::Operand &)>
|
|
|
|
|
lldb_private::OperandMatchers::FetchRegOp(ConstString ®) {
|
|
|
|
|
return [®](const Instruction::Operand &op) {
|
|
|
|
|
if (op.m_type != Instruction::Operand::Type::Register) {
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
reg = op.m_register;
|
|
|
|
|
return true;
|
|
|
|
|
};
|
|
|
|
|
}
|
|
|
|
|
|
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; };
|
|
|
|
|
}
|