Forum Replies Created
-
AuthorPosts
-
supportKeymaster
OK guys, the Beta 1 is out so I need your feedback on it. Once we ensure it’s stable, I will release a complete source package that will include BazisLib so you won’t need to mess with installing and configuring it.
supportKeymasterHi,
Most likely your LD_LIBRARY_PATH is modified from .bashrc that is not processed when running commands like GDB over SSH directly (opposed to typing the command name manually in the shell). VisualGDB 4.3 Beta 2 actually detects this condition and configures a workaround automatically. Please try updating to it.
supportKeymasterYes, it fully supports the Community Edition. We have updated our download page.
supportKeymasterThat depends on the bug. If your bug caused an exception during program initialization (before main() got a chance to run), the breakpoints would not be triggered.
supportKeymasterOK, your prayers have been heard. I’ll try to get as much feedback from the community as I can and make a new release.
Regarding vmnt, have you installed BazisLib 3.0? It is needed by the latest WinCDEmu.supportKeymasterHi,
From the GDB perspective, the breakpoints are set correctly, but the tool simply exits. Are you missing custom LD_LIBRARY_PATH? Does the tool run normally when you launch it manually? Do you experience the same issues with a basic “Hello, World” tool?
November 9, 2014 at 20:01 in reply to: Can’t pull /system/bin/app_process on Android L Preview dev. #3091supportKeymasterHi,
Thanks for the log. The problem might actually be caused by VisualGDB. We have recently modified our workaround that handles VSPackage registration and it may be causing your problem. Please try this build:
http://visualgdb.com/tmp/VisualGDB-4.3.1.184.msi
Then create a registry value: HKLMSOFTWAREWow6432NodeSysprogsVisualGDBSettingsPackageSiteWorkaroundMode and set it to 2. If that does not help, set it to 0. Let us know if that solves the problem.supportKeymasterHi,
Do you get any IntelliSense errors in the Errors pane? IntelliSense currently uses a completely different mechanism than the compiler uses, so it is known miss some GCC-specific declarations occasionally. We are currently working on a separate IntelliSense engine that will understand GCC-specific code much better.
supportKeymasterHi,
You appear to be using a very old version of tar that has a known bug. Please update to a newer version or configure VisualGDB to ignore file transfer errors on the Project Settings page in VisualGDB Project Properties.
It also looks like you are doing either a clean or a rebuild on a project that does not define the clean rules. Please either use the ‘Build All’ command or add a clean rule to your Makefile.supportKeymasterHi,
The easiest way would be first import the actual app (it should have the jni folder defining which libraries to import), then import the library project:
1. Copy the AndroidManifest.xml file to the root directory of your library (the one that contains the jni subdirectory). It will be deleted later.
2. Import the library as if it was an app.
3. Delete the AndroidManifest.xml file.
4. In the VisualGDB Project Properties set the “This is a library-only project” checkbox on the Build Settings page.Note that we have added support for Gradle projects to VisualGDB 4.3.
supportKeymasterHi,
Sorry about your PhpBB experience, normally when you press ‘back’ in your browser, the text you entered on the page should reappear. if that does not happen, you may want to update your browser. We had to disable hyperlink posting for anonymous users because we were getting 20+ spam posts per day despite having a custom CAPTCHA.
Please find the answers to your questions below:
1. It is straight-forward. See the STM32 tutorial here: http://visualgdb.com/tutorials/arm/stm32/
2. You can use any GCC-based toolchain of your choice (some our customers even reported success with using the IAR compiler). However you may need to specify some GCC flags manually if your toolchain handles them differently from ours.
3. This is not directly supported by VisualGDB, however you can use the GDB tracepoint commands (https://sourceware.org/gdb/onlinedocs/gdb/Tracepoints.html) to collect data in a similar way. You can enter GDB commands directly in the GDB Session window while using VisualGDB.
4. Last time we checked, ST did not ship their own GDB Server. Hence we support OpenOCD and Texane ST-Link tool out-of-the-box. If you want to use some other GDBServer, simply choose the ‘custom mode’ and specify the path to your GDBServer manually.
5. You can support FreeRTOS threads by writing a thread visualization plugin. There is a detailed tutorial here: http://visualgdb.com/tutorials/arm/threads/
6. VisualGDB does not have any special support for profiling. You can use the built-in GCC/GDB features for it.
7. You can use the Visual Studio memory window just like when debugging Windows programs.
8. You can use the VS Registers window to view the CPU registers and the Embedded Registers pane to view the peripheral registers.
9. The problem with serial wire viewer is that ST-Link uses an undocumented protocol and hangs randomly when you try to view the output. Hence OpenOCD and Texane ST-Link tools support it, but it not very useful in practice. You could get a stable SWV output if you use Segger J-Link with Segger software.supportKeymasterHi,
Which system are you targeting? Linux, MinGW/Cygwin or Android? Are you running GDB locally (i.e. using a cross-toolchain) or remotely via SSH?
supportKeymasterHi,
What platform would you prefer? x86 Linux, Raspberry Pi or something different?
supportKeymasterHi,
You can update for free to any version released within a year from your purchase date (we usually count the date of the first beta). Hence you can start using the beta now and simply install the final release over it once it’s out.
Cygwin build of make is the root cause of the problems you are expecting. It expects the paths in the /cygdrive/c/xxx format, while our toolchains are MinGW-based and report paths in the c:/xxx format. To avoid further problems, ensure that your toolchain and your make executable are built for the same platform.
supportKeymasterHi,
We did test this specific patch. Last time we built the Android GDB was around NDK 8 and the build process was fairly straight-forward using a MinGW/MSYS environment. Please feel free to give it a try and if you encounter strange problems, feel free to post here so that we can try to help you.
-
AuthorPosts