summaryrefslogtreecommitdiffstats
path: root/lldb/source/Plugins/Disassembler
Commit message (Collapse)AuthorAgeFilesLines
...
* Add the infrastructure to test instruction emulations automatically.Caroline Tice2011-04-191-1/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The idea is that the instruction to be emulated is actually executed on the hardware to be emulated, with the before and after state of the hardware being captured and 'freeze-dried' into .dat files. The emulation testing code then loads the before & after state from the .dat file, emulates the instruction using the before state, and compares the resulting state to the 'after' state. If they match, the emulation is accurate, otherwise there is a problem. The final format of the .dat files needs a bit more work; the plan is to generalize them a bit and to convert the plain values to key-value pairs. But I wanted to get this first pass committed. This commit adds arm instruction emulation testing to the testsuite, along with many initial .dat files. It also fixes a bug in the llvm disassembler, where 32-bit thumb opcodes were getting their upper & lower 16-bits reversed. There is a new Instruction sub-class, that is intended to be loaded from a .dat file rather than read from an executable. There is also a new EmulationStateARM class, for handling the before & after states. EmulationStates for other architetures can be added later when we emulate their instructions. llvm-svn: 129832
* Centralized a lot of the status information for processes,Greg Clayton2011-04-182-4/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | threads, and stack frame down in the lldb_private::Process, lldb_private::Thread, lldb_private::StackFrameList and the lldb_private::StackFrame classes. We had some command line commands that had duplicate versions of the process status output ("thread list" and "process status" for example). Removed the "file" command and placed it where it should have been: "target create". Made an alias for "file" to "target create" so we stay compatible with GDB commands. We can now have multple usable targets in lldb at the same time. This is nice for comparing two runs of a program or debugging more than one binary at the same time. The new command is "target select <target-idx>" and also to see a list of the current targets you can use the new "target list" command. The flow in a debug session can be: (lldb) target create /path/to/exe/a.out (lldb) breakpoint set --name main (lldb) run ... hit breakpoint (lldb) target create /bin/ls (lldb) run /tmp Process 36001 exited with status = 0 (0x00000000) (lldb) target list Current targets: target #0: /tmp/args/a.out ( arch=x86_64-apple-darwin, platform=localhost, pid=35999, state=stopped ) * target #1: /bin/ls ( arch=x86_64-apple-darwin, platform=localhost, pid=36001, state=exited ) (lldb) target select 0 Current targets: * target #0: /tmp/args/a.out ( arch=x86_64-apple-darwin, platform=localhost, pid=35999, state=stopped ) target #1: /bin/ls ( arch=x86_64-apple-darwin, platform=localhost, pid=36001, state=exited ) (lldb) bt * thread #1: tid = 0x2d03, 0x0000000100000b9a a.out`main + 42 at main.c:16, stop reason = breakpoint 1.1 frame #0: 0x0000000100000b9a a.out`main + 42 at main.c:16 frame #1: 0x0000000100000b64 a.out`start + 52 Above we created a target for "a.out" and ran and hit a breakpoint at "main". Then we created a new target for /bin/ls and ran it. Then we listed the targest and selected our original "a.out" program, so we showed two concurent debug sessions going on at the same time. llvm-svn: 129695
* Modified the ArchSpec to take an optional "Platform *" when setting the triple.Greg Clayton2011-04-071-14/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | This allows you to have a platform selected, then specify a triple using "i386" and have the remaining triple items (vendor, os, and environment) set automatically. Many interpreter commands take the "--arch" option to specify an architecture triple, so now the command options needed to be able to get to the current platform, so the Options class now take a reference to the interpreter on construction. Modified the build LLVM building in the Xcode project to use the new Xcode project level user definitions: LLVM_BUILD_DIR - a path to the llvm build directory LLVM_SOURCE_DIR - a path to the llvm sources for the llvm that will be used to build lldb LLVM_CONFIGURATION - the configuration that lldb is built for (Release, Release+Asserts, Debug, Debug+Asserts). I also changed the LLVM build to not check if "lldb/llvm" is a symlink and then assume it is a real llvm build directory versus the unzipped llvm.zip package, so now you can actually have a "lldb/llvm" directory in your lldb sources. llvm-svn: 129112
* Add Emulate and DumpEmulation to Instruction class.Caroline Tice2011-04-052-40/+41
| | | | | | | | Move InstructionLLVM out of DisassemblerLLVM class. Add instruction emulation function calls to SBInstruction and SBInstructionList APIs. llvm-svn: 128956
* Add the rest of the mechanisms to make ARM instruction emulation ↵Caroline Tice2011-04-051-1/+1
| | | | | | usable/possible. llvm-svn: 128907
* Added the ability to get the min and max instruction byte size for Greg Clayton2011-03-262-18/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Cleaned up the Disassembler code a bit more. You can now request a disassemblerGreg Clayton2011-03-252-36/+32
| | | | | | | | | | | | | plugin by name on the command line for when there is more than one disassembler plugin. Taught the Opcode class to dump itself so that "disassembler -b" will dump the bytes correctly for each opcode type. Modified all places that were passing the opcode bytes buffer in so that the bytes could be displayed to just pass in a bool that indicates if we should dump the opcode bytes since the opcode now lives inside llvm_private::Instruction. llvm-svn: 128290
* Made the lldb_private::Opcode struct into a real boy... I mean class.Greg Clayton2011-03-242-9/+42
| | | | | | | | | | | Modified the Disassembler::Instruction base class to contain an Opcode instance so that we can know the bytes for an instruction without needing to keep the data around. Modified the DisassemblerLLVM's instruction class to correctly extract the opcode bytes if all goes well. llvm-svn: 128248
* Add the ability to disassemble "n" instructions from the current PC, or the ↵Jim Ingham2011-03-222-3/+6
| | | | | | | | first "n" instructions in a function. Also added a "-p" flag that disassembles from the current pc. llvm-svn: 128063
* Added more platform support. There are now some new commands:Greg Clayton2011-03-192-5/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | platform status -- gets status information for the selected platform platform create <platform-name> -- creates a new instance of a remote platform platform list -- list all available platforms platform select -- select a platform instance as the current platform (not working yet) When using "platform create" it will create a remote platform and make it the selected platform. For instances for iPhone OS debugging on Mac OS X one can do: (lldb) platform create remote-ios --sdk-version=4.0 Remote platform: iOS platform SDK version: 4.0 SDK path: "/Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0" Not connected to a remote device. (lldb) file ~/Documents/a.out Current executable set to '~/Documents/a.out' (armv6). (lldb) image list [ 0] /Volumes/work/gclayton/Documents/devb/attach/a.out [ 1] /Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0/Symbols/usr/lib/dyld [ 2] /Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0/Symbols/usr/lib/libSystem.B.dylib Note that this is all happening prior to running _or_ connecting to a remote platform. Once connected to a remote platform the OS version might change which means we will need to update our dependecies. Also once we run, we will need to match up the actualy binaries with the actualy UUID's to files in the SDK, or download and cache them locally. This is just the start of the remote platforms, but this modification is the first iteration in getting the platforms really doing something. llvm-svn: 127934
* Fixed a bug where the disassembly syntax specified for theSean Callanan2011-03-091-1/+2
| | | | | | | ARM disassembler was wrong, causing the disassembler to fail to initialize. llvm-svn: 127302
* LLDB now has "Platform" plug-ins. Platform plug-ins are plug-ins that provideGreg Clayton2011-03-082-28/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | an interface to a local or remote debugging platform. By default each host OS that supports LLDB should be registering a "default" platform that will be used unless a new platform is selected. Platforms are responsible for things such as: - getting process information by name or by processs ID - finding platform files. This is useful for remote debugging where there is an SDK with files that might already or need to be cached for debug access. - getting a list of platform supported architectures in the exact order they should be selected. This helps the native x86 platform on MacOSX select the correct x86_64/i386 slice from universal binaries. - Connect to remote platforms for remote debugging - Resolving an executable including finding an executable inside platform specific bundles (macosx uses .app bundles that contain files) and also selecting the appropriate slice of universal files for a given platform. So by default there is always a local platform, but remote platforms can be connected to. I will soon be adding a new "platform" command that will support the following commands: (lldb) platform connect --name machine1 macosx connect://host:port Connected to "machine1" platform. (lldb) platform disconnect macosx This allows LLDB to be well setup to do remote debugging and also once connected process listing and finding for things like: (lldb) process attach --name x<TAB> The currently selected platform plug-in can now auto complete any available processes that start with "x". The responsibilities for the platform plug-in will soon grow and expand. llvm-svn: 127286
* Abtracted all mach-o and ELF out of ArchSpec. This patch is a modified formGreg Clayton2011-02-231-7/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Fixed an issue where detection of vCont support wasn't being done correctly.Greg Clayton2011-02-162-26/+26
| | | | | | Fixed how the LLDBDisassembler computes and uses a target triple. llvm-svn: 125617
* Patch to remove uses of non-standard strcasestr and replace then withGreg Clayton2011-02-041-3/+3
| | | | | | strncasecmp equivalents from Kirk Beitz. llvm-svn: 124889
* A few of the issue I have been trying to track down and fix have been due toGreg Clayton2011-01-171-4/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | the way LLDB lazily gets complete definitions for types within the debug info. When we run across a class/struct/union definition in the DWARF, we will only parse the full definition if we need to. This works fine for top level types that are assigned directly to variables and arguments, but when we have a variable with a class, lets say "A" for this example, that has a member: "B *m_b". Initially we don't need to hunt down a definition for this class unless we are ever asked to do something with it ("expr m_b->getDecl()" for example). With my previous approach to lazy type completion, we would be able to take a "A *a" and get a complete type for it, but we wouldn't be able to then do an "a->m_b->getDecl()" unless we always expanded all types within a class prior to handing out the type. Expanding everything is very costly and it would be great if there were a better way. A few months ago I worked with the llvm/clang folks to have the ExternalASTSource class be able to complete classes if there weren't completed yet: class ExternalASTSource { .... virtual void CompleteType (clang::TagDecl *Tag); virtual void CompleteType (clang::ObjCInterfaceDecl *Class); }; This was great, because we can now have the class that is producing the AST (SymbolFileDWARF and SymbolFileDWARFDebugMap) sign up as external AST sources and the object that creates the forward declaration types can now also complete them anywhere within the clang type system. This patch makes a few major changes: - lldb_private::Module classes now own the AST context. Previously the TypeList objects did. - The DWARF parsers now sign up as an external AST sources so they can complete types. - All of the pure clang type system wrapper code we have in LLDB (ClangASTContext, ClangASTType, and more) can now be iterating through children of any type, and if a class/union/struct type (clang::RecordType or ObjC interface) is found that is incomplete, we can ask the AST to get the definition. - The SymbolFileDWARFDebugMap class now will create and use a single AST that all child SymbolFileDWARF classes will share (much like what happens when we have a complete linked DWARF for an executable). We will need to modify some of the ClangUserExpression code to take more advantage of this completion ability in the near future. Meanwhile we should be better off now that we can be accessing any children of variables through pointers and always be able to resolve the clang type if needed. llvm-svn: 123613
* Fixed the "-b" option on disassembly to always pad out the bytes with forGreg Clayton2011-01-081-3/+6
| | | | | | | i386 and for x86_64 to allow 15 byte opcodes to be displayed. This outputs clean looking disassembly when the bytes are shown. llvm-svn: 123094
* Fixed a bug where the LLVM disassembler wasSean Callanan2010-11-101-1/+1
| | | | | | ignoring the show_address parameter. llvm-svn: 118666
* Revert last checkin to DisassemblerLLVM.cpp; that was some temporaryJason Molenda2010-11-041-5/+0
| | | | | | debug printfs that got left behind by accident. llvm-svn: 118244
* Built the native unwinder with all the warnings c++-4.2 could muster;Jason Molenda2010-11-041-0/+5
| | | | | | | | | fixed them. Added DISALLOW_COPY_AND_ASSIGN to classes that should not be bitwise copied. Added default initializers for member variables that weren't being initialized in the ctor. Fixed a few shadowed local variable mistakes. llvm-svn: 118240
* Added the ability to get the disassembly instructions from the function andGreg Clayton2010-10-062-33/+39
| | | | | | symbol. llvm-svn: 115734
* Moved the section load list up into the target so we can use the targetGreg Clayton2010-09-141-5/+5
| | | | | | to symbolicate things without the need for a valid process subclass. llvm-svn: 113895
* Added extensive logging of the code that is actually goingSean Callanan2010-07-231-9/+13
| | | | | | | | | | | | to be executed by the inferior. This required explicit support from RecordingMemoryManager for finding the address range belonging to a particular function. Also fixed a bug in DisassemblerLLVM where the disassembler assumed there was an AddressRange available even when it was NULL. llvm-svn: 109209
* Updated LLVM and Clang to July 20 at 16:00.Greg Clayton2010-07-211-6/+3
| | | | llvm-svn: 109016
* Merged Eli Friedman's linux build changes where he added Makefile files thatGreg Clayton2010-07-092-2/+15
| | | | | | | enabled LLVM make style building and made this compile LLDB on Mac OS X. We can now iterate on this to make the build work on both linux and macosx. llvm-svn: 108009
* Fixed up disassembly to not emit the module name before all function namesGreg Clayton2010-07-011-2/+2
| | | | | | | | | | | | that are in the disassembly comments since most of them are in the same module (shared library). Fixed a crasher that could happen when disassembling special section data. Added an address dump style that shows the symbol context without the module (used in the disassembly code). llvm-svn: 107366
* Centralized all disassembly into static functions in ↵Greg Clayton2010-06-302-21/+41
| | | | | | | | | | | | | | | | | | | | | | | | source/Core/Disassembler.cpp. Added the ability to read memory from the target's object files when we aren't running, so disassembling works before you run! Cleaned up the API to lldb_private::Target::ReadMemory(). Cleaned up the API to the Disassembler to use actual "lldb_private::Address" objects instead of just an "addr_t". This is nice because the Address objects when resolved carry along their section and module which can get us the object file. This allows Target::ReadMemory to be used when we are not running. Added a new lldb_private::Address dump style: DumpStyleDetailedSymbolContext This will show a full breakdown of what an address points to. To see some sample output, execute a "image lookup --address <addr>". Fixed SymbolContext::DumpStopContext(...) to not require a live process in order to be able to print function and symbol offsets. llvm-svn: 107350
* Fixed a problem where invalid triples were being passedSean Callanan2010-06-161-1/+1
| | | | | | | into the constructor for the LLVMDisassembler, resulting in asserts. llvm-svn: 106160
* Made lldb_private::ArchSpec more generic so that it can take a mach-o cpuGreg Clayton2010-06-111-29/+25
| | | | | | | | | | | | | | | | type and sub-type, or an ELF e_machine value. Also added a generic CPU type to the arch spec class so we can have a single arch definition that the LLDB core code can use. Previously a lot of places in the code were using the mach-o definitions from a macosx header file. Switches over to using "llvm/Support/MachO.h" for the llvm::MachO::XXX for the CPU types and sub types for mach-o ArchSpecs. Added "llvm/Support/ELF.h" so we can use the "llvm::ELF::XXX" defines for the ELF ArchSpecs. Got rid of all CPU_TYPE_ and CPU_SUBTYPE_ defines that were previously being used in LLDB. llvm-svn: 105806
* Initial checkin of lldb code from internal Apple repo.Chris Lattner2010-06-082-0/+579
llvm-svn: 105619
OpenPOWER on IntegriCloud