Forum Replies Created
-
AuthorPosts
-
support
KeymasterHi,
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.
January 14, 2016 at 00:01 in reply to: VS2010 poco Beaglebone Cross Compile. Build fail Header file not found #7472support
KeymasterHi,
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).
January 13, 2016 at 23:59 in reply to: Unable to debug std::map when cmake is configured with flag -std=c++11 #7471support
KeymasterHi,
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.
January 12, 2016 at 02:54 in reply to: VS2010 poco Beaglebone Cross Compile. Build fail Header file not found #7461support
KeymasterHi,
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.
support
KeymasterHi,
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.
support
KeymasterHi,
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.
January 12, 2016 at 02:45 in reply to: No such thing as "Program and Start Without Debugging" with ESP8266 #7458support
KeymasterWow, 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.
support
KeymasterHi,
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?
January 8, 2016 at 05:35 in reply to: Unable to debug std::map when cmake is configured with flag -std=c++11 #7445support
KeymasterHi,
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.
support
KeymasterHi,
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
support
KeymasterHi,
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.
support
KeymasterHi,
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?
support
KeymasterHi,
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.
support
KeymasterHi,
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.
support
KeymasterHi,
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.
-
AuthorPosts