I am wondering how people typically go about debugging applications that are written in multiple languages.
For example, you could have some javascript that calls some back end python code. Is there a way to set up debugging so that you can start debugging in one language i.e. javascript, and then switch to the python debugger once that bit of code gets called?
My use case is with PowerShell and some .NET class libraries but it seems like there might be a broader set of use cases.
I've just started on a project and I'm stuck. The projects goal is to trace the execution of a program. I've looked at Capstone engine, but as far as I can tell it doesn't allow live code execution and stepping. I want something that is able to trace execution, step, convert to assembly, and has an api or other way of other programming with it. GDB is perfect except for the very last part. It has an api for python, but gdb executes it rather than the other way around. So far, the only way I can see of meeting my goal is to write bindings for gdb to another language. Is this possible(seeing as it's a shell and all), or are there any other possible solutions that I'm missing?
To Clarify: Is there a library or framework that is similar to gdb in its functionality?
Is there a library or framework that is similar to gdb in its functionality?
You are looking for libgdb, but that project is dead.
However, lldb may be the answer. From linked page:
The LLDB debugger APIs are exposed as a C++ object oriented
interface in a shared library.
Your question is rather general but I can point to a few examples.
You can set your own breakpoints and then Next Until Breakpoint. The python can tell gdb to next/step/cont in the target via the gdb.execute method. I think this will meet your goal with some python enhancements.
Based on the same idea, you can look at the stack and do check for a particular function. This example shows the general way to feedback information to gdb through the python interface. You can set variables with the python code then use the gdb if/else functionality to make decisions.
I am writing a big project using c++. In this project, some lua scripts will be called to implement functions. Now I want to set breakpoints in lua scripts but I don't know how to do that. I would prefer something like "pdb.set_trace()" as for python.
Any idea would be appreciated. Thanks in advance.
Unfortunately, Lua has no built-in debugger, and many of the debugging options available to you in the Lua standalone are not available in an embedded Lua scenario.
One way to deal with this would be to "script in" debugging - simply use print(whatever) and print(debug.traceback()) liberally throughout the code, possibly switched on or off by a DEBUG global (perhaps set by a DEBUG #define in the C++ code) so that the messages wouldn't be emitted in production executables.
Also, when using lua_pcall(), if a function has an error, it calls debug.traceback() and puts the resulting string on the stack. You can get it with:
lua_pushcfunction(L, c_function_name);
lua_pushnumber(L, 5.3);
if (lua_pcall(L, 1, 0, 0) != 0) lua_error(L);
A note: none of this works unless you open the debug library first, using luaopen_debug(L); where L is your lua_State*.
If you really do need interactive debugging, as #Colonel Thirty Two said, you should find an interactive debugging library; I'm sure one is available, but that is outside the scope of a StackOverflow question.
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
Can GO be used as a scripting language within an application ? I can't find any informations about this: is there a dynamic link library version which could be interfaced from a Windows application with some standard methods such as Compile(), Execute and features such as callbacks, variables sharing etc ?
This might sound strange at first but go with me on this: I think it would be a perfect candidate for a scripting language because it's compile time is so fast....hear me out...
Most scripting languages are interpreted, and so they do not require (or even provide in some cases) compilation. However compiled languages are safer in general because they can catch certain errors at compile time, which is better than, for example, catching a syntax error at runtime.
With Go, the compile time is so speedy that whatever program is running your Go code (e.g. a web server) could hypothetically compile the code on-demand if the code has changed, and otherwise use the compiled version.
Actually if you check out Google App Engine and download their dev web server for Go (https://developers.google.com/appengine/) you'll notice that their web server does exactly this. If you run through their Hello World tutorial for Go you'll notice that if you make changes to your code you won't need to recompile the Go code in order for the changes to take affect.
Go is not a scripting language. Because Go is designed for fast compilation, there have been some attempts to use it as a scripting language. For example,
gorun
GoNow
In theory (and perhaps somewhere out there w/o me knowing), Go can be used as a script language. Just note that it makes as much sense as using e.g. C as a scripting language.
No. Go code cannot be used within a non-Go application unless Go is responsible for starting up the whole app.