Forum Replies Created
-
Posts
-
Hi,
Yes, we specifically designed the Clang engine to run in a separate process so that any crashes inside clang don’t affect your Visual Studio.
Are you able to reliably reproduce some of the crashes and send us the repro instructions? If it only happens with your project, we can send you a debug build of the engine so that you could create a dump file.
We have easily fixed previous crashes like that, so your crash dumps are more than welcome.
Hi,
Yes, that would work. You can also add a command to the Makefile to copy the built library to a common output directory after it is linked. Let us know if you need a detailed example on that.
Wow, thanks for the detailed description!
We indeed don’t support OTA out-of-the-box, to the instructions you provided should be very useful for the other users looking for it.
We will also consider supporting it directly in one of the next versions.
We’ve also fixed the ‘cancel’ button behavior during the connection attempt in the upcoming VisualGDB 5.1 Preview 2.
Hi,
You can go to the VisualGDB Project Properties, open the Embedded Frameworks page and remove references to HAL or StdPeriph. This will only leave the startup file and the linker script in your project.
We are not aware of any code that calls malloc() during initialization. Can you reproduce this on a “Hello, World” project and send it to us?
Hi,
This is a known limitation. The problem is that for typedef’ed types GDB reports the typedef name instead of the actual type name and resolving each unknown type would have a significant performance impact.
Hi,
Most likely you are either not deploying your library or are using the wrong symbols. Please ensure that the modified version of the library ends up both:
- On your Raspberry Pi
- In the sysroot directory of your toolchain. You can check the exact path by running the “info shared” command in the GDB Session window
Hi,
Unfortunately there is no easy or practical way to do that. If the APK vendor has not provided the sources/symbols, you cannot simply reconstruct them from the app.
Hi,
Normally launching the debugger should be fairly fast, so VisualGDB does it in the foreground. Do you have an idea why is it taking 10 seconds each time? Are you deploying large binaries? Do you experience the same delays with a “Hello, World” project?
Hi,
You can change the output directory on the Makefile Settings page of VisualGDB Project Properties. However, if you have several projects in the same directory, you would need to change the Makefile names for them (same page of properties) to ensure that they are using different Makefiles and their settings are stored separately.
Hi,
Please check your link command line in the build output. Does it include the ftk.o file twice? If yes, please ensure that you don’t have two different ftk.c files in your project.
Hi,
Unfortunately that won’t work because the Play Store apps contain release versions of the libraries that simply don’t have debug symbols required for debugging. So even if you manually set the ‘debuggable’ attribute and copy gdbserver, you won’t be able to get any meaningful debugging experience.
Hi,
Last time we checked the PIC32 devices were not very popular and the popularity was declining. So unless this trend changes, we won’t be supporting them directly.
You are welcome to try creating a project manually by following our legacy device tutorial and feel free to ask questions if anything breaks or becomes unclear.
Hi,
Please try manually locating the source file that contains the main() function. Is it located under the source directory you are importing?
Hi,
It’s usually displayed via Help->About VisualGDB. If you want to upgrade, simply email sales@sysprogs.com and we’ll give you a quote.
