[support]

Hi,

This happens because CMake projects contain multiple targets, and setting the target_compile_definitions() for one target does not automatically affect others.

You can find the list of targets (executables + static libraries) in Solution Explorer, or by analyzing the target-XXX.json files in the .visualgdb\VisualGDBCache subdirectory.

If you are trying to setup a complex project layout involving multiple targets, we would advise first sketching how many targets it would involve, how they would reference each other, and then setting up the target_compile_definitions() accordingly. If you are new to CMake, we would advise reading about the public/private/interface definitions – it will help you setup everything efficiently.

You can also use our CMake Debugger to step through the CMakeLists files and see how and where various settings are applied.

[support]

Thanks, we have received and reviewed the dump file. The crash happens because Clang considers one of the headers it’s precompiling to contain a typo preventing the normal parsing, and it apparently triggers a “not implemented” condition when trying to produce the precompiled header data.

You can work around it by adding a non-preprocessor statement (e.g. ‘static int unused=0;’) at the beginning of the file to suppress the precompiled header generation. Then you can try moving the statement between the #include<> directives until you find the one that is triggering the issue. Having that include directive after the non-preprocessor statement will prevent Clang from trying to precompile that header file, working around the crash.

[support]

Hi,

Normally VisualGDB should automatically create a dump file containing sufficient information for us to pinpoint the issue. If this doesn’t happen, please try attaching another VS instance to the CppEngineHost64.exe process (make sure you explicitly select the Native mode), wait for the crash to happen and then create a dump file via the Debug->Save Dump command.

You can attach the dump file here, or simply submit it to us via the support interface and we will try to find the root cause of the issue and release a hotfix.

[support]

The target-independent parts of VisualGDB (.Net IL libraries) will indeed work. However, the native parts (x86 and x64-specific) will not. Furthermore, all external tools (e.g. OpenOCD, toolchains) will have to rely on the x86 emulation, making them considerably slower. Driver compatibility could be another big issue.

So, it could be fairly easy to get it to a proof-of-concept level, but getting a reliable development environment that can be used for non-trivial projects could be orders of magnitude more complex, and may still not work out due to lack of support from external tools.

We will watch the user interest in ARM64 and the adoption of the Windows ARM64 platform by the GNU tool ecosystem, and will add support for it when there is enough momentum. If you are serious about using an ARM64 Windows host for development with GNU tools, please consider contributing to the ARM64 MinGW port. It will speed up the ARM64 adoption by the community by making it possible to do native builds of tools like OpenOCD and GCC/GDB. Once these tools are natively supported and start being used by the community, the ARM64 port of VisualGDB will make more sense.

[support]

Thanks for letting us know and good to know it works.

[support]

Hi,

We are aware of that. ARM64 laptops are still very new, relatively rare, and are seldom used as development workstations. Hence, VisualGDB does not support running on the ARM64 Windows builds.

We will continue monitoring the situation and will consider supporting ARM64 development machines if they become more popular among developers.

[support]

Thanks for confirming this and good to know it works. BTW, if you change your build environment in a minor way (e.g. add new libraries to the setup), you don’t need to rebuild the entire toolchain, as long as the gcc version and ABI (e.g. floating point mode) stays the same. Running a “bitbake build-sysroots” and replacing the sysroot directory in the current toolchain should do the trick.

[support]

Thanks, it looks like gdb never reports a successful connection to the J-Link GDB server. Please try running both of them manually:

C:\Program Files\SEGGER\JLink_v780a\JLinkGDBServerCL.exe -select USB -device NUC029LEE -speed 33000 -if SWD -port 50692

and gdb:

C:\Program Files (x86)\Sysprogs\VisualGDB\Keil\arm-none-eabi-gdb.exe “D:\@coding\@bce\ap8557cdma\_AP8557x1.0828t191Bx0821V2(REV)_220118R0_Lib\.project\vgdb\AP8557V2REV\VisualGDB\Debug\AP8557V2REV.elf”
target remote :50692

Does it result in a successful debugging session? If not, please try disabling your firewall/antivirus and using a different port number.

[support]

Hi,

This looks like a corrupt toolchain. Please try deleting it and reinstalling it via the VisualGDB Package Manager.

If it doesn’t help, please try disabling your antivirus. It might be interfering with invocation of some components.

[support]

Thanks for renewing your license.

For RP2040 projects there are 2 different FLASH sizes:

