Nsight Eclipse C++ - Using GDB debugger with Eigen Matrices / Vectors and std::string
I am using the [i]Nsight Eclipse IDE[/i] from Nvidia Jetpack 3.2 to develop C++ applications for Jetson TX1/ TX2. My code has [color="orange"]std::string[/color] variables defined as: [code]std::string data = "{\"command\":\"sensors\"}";[/code] I also have [color="orange"]Eigen::MatrixXd[/color]/ [color="orange"]Eigen::VectorXd[/color] defined as: [code]Eigen::VectorXd ex_var(3); ex_var << 0, 0, 0;[/code] The code works without any syntax or runtime errors (but I need to check a few variables and outputs to verify some logic). When I use gdb from Ubuntu terminal, I can see the content of both [color="orange"]data[/color] and [color="orange"]ex_var[/color]. I have installed the gdb [url=https://bitbucket.org/eigen/eigen/src/8b18ff2c70289b47928ae75fdb89a6ac3d018e08/debug/gdb/printers.py?at=default&fileviewer=file-view-default]extension[/url] for [color="orange"]Eigen[/color]. However, when I try to view these variables in [i]Debug[/i] mode inside [i]Nsight Eclipse IDE[/i]: 1) In the case of [color="orange"]data[/color], I see [color="orange"]<not available>[/color] against _[color="orange"]M_local_buf[/color] field (and subfields) and a random [color="orange"]123'{'[/color] against [color="orange"]*_M_p[/color] field. How can I view string variables correctly? 2) In the case of [color="orange"]ex_var[/color], I can see the first value in the vector, against [color="orange"]*m_data[/color] field. How can I see the rest of the vector?
I am using the Nsight Eclipse IDE from Nvidia Jetpack 3.2 to develop C++ applications for Jetson TX1/ TX2. My code has std::string

variables defined as:

std::string data = "{\"command\":\"sensors\"}";



I also have Eigen::MatrixXd/ Eigen::VectorXd defined as:

Eigen::VectorXd ex_var(3);
ex_var << 0, 0, 0;



The code works without any syntax or runtime errors (but I need to check a few variables and outputs to verify some logic). When I use gdb from Ubuntu terminal, I can see the content of both data and ex_var. I have installed the gdb extension for Eigen. However, when I try to view these variables in Debug mode inside Nsight Eclipse IDE:

1) In the case of data, I see <not available> against _M_local_buf field (and subfields) and a random 123'{'
against *_M_p field. How can I view string variables correctly?

2) In the case of ex_var, I can see the first value in the vector, against *m_data field. How can I see the rest of the vector?

#1
Posted 04/16/2018 01:49 PM   
I have not used this extension, this isn't an answer...maybe it'll give you a place to start. Note that std::string is a class and not just the text you see: [url]http://www.cplusplus.com/reference/string/string/[/url] When you print an "object" in gdb, but you really want some particular field, then you need to specify that...otherwise you might end up seeing a pointer value instead. For example, you'll see std::string has a ".data()" and ".c_str()" function. If you string has name "sample", then in gdb you could: [code]p sample.data() p sample.c_str()[/code] The length of the data is found via ".length()", so you could do this: [code]p sample.length()[/code] When your code reaches out to a third party library (I'm guessing that's what your extension does...some kind of binding to python) it is up to the third party library to have debug symbols if you want gdb to see what is going on in that library. I have no idea how gdb behaves with scripted languages such as Python, but I suspect it is just a wrapper library and gdb probably has no way to look inside of Python (there will be other methods, but I have not heard of one for use in gdb). If your string's ".data()" is a pointer to memory not within your core program, then I'd expect no actual dereferenced value to be available. If the extension is actually part of another class, then I'd expect you to have to drill down further into that class...unfortunately, if that class is part of a library without symbols, then you may not have access to this. Some code, even if you would normally be able to debug it, may have been optimized such that data placed in registers cannot be seen. Make sure you did not compile with optimization. Make sure your libraries you link against were compiled with debug symbols and that optimization was not used. For vectors just use member functions to show, e.g.: [code]# Print third value of zero-based indexing: p sample_vector[2][/code] Note that any UNIX style system has a C linker...C was actually invented in conjunction with the invention of UNIX...and Linux follows the POSIX standards which make it "UNIX-like" (UNIX is a trade name, POSIX is the behavior UNIX implements). The linker has no concept of C++ namespaces. This means when there is an overloaded definition a hash value is generated in combination with the obvious name in order to make it unique...one has to "demangle" to reverse this. Some of the random characters you are seeing may be the mangled C name for a namespace-aware signature. Anything linked in by an external C library or C wrapper would have to do this. It wouldn't matter if there is currently nothing overloaded...the possibility of overloading implies mangling is mandatory before talking to a C-style object which isn't capable of understanding C++ overloads. I don't know if this is the case for what you described, but with what you have shown it is a candidate.
I have not used this extension, this isn't an answer...maybe it'll give you a place to start.

