Forum Replies Created
-
AuthorPosts
-
June 28, 2017 at 19:53 in reply to: Visual GDB error with shared librarys from remote machine #11607
support
KeymasterHi,
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
KeymasterHi,
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
KeymasterHi,
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
KeymasterHi,
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/
June 28, 2017 at 02:58 in reply to: Add option to select ProfilerDriver in stand-alone project #11587support
KeymasterHi,
This should be already fixed in VisualGDB 5.3 Preview 1. Please try updating to it.
support
KeymasterHi,
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
KeymasterHi,
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); }June 26, 2017 at 17:32 in reply to: Visual GDB error with shared librarys from remote machine #11578support
KeymasterHi,
Strange. The first step for diagnosing this would be to understand which component causes this message. Do you get it in the “GDBServer” window in Visual Studio, or elsewhere? If you are not sure, please simply attach a screenshot.
support
KeymasterHi,
Thanks for the screenshot and sorry about the confusion. This could happen if you were not right-clicking on a globally visible entity (like a function) that could be shown in a code map.
Please try first left-clicking on the function name, then ensure that it appears in the rightmost combo box on the smart navigation bar and finally right-click again. Does the code map menu appear?
support
KeymasterHi,
You could try using the _sbrk() implementation that comes from our “Fixed-size stack and heap” framework described in this tutorial: https://visualgdb.com/tutorials/arm/stack/
You would need to modify the linker script to place the “.heap” section into SDRAM and explicitly set the heap size via VisualGDB Project Properties.
support
KeymasterSorry, the screenshot did not get uploaded properly. Could you please upload it to an image sharing hosting? I.e. a screenshot showing the context menu when you right-click on a function like “main”.
support
KeymasterHi,
Good to know it works. BTW, we have added support for the “Peek definition” feature to the Clang IntelliSense in the upcoming VisualGDB 5.2 Preview 2, and also significantly improved performance and added a special mode for diagnosing parsing time. If this sounds like something worth giving a try, let us know and we can share a build with this feature.
support
KeymasterHi,
This could be caused by either X11 forwarding or the gdb signal handling. Please try configuring VisualGDB to display the X11 windows on the Raspberry Pi itself instead of forwarding them to your Windows machine. If this does not help, please check if you can reproduce the same behavior with a basic program that will not have any other code besides the waitKey() call.
support
KeymasterHi,
We usually only officially support major releases of the ESP-IDF, as the in-between versions that introduce new functionality often also break old features.
As the ESP-IDF is being developed very rapidly, we have actually added support for importing projects built directly by esp-idf that does not require an updated BSP from us.
I.e. you can simply replace the contents of the esp-idf.orig directory with the latest version of ESP-IDF and follow this tutorial: https://visualgdb.com/tutorials/esp32/esp-idf/
support
KeymasterHi,
The problem with treating the mbed-cli projects as normal editable VisualGDB projects is that it would depend on the internal format of the files generated by mbed-cli and will stop working each time the format changes.
So with mbed we essentially offer 2 approaches:
- Using our BSP that is verified, tested and maps common mbed features to easily editable embedded frameworks. But it’s updated quarterly as we need to manually keep up with the changes to mbed itself.
- Manually importing an mbed-cli project. This is less intuitive and requires some extra steps, but will still give you access to advanced debug and IntelliSense features and does not force you to use a specific mbed version.
-
AuthorPosts