Forum Replies Created
-
Posts
-
Hi,
The Program Files directory is normally not writable (unless you launch VS as Administrator which is often not the case), so we store the downloaded files under $(LOCALAPPDATA).
We intentionally don’t pre-install ALL of the BSPs with VisualGDB as they often get updated and none of our users will probably need ALL of the BSPs for ALL supported platforms at the same time.
The STM32 BSP is indeed huge, but as the modern HDDs/SSDs are huge as well and the scenario of one computer/multiple users is relatively rare, we don’t want to change the current layout. As a possible quick workaround we could recommend creating symbolic links between the BSP directory under %LOCALAPPDATA%\VisualGDB and a shared BSP location outside the users’ appdata directories.
BTW, we are currently experimenting with storing $(BSP_ROOT) paths in the .vcxproj files instead of the relative paths to relocated BSPs and are planning to include this in the upcoming Preview 3 of v5.3. This should solve the problem you mentioned.
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.
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.
Hi,
Yes, you can relocate the BSP as shown in this tutorial (requires Custom edition): https://visualgdb.com/tutorials/arm/multiuser/
Hi,
Looks like the image did not get uploaded properly. Could you please try attaching it to the post via the “attachments” button below?
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.
Hi,
Thanks for reporting this, looks like our bug. We have updated our profiler package. You can download it via Tools->Manage VisualGDB Packages.
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.
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.
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.
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.
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/
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).
