Forum Replies Created
-
Posts
-
Hi,
There was a bug in our latest Raspberry Pi toolchain. Please re-download the toolchain from http://gnutoolchains.com/raspberry/
Hi,
The binary size explains the delay. You can add a custom post-build step to deploy your binary and disable the automatic deployment in Debug settings. As the build process always runs in the background, this will move the deployment to the background as well.
Regarding “searching for a matching source file”, VisualGDB does that when it’s searching for a .cpp file that includes the .h file being opened. Normally it quickly scans all source files for unconditional include directives and picks the first matching one, however if none of the files include your header file unconditionally, VisualGDB will try fully parsing some of the files to find which of them actually includes the header. Is your header directly included from one of the files? Is the include directive surrounded by #ifdef or #if?
Hi,
Normally you need to edit the linker script and use the “section” attribute to place code and data into a specific memory. You can read more in this topic. If it does not help, please give us an example of what you are trying to do so that we could give a better suggestion.
Hi,
This means that you are missing the reference to the static library (should be called libPoco.a or something similar). Note that if you have just downloaded the sources from Internet, you need to configure and build the library according to the instructions provided by its vendor. This will produce the .a file that you can reference from VisualGDB Project Properties (normally add the directory with the .a files to the Library Directories and add the library name without the ‘lib’ prefix to the Additional Libraries).
Hi,
Qt creator may be explicitly querying the type of each variable or may be using some GDB extension that VisualGDB does not support.
We can investigate this during the v5.2 release cycle, however if you could obtain a full GDB command log from Qt creator (if it supports creating such logs or shows the executed GDB commands somewhere), we may be able to include a fix in the upcoming v5.1 release.
The breakpoint problem does not sound like any known issue, can you reproduce it on a “Hello, world” project and send it to us so that we can see what’s happening? You can also run the “info breakpoints” command in the GDB Session window to find out the address where the breakpoint was put and then use the disassembly window to understand whether this address is correct and actually contains the constructor code.
Hi,
Please right-click on your project in Solution Explorer, select “VisualGDB Project Properties”, go to the Makefile Settings page and add the include directories there.
Let us know if you run into further problems.
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.
