[support]

Hi,

VisualGDB itself does not provide any special commands for programmatically dumping the memory, however you might be able to achieve this via gdb commands (since it’s not a VisualGDB feature, the specifics are not covered by our technical support, but we can do a detailed research and share detailed instructions via our consulting track if you prefer).

On the VisualGDB side, you can issue GDB commands via the GDB Session window, or create your own gdb scripts (e.g. with actions bound to breakpoints) and load them by adding the “source” command to VisualGDB Project Properties -> Additional GDB Commands.

You can also try using the Embedded Integration Tests. They support running arbitrary gdb commands.

[support]

Thanks, we have added it to the backlog and will try to address it in one of the next releases.

[support]

Hi,

Unfortunately, we were not able to reproduce the problem based on the description you provided.

In order for us to diagnose it further, please provide a clear description of steps we could follow on our side to reproduce the issue, according to our problem reporting guidelines.

[support]

Hi,

Sorry, this also doesn’t look like a VisualGDB-specific issue, but rather a problem with a specific computer. Please try creating and building an equivalent CMake-based project on it manually. If the project builds successfully outside VisualGDB, but causes errors when building with VisualGDB, we can help you replicate the manual build results. Otherwise, the issue is not caused by VisualGDB and is out of VisualGDB’s control.

[support]

Thanks, we have confirmed that gdb indeed unexpectedly disables conditional breakpoints that were set in a shared library prior to its load. As this is a bug in gdb, rather then VisualGDB itself, we can offer one of the following workarounds:

• You can try enabling all breakpoints by issuing the “enable” command via the GDB Session window after the library has been loaded, or by using the Breakpoints window in Visual Studio.
• You can also try using Python scripting to respond to breakpoint change events and reenable them.
• If your company purchases 5 licenses or more (or if the issue starts affecting a customer with 5 or more active licenses), we can add a special workaround to this on the VisualGDB side. The workaround will automatically detect breakpoints that have been disabled by GDB without VisualGDB asking for it, and will manually reenable them. This will imply using the stop-on-solib-events option.

[support]

Hi,

Normally both options should work the same way. Please try double-checking whether the LEDs start blinking after you power cycle the board after it has been programmed.

[support]

Hi,

This looks like a bug in a specific toolchain, rather than a VisualGDB issue. We can gladly help you find the root cause and devise a workaround, however as the issue is not in VisualGDB itself, we would have to charge a consulting fee for this work. Please contact our sales for a quote if you are interested.

[support]

Unfortunately, as you have not attached the full log, it’s hard to say what exactly is going on. Can you confirm that breakpoint #4 is created with enabled=”y” and then switches to enabled=”n” without VisualGDB issuing any breakpoint-related commands?

Regarding the second issue, could you please share the example C++ code and specific natvis file so that we could reproduce the issue on our side? Otherwise it’s hard to say what is going on.

[support]

Thanks for the update. We have rechecked everything and found a possible cause for the issue. Please try this build: VisualGDB-5.5.103.3919.msi

[support]

This might be caused by a recent change in the VS2019 CMake parser. Our latest build [VisualGDB-5.5.103.3919.msi] was fully tested with this VS version and might resolve the issue.

Regarding CMake, please make sure you understand the difference between running CMake on Raspberry Pi itself, and running it on Windows together with a cross-compiler. The CMake building instructions page does explain it in detail.

[support]

Thanks, this version should fully support the conditional breakpoints as expected.

If you could reproduce the breakpoint problem on a smaller project created from scratch, and share the steps for us to reproduce it on our side, we should be able to fix it. Also obtaining a gdb log may provide some extra clues (e.g. gdb might be rejecting breakpoint condition commands).

Regarding Natvis, please try the {*(::MyClassImpl*)m_pImpl} or {*static_cast<MyClassImpl*>(m_pImpl)} syntax instead.

[support]

Most likely, you have previously selected an incompatible combination of settings somewhere.

If you could share the exact steps to reproduce the problem from scratch per our problem reporting guidelines, we should be able to help you get it working.

[support]

Hi,

No problem, please try the steps below to narrow down the problem:

1. Try creating a new project and selecting “Store source files on the Windows computer” on the last page of the wizard. Does it solve the problem?
2. Does double-clicking on CMakeLists.txt file in Solution Explorer (so that it opens in a permanent tab) instead of a temporary one solve the problem?

Regarding property sheets, most likely you are using a version of CMake that does not support statement annotations. Please try right-clicking on the target icon in Solution Explorer (terminal icon) and select “Go to Definition”. If there are any issues with CMake, VisualGDB will display a link to detailed troubleshooting instructions.

[support]

No problem. Please let us know what Visual Studio version you are using.

Please also try the following steps to narrow down the test problem:

1. Open the solution in Visual Studio.
2. Open the View->Output window and switch to the Tests view.
3. Clear the Tests output.
4. Build the project and wait for it to finish.
5. Make sure the Test Explorer window is visible and wait until it doesn’t show any progress indication.
6. Open the View->Output window again, copy the entire output of the Tests view and post it here.

[support]

No problem, please attach a screenshot of the Help->About VisualGDB window so that we could check for common issues.

[Author]

Posts