Forum Replies Created
-
Posts
-
Hi,
Perhaps this is something auto-generated by the compiler? Please try reverting the settings to a point when the code builds successfully, enable the generation of Map files and check the .map file for any references to ‘_udivmoddi4’. It should mention the .o or .a file that contains the function.
Hi,
You can configure VisualGDB to upload that extra directory by adding a custom pre-build step to your project (requires Custom edition or higher). Alternatively you can create a dummy Linux project that will have that directory selected as the main source directory and won’t actually build anything. Then each time Visual Studio tries to build that project, the directory will be uploaded automatically.
Hi,
Are you using a toolchain shipped with VisualGDB? If not, your toolchain may be too old and have no support for these functions.
If yes, please double-check that the <source file name>.gcc.rsp file in the VisualGDB\<configuration> directory contains the -std setting you have selected. If not, please double-check that you have selected it for the correct project configuration.
Hi,
Most likely this happens because your LinuxApp project specifies the absolute path to MySharedLib in its settings. This is by design – absolute include paths are treated as system paths and are automatically cached.
You can override this by adding a custom path mapping in LinuxApp’s VisualGDB Project Properties or by using relative paths in project properties instead.
Please also note that including the library .cpp files from other .cpp files will not refer to the code in the library, but will instead just copy that code to your application. You can read more about C++ headers and sources here: http://www.cplusplus.com/forum/articles/10627/
Hi,
For release configurations – yes. For debug configurations you should replace -O3 with -O0 as optimized code is hard to debug.
Hi,
Yes, that should do. Please upload the files to a file hosting service like dropbox, as our ticket system has an attachment size limit.
Hi,
You definitely need to check in the .vgdbsettings files as they contain VisualGDB-specific settings. If you are using Make, CMake or QMake, you also need to check in the main project file and the configuration files from that build systems.
Hi,
Good to know it works. Could be antivirus software treating sample.xml as a virus, corrupt filesystem or any other cause. If the problem reoccurs, feel free to contact us again.
Hi,
This looks like a bug. The v5.2 uses a different internal mechanism for locating the .vgdbsettings files (using the name from NMake Project Properties for all cases). Perhaps there is a typo somewhere or some special character in the project name is causing trouble? Would you be able to share your .vcxproj and .vgdbsettings files so that we could quickly check what is causing this and fix it?
VisualGDB always tries to check that the toolchain can build valid code when you create a new project. You can simply ignore any errors it discovers and proceed with the project creation if you don’t care about building. We did not change any logic related to this in v5.2. Please feel free to send us the project file (and the .vgdbsettings file) so that we could help you resolve this.
Hi,
Strange. Please double-check that you select the device and sample as shown below:
If the sample does not appear, please check if you have the following file:
%LOCALAPPDATA%\VisualGDB\EmbeddedBSPs\arm-eabi\com.sysprogs.arm.stm32\samples\LEDBlink_STM32F0X\sample.xml
If yes, could you please check if the StdPeriph sample appears for other device families?
Hi,
It looks like the command responsible for the delay is “-stack-list-frames”. This may happen if the algorithm used to discover stack frames does not detect the outermost frame properly and keeps on trying to interpret garbage after the end of stack.
This could be caused by the layout of your program or a bug in gdb, but you can fairly easily limit it by running the following command:
set backtrace limit <number>
where <number> is the maximum number of frames you are interested in. You can start with something like ‘3’ and see if it increases the performance. If this helps, you can add the command to the Additional GDB Commands page in VisualGDB Project Properties.
Hi,
Sending a repro project should be the easiest. Are you using a Windows cross-toolchain or compiling on the Linux side?
In case of a cross-toolchain we will also need the toolchain archive; in case of Linux compilation we will need a snapshot of %LOCALAPPDATA%\RemoteSourceCache\<machine> in order to reproduce this.
Hi,
The error you are encountering most likely means that some other library function is compiled expecting that the functions from _divdi3.o will be placed nearby. Adding -mlongcalls to your compilation won’t help as it will not affect the pre-compiled library code. Basically, you have something like this:
If you want to relocate divdi3(), you also need to relocate func1() and any other functions that call divdi3() or are “connected” by shortcalls in the call graph. We don’t know enough about the structure of the internal ESP8266 libraries to give any definitive answer here, but you can try the following process iteratively:
- Relocate one function
- Build, find out the function causing the problem from the error log
- Relocate the offending function as well
Sorry for the inconvenience, but this is the common case with ESP8266.
Regarding ets_timer() we picked it because it was directly called from the user code and would hence illustrate the process well.
