of Stephen Wilson's idea (thanks for the input Stephen!). What I ended up
doing was:
- Got rid of ArchSpec::CPU (which was a generic CPU enumeration that mimics
the contents of llvm::Triple::ArchType). We now rely upon the llvm::Triple
to give us the machine type from llvm::Triple::ArchType.
- There is a new ArchSpec::Core definition which further qualifies the CPU
core we are dealing with into a single enumeration. If you need support for
a new Core and want to debug it in LLDB, it must be added to this list. In
the future we can allow for dynamic core registration, but for now it is
hard coded.
- The ArchSpec can now be initialized with a llvm::Triple or with a C string
that represents the triple (it can just be an arch still like "i386").
- The ArchSpec can still initialize itself with a architecture type -- mach-o
with cpu type and subtype, or ELF with e_machine + e_flags -- and this will
then get translated into the internal llvm::Triple::ArchSpec + ArchSpec::Core.
The mach-o cpu type and subtype can be accessed using the getter functions:
uint32_t
ArchSpec::GetMachOCPUType () const;
uint32_t
ArchSpec::GetMachOCPUSubType () const;
But these functions are just converting out internal llvm::Triple::ArchSpec
+ ArchSpec::Core back into mach-o. Same goes for ELF.
All code has been updated to deal with the changes.
This should abstract us until later when the llvm::TargetSpec stuff gets
finalized and we can then adopt it.
llvm-svn: 126278
now, in addition to cpu type/subtype and architecture flavor, contains:
- byte order (big endian, little endian)
- address size in bytes
- llvm::Triple for true target triple support and for more powerful plug-in
selection.
llvm-svn: 125602
lldb_private::Function objects. Previously the SymbolFileSymtab subclass
would return lldb_private::Symbol objects when it was asked to find functions.
The Module::FindFunctions (...) now take a boolean "bool include_symbols" so
that the module can track down functions and symbols, yet functions are found
by the SymbolFile plug-ins (through the SymbolVendor class), and symbols are
gotten through the ObjectFile plug-ins.
Fixed and issue where the DWARF parser might run into incomplete class member
function defintions which would make clang mad when we tried to make certain
member functions with invalid number of parameters (such as an operator=
operator that had no parameters). Now we just avoid and don't complete these
incomplete functions.
llvm-svn: 124359
cache even when a valid process exists. Previously, Target::ReadMemory would
read from the process if there was a valid one and then fallback to the
object file cache.
llvm-svn: 122989
Added a "bool show_fullpaths" to many more objects that were
previously always dumping full paths.
Fixed a few places where the DWARF was not indexed when we
we needed it to be when making queries. Also fixed an issue
where the DWARF in .o files wasn't searching all .o files
for the types.
Fixed an issue with the output from "image lookup --type <TYPENAME>"
where the name and byte size might not be resolved and might not
display. We now call the accessors so we end up seeing all of the
type info.
llvm-svn: 113951
might dump file paths that allows the dumping of full paths or just the
basenames. Switched the stack frame dumping code to use just the basenames for
the files instead of the full path.
Modified the StackID class to no rely on needing the start PC for the current
function/symbol since we can use the SymbolContextScope to uniquely identify
that, unless there is no symbol context scope. In that case we can rely upon
the current PC value. This saves the StackID from having to calculate the
start PC when the StackFrame::GetStackID() accessor is called.
Also improved the StackID less than operator to correctly handle inlined stack
frames in the same stack.
llvm-svn: 112867
complex inlined examples.
StackFrame classes don't have a "GetPC" anymore, they have "GetFrameCodeAddress()".
This is because inlined frames will have a PC value that is the same as the
concrete frame that owns the inlined frame, yet the code locations for the
frame can be different. We also need to be able to get the real PC value for
a given frame so that variables evaluate correctly. To get the actual PC
value for a frame you can use:
addr_t pc = frame->GetRegisterContext()->GetPC();
Some issues with the StackFrame stomping on its own symbol context were
resolved which were causing the information to change for a frame when the
stack ID was calculated. Also the StackFrame will now correctly store the
symbol context resolve flags for any extra bits of information that were
looked up (if you ask for a block only and you find one, you will alwasy have
the compile unit and function).
llvm-svn: 111964
which is now on by default. Frames are gotten from the unwinder as concrete
frames, then if inline frames are to be shown, extra information to track
and reconstruct these frames is cached with each Thread and exanded as needed.
I added an inline height as part of the lldb_private::StackID class, the class
that helps us uniquely identify stack frames. This allows for two frames to
shared the same call frame address, yet differ only in inline height.
Fixed setting breakpoint by address to not require addresses to resolve.
A quick example:
% cat main.cpp
% ./build/Debug/lldb test/stl/a.out
Current executable set to 'test/stl/a.out' (x86_64).
(lldb) breakpoint set --address 0x0000000100000d31
Breakpoint created: 1: address = 0x0000000100000d31, locations = 1
(lldb) r
Launching 'a.out' (x86_64)
(lldb) Process 38031 Stopped
* thread #1: tid = 0x2e03, pc = 0x0000000100000d31, where = a.out`main [inlined] std::string::_M_data() const at /usr/include/c++/4.2.1/bits/basic_string.h:280, stop reason = breakpoint 1.1, queue = com.apple.main-thread
277
278 _CharT*
279 _M_data() const
280 -> { return _M_dataplus._M_p; }
281
282 _CharT*
283 _M_data(_CharT* __p)
(lldb) bt
thread #1: tid = 0x2e03, stop reason = breakpoint 1.1, queue = com.apple.main-thread
frame #0: pc = 0x0000000100000d31, where = a.out`main [inlined] std::string::_M_data() const at /usr/include/c++/4.2.1/bits/basic_string.h:280
frame #1: pc = 0x0000000100000d31, where = a.out`main [inlined] std::string::_M_rep() const at /usr/include/c++/4.2.1/bits/basic_string.h:288
frame #2: pc = 0x0000000100000d31, where = a.out`main [inlined] std::string::size() const at /usr/include/c++/4.2.1/bits/basic_string.h:606
frame #3: pc = 0x0000000100000d31, where = a.out`main [inlined] operator<< <char, std::char_traits<char>, std::allocator<char> > at /usr/include/c++/4.2.1/bits/basic_string.h:2414
frame #4: pc = 0x0000000100000d31, where = a.out`main + 33 at /Volumes/work/gclayton/Documents/src/lldb/test/stl/main.cpp:14
frame #5: pc = 0x0000000100000d08, where = a.out`start + 52
Each inline frame contains only the variables that they contain and each inlined
stack frame is treated as a single entity.
llvm-svn: 111877
it returns a list of functions as a SymbolContextList.
Rewrote the clients of SymbolContext to use this
SymbolContextList.
Rewrote some of the providers of the data to SymbolContext
to make them respect preferences as to whether the list
should be cleared first; propagated that change out.
ClangExpressionDeclMap and ClangASTSource use this new
function list to properly generate function definitions -
even for functions that don't have a prototype in the
debug information.
llvm-svn: 109476
Added the ability to read memory from the target's object files when we aren't
running, so disassembling works before you run!
Cleaned up the API to lldb_private::Target::ReadMemory().
Cleaned up the API to the Disassembler to use actual "lldb_private::Address"
objects instead of just an "addr_t". This is nice because the Address objects
when resolved carry along their section and module which can get us the
object file. This allows Target::ReadMemory to be used when we are not
running.
Added a new lldb_private::Address dump style: DumpStyleDetailedSymbolContext
This will show a full breakdown of what an address points to. To see some
sample output, execute a "image lookup --address <addr>".
Fixed SymbolContext::DumpStopContext(...) to not require a live process in
order to be able to print function and symbol offsets.
llvm-svn: 107350
to the debugger from GUI windows. Previously there was one global debugger
instance that could be accessed that had its own command interpreter and
current state (current target/process/thread/frame). When a GUI debugger
was attached, if it opened more than one window that each had a console
window, there were issues where the last one to setup the global debugger
object won and got control of the debugger.
To avoid this we now create instances of the lldb_private::Debugger that each
has its own state:
- target list for targets the debugger instance owns
- current process/thread/frame
- its own command interpreter
- its own input, output and error file handles to avoid conflicts
- its own input reader stack
So now clients should call:
SBDebugger::Initialize(); // (static function)
SBDebugger debugger (SBDebugger::Create());
// Use which ever file handles you wish
debugger.SetErrorFileHandle (stderr, false);
debugger.SetOutputFileHandle (stdout, false);
debugger.SetInputFileHandle (stdin, true);
// main loop
SBDebugger::Terminate(); // (static function)
SBDebugger::Initialize() and SBDebugger::Terminate() are ref counted to
ensure nothing gets destroyed too early when multiple clients might be
attached.
Cleaned up the command interpreter and the CommandObject and all subclasses
to take more appropriate arguments.
llvm-svn: 106615
Greg Clayton