access gdb variables from matlab

Dear community, does anyone know how to access gdb (gnu debugger) memory space from matlab, while debugging external C/C++ code? Best Regards Mikhail

Answer 1

[mikhailo]

I found my way of interacting with GDB using tcpip, although it requires a bit of setup.

As I already said, gdb has a python interface. The way to proceed is to create tcpip tunnel to the (gdb) command line and then everything else is easy. So I wrote a small script that does that job (first attachment)

Instruction:

1. Download the following python script as save it somewhere (replace extension form .m to py)
2. create .gdbinit file in the folder of debug, where the following line is required: source path_to_the_script/py_dbg.py
3. start debugging and at the breakpoint execute the loaded function: python py_dbg(34555). Instead of that number can be any port you with to use. From that moment on, it is possible to access the gdb throug telnet.

From the Matlab side I wrote a function that explicitly extracts the matrix using this inteface. As I currently work with Armadillo objects, the second attached function is capable of correctly determining the size of the matrix and directly exporting it from gdb to Matlab.

for example, if the variable of interest is called temp, the following command would do the job:

port_no = 34555;
cpp_matrix = get_arma_val_gdb('temp',port_no)

I hope that can help someone. Of course, if someone finds a more straightforward way of doing that, I am interested.

Regards

Mikhail

Answer 2

[José-Luis]

Looks like the Mathworks support team knows how to.

[mikhailo]

Thanks for the link but it is not exactly what I am looking for. My question has nothing to do with mex debugging.

Situation is: I do debug an external C++ project outside matlab that contains large 2D arrays that are not pleasant to analyze in a row data mode. Options are:

1. dump data in file and then load it in matlab.
2. gdb seems to support python in command line -> option to pursue

But I wonder if there is a simple way to interface gdb with matlab such that I could access the gdb memspace from matlab it the following way

data = get_var_data_from_gdb(obj_name,first_index,last_index)

for that i can easily manipulate the data from matlab.

Some ideas?

[José-Luis]

Not that I know of. I have difficulties seeing how involving Matlab to debug a C++ program is a good idea though.

As you mention: What's wrong with writing a helper function that will dump your array to a text file? You could even directly write to a .mat file using the C++ API.

What's wrong with using gdb only? You can make the output be whatever you want.

[mikhailo]

To that question I would like to ask a similar one: what is wrong writing code directly in C++? Why using Matlab at all? I guess the answer is: convenience and efficiency.

The same is here: gdb raw text mode is less nice than Matlab IDE.

I reason I asked this question at all, I saw my colleague analyzing data in Matlab while debugging his c++ project in VS. He wrote mex plugin calling a dll that interacts with VS debugger. It is indeed a very nice feature to have as one can play with the data on-the-fly the way one wants, plot 3d graphs and analyze the equations. Being Linux user, I asked myself the question if I can get something like this with my tool-set.

I the meantime I think I found the answer that does not involve Matlab but python: http://www.codeproject.com/Articles/669606/Analyzing-C-Cplusplus-matrix-in-the-gdb-debugger-w

But I would still be interested in Matlab solution, should this appear one day.

[José-Luis]

Maybe something like loading libgdb.a with loadlibrary() could provide the functionality you want. Disclaimer: No idea if it'd work since I've never tested it for that. It's just what popped to mind and it'd be nice to hear if it works if you test it.

The comparison to writing code directly in C++ compared to Matlab is not a fair one, IMO.

My point is that there are already tools out there that interact with gdb. Although I understand the convenience of having everything under one roof, I'm still not a fan of the idea. GNU DDD looks nice for what it's worth.