Note that std::string is a class and not just the text you see:
http://www.cplusplus.com/reference/string/string/

When you print an "object" in gdb, but you really want some particular field, then you need to specify that...otherwise you might end up seeing a pointer value instead.

For example, you'll see std::string has a ".data()" and ".c_str()" function. If you string has name "sample", then in gdb you could:
p sample.data()
p sample.c_str()


The length of the data is found via ".length()", so you could do this:
p sample.length()


When your code reaches out to a third party library (I'm guessing that's what your extension does...some kind of binding to python) it is up to the third party library to have debug symbols if you want gdb to see what is going on in that library. I have no idea how gdb behaves with scripted languages such as Python, but I suspect it is just a wrapper library and gdb probably has no way to look inside of Python (there will be other methods, but I have not heard of one for use in gdb). If your string's ".data()" is a pointer to memory not within your core program, then I'd expect no actual dereferenced value to be available. If the extension is actually part of another class, then I'd expect you to have to drill down further into that class...unfortunately, if that class is part of a library without symbols, then you may not have access to this.

Some code, even if you would normally be able to debug it, may have been optimized such that data placed in registers cannot be seen. Make sure you did not compile with optimization. Make sure your libraries you link against were compiled with debug symbols and that optimization was not used.

For vectors just use member functions to show, e.g.:
# Print third value of zero-based indexing:
p sample_vector[2]


Note that any UNIX style system has a C linker...C was actually invented in conjunction with the invention of UNIX...and Linux follows the POSIX standards which make it "UNIX-like" (UNIX is a trade name, POSIX is the behavior UNIX implements). The linker has no concept of C++ namespaces. This means when there is an overloaded definition a hash value is generated in combination with the obvious name in order to make it unique...one has to "demangle" to reverse this. Some of the random characters you are seeing may be the mangled C name for a namespace-aware signature. Anything linked in by an external C library or C wrapper would have to do this. It wouldn't matter if there is currently nothing overloaded...the possibility of overloading implies mangling is mandatory before talking to a C-style object which isn't capable of understanding C++ overloads. I don't know if this is the case for what you described, but with what you have shown it is a candidate.

#2
Posted 04/16/2018 03:36 PM   
I have compiled the code in Debug Mode. I think some more clarification regarding the problem would be helpful. The problem is not with the extension. If I use something like: [code]p sample[/code] or [code]p sample_vector[/code] in the commandline gdb, it prints the string or vector without any issues. I want to enable the same functionality for Eclipse GDB, in the Variables window of Eclipse Debug mode. My original idea was that whatever changes I make to gdb via commandline will be reflected in Eclipse GDB as well. But I don't think that's the case. Especially because I see [color="orange"]CUDA-GDB[/color] as the Debugger. 1) My current idea is that if commandline gdb can do it, Eclipse GDB should also be able to do it. But I am not able to figure out how. 2) This [url=https://help.eclipse.org/mars/index.jsp?topic=%2Forg.eclipse.cdt.debug.application.doc%2Ftasks%2Fcdt_t_run_dbg.htm]link[/url] shows that I can change the debugger in Eclipse, but I don't see the drop-down Debugger field under Debugger tab in Nsight Eclipse.
I have compiled the code in Debug Mode. I think some more clarification regarding the problem would be helpful. The problem is not with the extension. If I use something like:
p sample

or
p sample_vector

in the commandline gdb, it prints the string or vector without any issues.

I want to enable the same functionality for Eclipse GDB, in the Variables window of Eclipse Debug mode. My original idea was that whatever changes I make to gdb via commandline will be reflected in Eclipse GDB as well. But I don't think that's the case. Especially because I see CUDA-GDB as the Debugger.


1) My current idea is that if commandline gdb can do it, Eclipse GDB should also be able to do it. But I am not able to figure out how.

2) This link shows that I can change the debugger in Eclipse, but I don't see the drop-down Debugger field under Debugger tab in Nsight Eclipse.

#3
Posted 04/16/2018 03:59 PM   
I see...it should be possible to get eclipse gdb showing anything command line gdb does, but I am not familiar with how differences would show up. The concept of whether or not something linked has debug symbols or if it was optimized to invalidate symbols would still apply though. Whether or not namespaces are demangled when displayed would be a configurable option, but I do not know how this is set up in eclipse gdb.
I see...it should be possible to get eclipse gdb showing anything command line gdb does, but I am not familiar with how differences would show up. The concept of whether or not something linked has debug symbols or if it was optimized to invalidate symbols would still apply though. Whether or not namespaces are demangled when displayed would be a configurable option, but I do not know how this is set up in eclipse gdb.

#4
Posted 04/16/2018 04:33 PM   
Hi, Here is the CUDA gdb document for your reference: https://docs.nvidia.com/cuda/cuda-gdb/index.html Thanks.
Hi,

Here is the CUDA gdb document for your reference:
https://docs.nvidia.com/cuda/cuda-gdb/index.html

Thanks.

#5
Posted 04/17/2018 06:29 AM   
Scroll To Top

Add Reply