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...
Related
Hi according to this post, unbuffer connects to a command via a pseudo-terminal (pty), which makes the system treat it as an interactive process, therefore not using any stdout buffering.
I would like to use this function on Windows. May I know what is the equivalent of unbuffer program on Windows? Thanks.
I spent some time on this and succeeded. I found this blog during research, and decided to return and provide my solution to save the next guy some time. I'm responding as a guest with a false email so I won't be interacting, but no further information should be required.
On Jul 18 '12 at 19:41 Harry Johnston wrote:
"In principle, if you know how much data to expect, you could use the console API functions to create a console for the application to write to, and then read the output from the console. But you can't do that from Java, you would need to write a C application to do it for you."
Thing is, there is already a utility that does this. It's written for a slightly different use, but it can be coxed into providing the desired result. Its intended purpose is to enable a windows console app to interact with a Linux style tty terminal. It does this by running a hidden console and accesses the console buffer directly. If you tried to use it – you'd fail. I got lucky and discovered that there are undocumented switches for this utility which will allow it to provide simple unbuffered output. Without the switches it fails with the error – the output is not a tty – when trying to pipe output.
The utility is called winpty. You can get it here:
https://github.com/rprichard/winpty/releases
The undocumented switches are mentioned here:
https://github.com/rprichard/winpty/issues/103
I’m using the MSYS2 version. You’ll need the msys-2.0.dll to use it.
Simply run:
winpty.exe -Xallow-non-tty -Xplain your_program.exe | receive_unbuffered_output.exe
-Xallow-non-tty , will allow piped output
-Xplain , will remove the added Linux terminal escape codes (or whatever they’re called)
Required files are:
winpty.exe
winpty-agent.exe
winpty.dll
msys-2.0.dll
winpty-debugserver.exe – Not needed
The behaviour you're describing is typical of applications using run-time libraries for I/O. By default, most runtime libraries check to see whether the handle is a character mode device such as a console, and if so, they don't do any buffering. (Ideally the run-time library would treat a pipe in the same way as a console, but it seems that most don't.)
I'm not aware of any sensible way to trick such an application into thinking it is writing to a console when it is actually writing to a pipe.
Addendum: seven years later, Windows finally supports pseudoconsoles. If you are running on Windows 10 v1809 or later, this new API should solve your problem.
On older versions of Windows, if you know how much data to expect, you could in principle use the console API functions to create a console for the application to write to, and then read the output from the console. But you can't do that from Java, you would need to write a C application to do it for you.
Similarly, in principle it should presumably be possible to write a device driver equivalent to a Unix pseudo-terminal, one that acts like a pipe but reports itself to be a character-mode device. But writing device drivers requires specific expertise, and they have to be digitally signed, so unless there is an existing product out there this approach isn't likely to be feasible.
Disclaimer: My answer only deals with executables compiled using MSVC.
The buffering policy is coded inside Microsoft C Runtime (CRT) Library. You can learn the details here. This article suggests using console handles and manipulate console buffers to receive unbuffered output.
However, there's an undocumented feature inside Microsoft C Runtime to inherit file handles with some internal flags directly from its parent process using lpReserved2 and cbReserved2 fields of STARTUPINFO structure. You can find the details in the crt source code provided by Microsoft Visual Studio. Or search for something like posfhnd on GitHub.
We can exploit this undocumented feature to provide a pipe handle and specify FOPEN | FDEV flags to the child process, to fool the child process treat that pipe handle the same way as a FILE_TYPE_CHAR handle.
I have a working Python3 script to demonstrate this method.
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 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 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