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.
Is it possible to extract the current state of a C/C++ program using LLDB, without starting an interactive session? I've seen some information about the LLDB API but I haven't seen much info about how to use it, and if it can even accomplish what I'm looking for.
Ideally, I would write some code in Python or something, that is external the code I am debugging, where I use the LLDB API to get information about the current program, such as current variables and values, and can start and stop execution. Is this (or a subset of this) possible? Is there some alternative?
Here is some pseudocode for what I would like to do:
state = program.getState()
print state.values
program.next()
newState = state.set("newVariable", 10)
program.setState(newState)
program.continue()
The Xcode debugger is implemented using lldb's API's. Xcode happens to offer an lldb command console as well, but all the UI commands are implemented using the public SB API's directly.
So it is certainly possible to do what you want.
Here's an example of driving a program with the SB API's:
https://github.com/llvm/llvm-project/blob/master/lldb/examples/python/process_events.py
Here's an example of fetching all the global variables and their values:
https://github.com/llvm/llvm-project/blob/master/lldb/examples/python/globals.py
There are a bunch of other examples in that directory that do parts of what you might be interested in. If there's anything (within reason) you want to do with the SB API's but can't find a way to do, please file a bug with http://bugs.llvm.org. The intent is that the SB API's provide a complete interface to LLDB, orthogonal to the command interpreter.
Of course, you can also use the command interpreter in non-interactive mode if you prefer (through the SBCommandInterpreter class), though I don't suggest that for programming the debugger since that ends up tying your code to the specifics of the output of the various lldb commands, and we don't guarantee that output as API...
I am using Lua 5.3, hosting it in a C++ application. The C++ application provides various functions to a running Lua script. I would like to allow users to debug their Lua, while it is running in my application. I believe this is possible, but I can not find any recent information on doing this, only for older versions of Lua and this does not seem to work.
Can anyone please help me to get debugging a Lua script running under my application up and running? Any help would be greatly appreciated.
Thank you!
The easiest way that I know of is to use ZeroBrane's remote debugging capabilities. Their document explains it pretty nicely, but for the sake of self-containment:
Set your embedded Lua's path/cpath to zerobrane's stuff, or copy the mobdebug.lua file to your sources.
Add require('mobdebug').start() to the beginning of your code
You should be able to debug now. After you start your program, breakpoints set in the Lua sources should get hit.
This approach works best if you use ZB to edit your Lua files, which implies using a different editor for the C++ part. I found this to work reasonably well in practice, though.
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
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.