[support]

Hi,

Normally, checking the VisualGDB Diagnostics Console for the exact list of commands executed by VisualGDB adn re-running them manually should explain what is going on. Most likely some of the system tools (like gdbserver) got corrupt and resulted in invoking ld.so instead.

[support]

Hi,

This could be related to a recently fixed bug in the 64-bit engine. Please try downloading this build: http://sysprogs.com/files/tmp/VisualGDB-5.3.2.1620.msi

If the crashes still happen, please try deleting the CodeDB directory and reopening the solution.

[support]

Hi,

Yes, you can relocate the BSP as shown in this tutorial (requires Custom edition): https://visualgdb.com/tutorials/arm/multiuser/

[support]

Hi,

Looks like the image did not get uploaded properly. Could you please try attaching it to the post via the “attachments” button below?

[support]

Hi,

You can enable it via Tools->Options->Text Editors->C/C++ (VisualGDB)->Other->Use 64-bit Clang Engine. Note that you will need to reopen your solution in order for this setting to take effect.

[support]

Hi,

OK, we have added support for IntelliSense-only precompiled headers to VisualGDB 5.3 Preview 2.

[support]

Hi,

Thanks for reporting this, looks like our bug. We have updated our profiler package. You can download it via Tools->Manage VisualGDB Packages.

[support]

Hi,

The problem with converting an arbitrary Makefile-based project is that different Make-based projects store settings like CFLAGS slightly differently, so extracting them fully and reliably quickly gets too complicated. We have long-term plans for a tool that would reconstruct a project based on build logs (showing all gcc invocations), but it will not work on 100% of projects as Make projects often include custom build steps.

We have checked the internals of cmake-cli and will contribute an exporter module that will construct a VisualGDB project (similar to what it does for IAR projects) if the mbed community is OK with this.

[support]

Hi,

The “launching custom program console” could be related. Please check the corresponding setting under VisualGDB Project Properties -> Custom Debug Steps. You might be accidentally launching ld.so as the custom console command.

[support]

Hi,

This is a known issue caused by a breaking change in the kernel 4.10. As a workaround, please try downgrading to an older kernel before we fix this.

[support]

Hi,

Please open VisualGDB Project Properties and check the “Provide default stubs for system calls” checkbox on the first page. This will include default implementations for functions like _sbrk() to your project.

[support]

Hi,

No problem. We have just released the Preview 2 that supports Peek Definition and has improved performance. You can download it here: http://visualgdb.com/download/

[support]

Hi,

This should be already fixed in VisualGDB 5.3 Preview 1. Please try updating to it.

[support]

Hi,

We have investigated this further and it looks like the mechanism responsible for showing CodeMap-like diagrams has been removed from VS2017 community (still works with VS2017 Enterprise).

You can find more details here: https://developercommunity.visualstudio.com/content/problem/41410/generate-graph-of-include-files-still-not-working.html (the Generate Graph of Include Files command uses the same mechanism).

[support]

Hi,

Most likely you would need to set the “optimize” attribute on some of the inline functions in the kernel headers. Please check the build log for the actual function that calls __smp_store_release(), e.g.:

1><...>\include\asm-generic\qrwlock.h(165,2): note :  in expansion of macro `smp_store_release'

E.g. with kernel 4.10 you would need to set the optimization for the queued_write_unlock() function:

static inline void queued_write_unlock(struct qrwlock *lock)
{
    smp_store_release(__qrwlock_write_byte(lock), 0);
}

[Author]

Posts