I have an embedded project which runs on a 68332 processor target (68k family). There is no OS on the target. We have a custom simulator that will allow our code to execute within Windows. The simulator is completely without our control to modify. Basically the simulator is executing the machine code which isn't very good when you need to debug. What I would really like to do is interface a debugger to allow us to debug at the source level rather than at the machine/assembly level. Has anyone ever done such a thing? Is there a spec that debuggers support? Perhaps would something like gdb work for this? Any advice is appreciated.
This is not necessarily an answer to your question - I'm not familiar with hooking up an existing 3rd-party debugger to a program executing inside a VM so I can't advise about that.
However, you control the source of your simulator so you can try implementing an interface (maybe a local socket, etc.) where your simulator keeps reporting status information about the code that's executing and links it up with source files by reading debug information from some generated debugging database. You'd likely have to support reading the debugging format of the compiler that compiles your 68k code and then use that information to link back assembly instructions to source code lines.
This way you're effectively implementing a debugger, but since you already have the simulator (a VM really), that's probably not too much of extra work - the simulator already has all state information about the executing 68k code, you just need a way to temporarily pause execution and extract state information during pause. Stepping through code after that is probably a trivial repeat of these steps.
I am very interested in learning more about the specifics of debugging, and I am looking into making a very simple GUI for debugging with GDB.
I understand in general how debuggers work, but I am having trouble of how an IDE interacts with an external debugger like GDB.
I am sure I could call commands to setup breakpoints and such in the debugger, but I am unsure of how an IDE would get the information back like, oh the breakpoint you set has been hit or variable values and such. Is there good information of using GDB within another program, I tried searching google, but all results I get are about how to debug another program using GDB or setting it up in a IDE already developed.
does it involve hooking into GDB? or does GDB have a library?
Thanks.
does it involve hooking into GDB? or does GDB have a library?
No and no.
GDB has a machine interface, intended for interfacing between and IDE and GDB.
I want to write a GUI based debugger wrapped over GDB. Because, I dont want the program to stop after watch points or break points. Instead, it should redirect the details like filename, line number, new value and stuffs to a file and continue execution.
I am pretty bad at scripting. So, I want some starting point to start developing front end for GDB. As far as I googled, this link http://ftp.gnu.org/old-gnu/Manuals/gdb-5.1.1/html_node/gdb_211.html is not much understandable for a beginner in this activity?
Hopefully, I will get help on development in C/C++.
For writing a GDB frontend, you indeed want to use the GDB/MI protocol but perhaps read this up-to-date copy instead of the older one you linked to.
Sample GDB/MI session
(Lightly edited version of this section from the GDB manual)
Launching GDB with the MI Command Interpreter
$ gdb -q --interpreter=mi2
=thread-group-added,id="i1"
(gdb)
File /bin/true
-file-exec-and-symbols /bin/true
^done
(gdb)
Break main
-break-insert main
^done,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="0x00000000004014c0",func="main",file="true.c",fullname="/usr/src/debug/coreutils-8.17/src/true.c",line="59",times="0",original-location="main"}
(gdb)
Run and Breakpoint Hit
-exec-run
=thread-group-started,id="i1",pid="2275"
=thread-created,id="1",group-id="i1"
^running
*running,thread-id="all"
(gdb)
=library-loaded,id="/lib64/ld-linux-x86-64.so.2",target-name="/lib64/ld-linux-x86-64.so.2",host-name="/lib64/ld-linux-x86-64.so.2",symbols-loaded="0",thread-group="i1"
=library-loaded,id="/lib64/libc.so.6",target-name="/lib64/libc.so.6",host-name="/lib64/libc.so.6",symbols-loaded="0",thread-group="i1"
=breakpoint-modified,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="0x00000000004014c0",func="main",file="true.c",fullname="/usr/src/debug/coreutils-8.17/src/true.c",line="59",times="1",original-location="main"}
*stopped,reason="breakpoint-hit",disp="keep",bkptno="1",frame={addr="0x00000000004014c0",func="main",args=[{name="argc",value="1"},{name="argv",value="0x7fffffffde98"}],file="true.c",fullname="/usr/src/debug/coreutils-8.17/src/true.c",line="59"},thread-id="1",stopped-threads="all",core="1"
(gdb)
Continue
-exec-continue
^running
*running,thread-id="1"
(gdb)
=thread-exited,id="1",group-id="i1"
=thread-group-exited,id="i1",exit-code="0"
*stopped,reason="exited-normally"
Quitting GDB
(gdb)
-gdb-exit
^exit
Existing GDB/MI Clients
There are several GDB/MI client implementations in C, C++, Java, Python. I'll list a few that I find easy to read:
The inactive libmigdb project (sample program, public interfaces) -- The good news is that it's an attempt at creating a reusable C library. The bad news is that it's not well maintained, e.g. I think it's missing GDB non-stop mode and catchpoint commands support, features that your use case would likely need.
python-gdb-mi -- Quite readable if you know Python
The C++ GDB/MI client code in QtCreator -- Also quite readable though it's written as part of an abstraction layer to support multiple debugger engines.
You might want to also browse this list of GDB frontends.
Since you already pointed out the gdb/mi interface maybe an existing solution might give you an idea on how to address your needs. Here is a list of existing interfaces. Look at their approaches and how they address the different issues.
Another approach that might be helpful could be automated sessions. Not to discourage you from writing a gdb gui, but such an automation could be a good start to get a feeling for the steps needed and could maybe also used as a start. Maybe generating a session script and starting gdb with it. gdb -x to load a command file.
Here a link concerning automating:
What are the best ways to automate a GDB debugging session?
I hope it helps. Good luck!
Though writing new GUI tools gives you more knowledge, I suggest you to take up eclipe and modify according to your needs. It saves lot of your time as well as more flexible.
Programming a gdb wrapper to achieve your goal is way to much work.
See how you can execute script on breakpoint hits: gdb scripting: execute commands at selected breakpoint
Also take a look a gdb tracepoints: http://sourceware.org/gdb/onlinedocs/gdb/Tracepoints.html
I hope I'm asking this the right way but I am just getting started trying to learn exploit development. I've taken several tutorials and started off using gdb in Linux, which I am somewhat comfortable in. I'm now starting to use Immunity Debugger on Windows and have a question about how to view functions within the gui.
In gdb I could use the commands:
info functions
disas main
and be able to see the main function. My compiled code is unstripped for simplicity.
How can I recreate this in Immunity or OllyDbg? I want to see a list of functions so I can either examine them or set breakpoints on them. I can't seem to figure it out!
Thanks!
This can be achieved programatically in ImmunityDebugger:
module = imm.getModule('calc.exe')
if not module.isAnalysed():
module.Analyse()
functions = imm.getAllFunctions(module.getBase())
# functions is a list of function addresses in calc.exe
There is also another function:
imm.searchFunctionByName('name_to_search')
But in my experience, this is not very reliable. IDA Pro is the better way to achieve this. Its disassembly engine is superior to Ollydbg. You could get the function offets from IDA and then find them in Ollydbg.
Lastly, I would recommend WinDbg if you are doing exploit development. It takes time to learn it, but is more powerful and feature-rich than Ollydbg ( kernel debugging, for instance).
During web searching, I found the following comment : Traditional Lisp debugging practices can still be used.
What are the traditional debugging practices?
Normally, what tools are used for debugging lisp (with/without emacs)?
I don't know what Bill meant specifically, but IME:
Typically your editor will have a running instance connected to it. You can compile functions immediately to insert them into the running image -- since Lisp has its own compiler, you're just telling the running image to read and compile a small section of text. Or you can run functions directly, to see what they do.
When an exception is thrown (or a condition is signaled, if you're lucky enough to be in a dialect with conditions), the debugger will show you the stack trace and let you decide how to continue.
The major difference between Lisp and other high-level compiled languages is that in Lisp you're basically always writing code with the debugger attached.
As clojure was tagged in the question, I'll give our perspective.
Class files generated by the clojure compiler include line- and method-based debugging info, so any java debugger will interoperate directly with clojure code, including breakpoints and object inspection.
If you use emacs/slime as your development environment, integration with slime's debugger has recently been included. As documentation is a little sparse, it's probably best to check out the scope of the support on github directly.
Run edebug-defun in emacs and you will see that lisp is magic.
In something that I would call approaches a "traditional set of Lisp debugging techniques" are:
Debug printouts
Function tracing (each invocation of a traced function
is printed with an indentation that corresponds to call depth, on return the return
value is printed).
Explicit invocation of the in-image debugger
Ending up in the in-image debugger due to a bug (trying to add an integer and a symbol, for example)
Basically just things like adding code to print out values as it runs so you can see what's happening.