[support]

Hi,

Did you let VisualGDB generate a makefile/flags.mak, or did you reuse an existing makefile?
Does the makefile in your project directory have any comments related to VisualGDB?

[support]

Hi,

Please post the entire build log here. It should contain additional information that will help identify your problem.

[support]

Hi,

That`s a known bug of VisualGDB 3.0. Please download the 3.1 Beta 1.

[support]

Hi,

If you could quote a good example showing how using those functions simplifies viewing of complex data types, we would certainly consider supporting it in the future versions.

[support]

We`re sorry to hear that most of the tool version combinations did not work, however we cannot do much about it, as the GNU tools are out of our control.
We could only recommend using Ubuntu or other more popular Linux distributions that have bigger communities and fewer bugs.

[support]

Hi,

That is starting to look like a GCC or GDB bug. Can you try using a newer version? Will GDB accept map<...>::_RepType in another context? Will it handle map::key_type?

[support]

This can be it. Is it declared directly inside std::map<> or somewhere else? How exactly is _M_t declared?

[support]

Hi,

That is correct. However, we need to find a type that can be represented from the type of your map. E.g. std::map<...>::some_name. I.e. there should be a definition ‘typedef std::_Rb_tree<...> some_name;’ somewhere inside the std::map implementation. The name used in this typedef is what we are looking for.

Please try to find the declaration of _M_t. The code is pretty obscure, so you might need to use search instead of ‘go to definition’. Let us know the type used in the declaration.

[support]

Hi,

Please find where exactly _Rep_Type is declared on your machine (i.e. within which class). Alternatively you can add _M_t to the watch window (use correct stack frame) and see the type column for more hints.

[support]

Hi. Sorry for the delayed reply. We were trying to reproduce the problem on our Linux setups, but were unsuccessful.
Your problem is caused by VisualGDB trying to get cast the tree node pointer to a class that contains information about the descendents and the value. Normally this class is available as std::map<...>::_Rep_type::_Link_type.
It looks like your version of STL has different names for it. Please try the following steps to get the name of the tree node class:

1. Create a trivial program:

std::map test;

test[3] = 3.5;

2. Step into the second line by pressing F11.
3. Keep stepping into the STL code until you reach the _M_end() method:

_Link_type
_M_end()
{ return static_cast<_link_type>(&this->_M_impl._M_header); }

4. Please take a note of the return type of _M_end(). In our case it’s _Link_type.
5. Use the ‘call stack’ window to find the innermost frame that belongs to the map class itself. In our case this is map<...>::lower_bound():

iterator
lower_bound(const key_type& __x)
{ return _M_t.lower_bound(__x); }

6. Find where _M_t is declared and take a note of its type. In our case it’s _Rep_type:

_Rep_type _M_t;

7. In the GDB Console select ‘All GDB interaction’ and find the line causing the error you mentioned. Copy it and rerun the command to ensure that GDB still complains.
8. Modify the line to use the node type name you have derived. Ensure that GDB executes the command successfully.
9. Send us the node type name you have found. We will update our type visualizers to support your version of STL.

[support]

The easiest way would be to let VisualGDB connect via SSH already as root:

1. Open a root shell with ‘sudo su’
2. Change the root password with ‘passwd’
3. In VisualGDB Project Properties (right-click on the project file to open) find the ‘Remote Computer’ setting, select ‘New connection’ and enter ‘root’ as the user name and the password you set in the previous step.

From now on the project will be built and debugged as root.

[support]

As discussed per email, this is the limitation of the TrueSTUDIO GDB server. Using a GDB server that is not restricted to TrueSTUDIO is the solution.

[support]

Hi,

Please ensure that the the DLL being loaded contains symbols. Please run the ‘info shared’ command in the GDB Session window and paste the output here. Please also run the ‘info sources’ command to see which source files are listed in the currently loaded symbols.

[support]

Hi,

Thank you for your feedback. We have added support for build variables in custom directory mapping to the upcoming v3.1 release.

[support]

Hi,

Yes, using OpenOCD is possible, however we currently do not provide a step-by-step tutorial. Please refer to community-hosted instructions on setting up GDB with OpenOCD to get the OpenOCD arguments and GDB starup commands.
Please use the VisualGDB project wizard or the VisualGDB Project Properties window to provide those commands to VisualGDB.

[Author]

Posts