• The FLASH size displayed in the Memory Explorer is taken from %VISUALGDB_DIR%\rules\PicoSDK.xml (search for MemoryMap). It is only used to calculate the utilization percentage and can be changed by editing the rule file.
• The actual memory layout is managed by the PicoSDK build system. VisualGDB does not control it directly and lets the PicoSDK manage it.

If you would like to change the actual memory size used for linking, a good starting point would be the default linker script (try adding “-v” to Ninja arguments, re-link the project and search the build log for “.ld” or “-T”). Once you locate the default linker script, you can patch it to have the memory size you prefer, or fork it and patch the PicoSDK CMake files to use the modified version of the script.

[support]

Please note that OpenOCD is an external open-source tool maintained by the OpenOCD community. When you install it on your Raspberry Pi via VisualGDB GUI, it simply clones the project repository and attempts to build and install it. As it is often the case with open-source projects, it may require some minor fine-tuning and adjustments and it is not something that VisualGDB can do fully automatically.

If you are looking for a fully supported out-of-the-box solution, please consider using Segger J-Link. It comes with its own proprietary replacement to OpenOCD that is well-tested and fully supported. VisualGDB supports both OpenOCD and J-Link equally well, so our users can choose the underlying debugging software that works the best for them.

[support]

Hi,

It looks like gdb manages to connect to J-Link and then disconnects. Please try collecting and analyzing the GDB log as shown here: https://visualgdb.com/support/logsubmit

[support]

Hi,

The script names could slightly vary for different OpenOCD versions or devices. The VisualGDB device/interface script selectors always show the script names from the local machine, so if the remote machine uses different scripts, you would need to find them out and enter the names manually under “advanced settings”.

If you would like to use VisualGDB with OpenOCD that runs on a Linux machine, we would advise first getting it to work manually (i.e. ensure that it works when you launch it via an SSH terminal). If you need help with this, please consider asking on the Raspberry Pi community or in OpenOCD mailing lists, as it is not specific to VisualGDB.

Once you get OpenOCD working, you can manually enter the script names in VisualGDB Project Properties and VisualGDB will handle launching and connecting to OpenOCD automatically.

[support]

Thank you for ordering the custom toolchain build from us. You can download the pre-built installer here. As discussed per email, we are publishing the steps we took to build the toolchain:

1. Go to the existing Yocto environment (configured by var-setup-release.sh) and run the following command: bitbake build-sysroots. It will copy all the files that need to be present in the target’s file system to var-fsl-yocto/build_xwayland/tmp/sysroots/imx8mp-var-dart.
2. Copy the sysroot built in the previous step to <sysgcc>\variscite\cortexa53-crypto-fslc-linux\sysroot.
3. Locate libc.so inside the sysroot directory. It will contain a linker script fragment referencing a library. Update that paths there to use the sysroot-relative form:

   GROUP ( =/lib/libc.so.6 /usr/lib/libc_nonshared.a  AS_NEEDED ( =/lib/ld-linux-aarch64.so.1 ) )

4. Checkout git://git.yoctoproject.org/meta-mingw into var-fsl-yocto/sources/meta-openembedded/meta-mingw and register it in var-fsl-yocto/sources/base/conf/bblayers.conf. Make sure you are using the correct branch. Also create the var-fsl-yocto/sources/poky/meta/conf/machine-sdk/i686-mingw32.conf file with the following contents:

   require conf/machine-sdk/include/mingw32-common.inc

5. Create a separate Yocto environment and run the following commands there (the double assignment SDKMACHINE is required to work around a bug in the scripts):

   SDKMACHINE=i686-mingw32 MACHINE=imx8mp-var-dart DISTRO=fslc-xwayland . var-setup-release.sh build_xwayland
   export SDKMACHINE=i686-mingw32
   bitbake binutils-cross-canadian-aarch64 gcc-cross-canadian-aarch64 binutils-cross-canadian-aarch64 gdb-cross-canadian-aarch64

   Note that unlike STM32MP1, this won’t produce usable MinGW binaries, but it will be a good starting point.

6. Locate the binutils configuration log (build_xwayland/tmp/work/i686-nativesdk-mingw32-w64-mingw32/binutils-cross-canadian-aarch64/2.36.1-r0/git/build.i686-w64-mingw32.aarch64-fslc-linux/config.log) and create another build directory on the same level.
7. Patch the configuration command line so that the sysroot is located in <prefix>/cortexa53-crypto-fslc-linux/sysroot, e.g.:

   --prefix=/usr/local/oe-sdk-hardcoded-buildpath/sysroots/i686-w64-mingw32/usr \
   --with-sysroot=/usr/local/oe-sdk-hardcoded-buildpath/sysroots/i686-w64-mingw32/usr/cortexa53-crypto-fslc-linux/sysroot \

   Then configure/build/install binutils (they will get installed to /usr/local/oe-sdk-hardcoded-buildpath)

8. Locate the config.log for gcc (e.g. build_xwayland/tmp/work/i686-nativesdk-mingw32-w64-mingw32/gcc-cross-canadian-aarch64/10.3.0-r0/gcc-10.3.0/build.i686-w64-mingw32.aarch64-fslc-linux/config.log). Patch the config command line as shown below:
   1. replace /not/exist with /usr/local/oe-sdk-hardcoded-buildpath/sysroots/i686-w64-mingw32/usr/cortexa53-crypto-fslc-linux/sysroot
   2. Remove –with-system-zlib
9. Manually copy gmp/mpfr/mpc into the gcc source directory. Try configuring/building gcc.
10. When the build fails, apply the attached patch to the generated Makefile. Build it again. After it fails to run the cross-gcc, try installing it (“sudo make install”).
11. When it fails with a missing lto-dump.exe, built it manually (cd gcc && make lto-dump.exe). Re-run the install command.
12. Locate the gdb config log (e.g. build_xwayland/tmp/work/i686-nativesdk-mingw32-w64-mingw32/gdb-cross-canadian-aarch64/10.1-r0/build-aarch64-fslc-linux/config.log).
13. Patch the command line as shown below:

    --build=x86_64-linux \
    --host=i686-w64-mingw32 \
    --target=aarch64-fslc-linux \
    --prefix=/usr/local/oe-sdk-hardcoded-buildpath/sysroots/i686-w64-mingw32/usr \
    --with-sysroot=/usr/local/oe-sdk-hardcoded-buildpath/sysroots/i686-w64-mingw32/usr/cortexa53-crypto-fslc-linux/sysroot

14. Configure/build/install gdb.
15. Copy the files to the toolchain directory (see our pre-built toolchain for a sample structure). Double-check that all tools can locate sysroot:

    aarch64-fslc-linux-g++.exe --print-sysroot
    aarch64-fslc-linux-ld.exe --print-sysroot
    aarch64-fslc-linux-gdb.exe
    show sysroot

16. Copy var-fsl-yocto/build_xwayland/tmp/work/cortexa53-crypto-fslc-linux/libgcc-initial/10.3.0-r0/recipe-sysroot-native/usr/lib/aarch64-fslc-linux/gcc/aarch64-fslc-linux/10.3.0 to <sysgcc>\variscite\lib\aarch64-fslc-linux\gcc\aarch64-fslc-linux\10.3.0.

Note that these steps work for the hardknott branch and will likely not work for others (e.g. the Makefile patch works around a bug that is not present in the previous GCC version).

• This reply was modified 2 years, 2 months ago by support.

Attachments:

You must be logged in to view attached files.

[support]

Unfortunately, it is hard to suggest anything specific based on the description you provided.
In order for us to provide any help with this, we need to be able to reproduce the problem on our side.
Please provide complete and detailed steps to reproduce the issue as described below:

1. The steps should begin with launching Visual Studio. They should include every step necessary to create the project from scratch and reproduce the issue.
2. Please make sure the steps do not involve any 3rd-party code as we will not be able to review it. If the problem only happens with a specific project, please make sure you can reproduce it on a clean project created from scratch.
3. The steps should include uncropped screenshots of all wizard pages, VisualGDB Project Properties pages and any other GUI involved in reproducing the problem. This is critical for us to be able to reproduce the problem on our side.

You can read more about the best way to report VisualGDB issues in our problem reporting guidelines, If you do not wish to document the repro steps and save the screenshots, please consider recording a screen video instead and sending us a link to it.

Please note that many VisualGDB issues are caused by selecting an incompatible combination of settings at some point. We are generally not able to review specific projects and find the specific settings that were set incorrectly. We recommend checking the projects into source control and keeping a track of all changed settings to avoid breaking the projects.

We would also kindly ask you to renew your support as it has expired a few months ago.

[Author]

Posts