Issues after update

[GeneM]

I have a VGDB C++ CMake project I’ve been working on.  Everything worked fine yesterday.  This evening when I opened VGDB it wanted to update a lot of modules.  I went ahead with the update.  It mostly worked the first time through but it had problems finding a STM module (I didn’t catch the name).  I restarted VGDB, it found the missing STM module and loaded it the second time.  VGDB still couldn’t find some system files like stddef.h but it is really good about notifying me and I was able to manually point it at the right folder.  Everything builds and compiles except

1. the  fast semi-hosting output that I generate with std::cout << …  that used to come up nicely in the ARM Semihosting Console now looks like this

]k�’P]k�’!�]k�’!�!]k�’!�Q]k�’!�]k�’!�!�Q]k�’!]k�’!�!�5�basic_ios::clearSt9basic_iosIcSt11char_traitsIcEE�U�St9]]k�’P

and 2. I’m getting red squiggly error lines under my uintXX_t stdint declarations.  I don’t remember getting these before the update.

To be clear, everything builds and runs and variables that are supposed to print out in the Semihosting Console do show up correctly in the Watch window.  I’m pretty sure there is a log file somewhere that shows what happened during the update but I haven’t been able to find it.  If you point me at the right place, I can pass it along.

Thanks

 

 

• This topic was modified 9 months, 2 weeks ago by GeneM.

[support]

Hi,

Most likely, you ended up updating some of the components (e.g. BSP or some libraries to versions  that  are not 100% backward-compatible, and  then tried to troubleshoot it by changing some setting that ended up breaking the project.

Unfortunately, the issues you are describing do not look like a known issue, so our best advice would be to revert everything to the latest version that worked.

If you can point a specific setting or update that breaks the project, we can gladly investigate it further.

[bjornharink]

I have the same issue after updating ARM toolchain (GCC 12.2.1; GDB 12.12). Compiles ok, but VisualGDB missing headers tool complains can’t find stddef.h

 

[support]

Hi,

Could you please let us know the build subsystem you are using? Is it GNU Make, CMake or MSBuild?

[bjornharink]

stddef.h issue is on CMake. I’m using VisualGDB 5.6R9 (build 4777).

On MSBuild I get a  lot of errors too I did not see before the update:

c:/sysgcc/arm-eabi/bin/../lib/gcc/arm-none-eabi/12.2.1/../../../../arm-none-eabi/bin/ld.exe: c:/sysgcc/arm-eabi/bin/../lib/gcc/arm-none-eabi/12.2.1/thumb/v7e-m+fp/hard\libc_nano.a(libc_a-fstatr.o): in function`_fstat_r':
fstatr.c:(.text._fstat_r+0xe): warning: _fstat is not implemented and will always fail
c:/sysgcc/arm-eabi/bin/../lib/gcc/arm-none-eabi/12.2.1/../../../../arm-none-eabi/bin/ld.exe: c:/sysgcc/arm-eabi/bin/../lib/gcc/arm-none-eabi/12.2.1/thumb/v7e-m+fp/hard\libc_nano.a(libc_a-signalr.o): in function `_getpid_r':
signalr.c:(.text._getpid_r+0x0): warning: _getpid is not implemented and will always fail
c:/sysgcc/arm-eabi/bin/../lib/gcc/arm-none-eabi/12.2.1/../../../../arm-none-eabi/bin/ld.exe: c:/sysgcc/arm-eabi/bin/../lib/gcc/arm-none-eabi/12.2.1/thumb/v7e-m+fp/hard\libc_nano.a(libc_a-isattyr.o): in function `_isatty_r':
isattyr.c:(.text._isatty_r+0xc): warning: _isatty is not implemented and will always fail
c:/sysgcc/arm-eabi/bin/../lib/gcc/arm-none-eabi/12.2.1/../../../../arm-none-eabi/bin/ld.exe: c:/sysgcc/arm-eabi/bin/../lib/gcc/arm-none-eabi/12.2.1/thumb/v7e-m+fp/hard\libc_nano.a(libc_a-signalr.o): in function `_kill_r':
signalr.c:(.text._kill_r+0xe): warning: _kill is not implemented and will always fail
c:/sysgcc/arm-eabi/bin/../lib/gcc/arm-none-eabi/12.2.1/../../../../arm-none-eabi/bin/ld.exe: warning: VisualGDB/Release/2007-FAUVE-MBR-Firmware has a LOAD segment with RWX permissions

And whole bunch of:

: warning: ISO C99 requires whitespace after the macro name

Visual Studio Community 2022 (17.6.5)

• This reply was modified 9 months, 1 week ago by bjornharink.
• This reply was modified 9 months, 1 week ago by support. Reason: formatting
• This reply was modified 9 months, 1 week ago by bjornharink.
• This reply was modified 9 months, 1 week ago by bjornharink.
• This reply was modified 9 months, 1 week ago by bjornharink.
• This reply was modified 9 months, 1 week ago by bjornharink.
• This reply was modified 9 months, 1 week ago by support. Reason: merged with the clarification post

[support]

Thanks, we have rechecked stddef.h on Advanced CMake, but it looked just fine. Could you please attach a screenshot of the entire Visual Studio window, showing the error and the Solution Explorer window as well?

Regarding the “not implemented” warnings, it appears to be a feature of the new toolchain to warn you about these functions, however it does not indicate any actual error. We have updated our documentation here, explaining what causes it, and known workarounds.

[GeneM]

Unfortunately, I’m still have problems.  When I opened VGDB today, it wanted to update a few modules.  Based on the activity in this thread, this seemed like a good idea.  It found, downloaded and installed all the new modules and I was working for a while. Then I closed VGBD and reopened it later in the day working on the same project. It told me it couldn’t find the STM32 Devices Module 2023.08 and asked if I wanted to use 2023.07.  I thought when I was watching the update, it did install 2023.08.  When I look at my “Manage VisualGDB Packages” menu it does seem to say I only have 2023.07 installed.  But it does show I have 2 copies of STM32 Devices.  I’ve tried downloading a fresh copy of VGDB but still wound up with 2 copies of 2023.07 (see attached screen shot). If I should have 2023.08, how do I download it? And should I delete one of the 2 copies of STM32 Devices?

An unrelated question: I’d like to download an earlier version of VGDB to see if my red squiggly error line (see my original post) goes away.  But the next latest version on your downloads page is dated 2021-03-05.  Is that the most recent version before the current latest version?

One piece of good news is the junk characters I was seeing in my ARM Semihosting Console seems to have resolved itself.  I cleaned up some recent code and the problem went away.  I was probably overwriting an array or buffer somewhere that was stepping on the semihosting memory.

Attachments:

You must be logged in to view attached files.

[bjornharink]

Not sure this helps.

• This reply was modified 9 months, 1 week ago by bjornharink.

Attachments:

You must be logged in to view attached files.

[GeneM]

I’m not sure what’s happening here.  Is the attachment in your post supposed to be what you get when you open the attachment in my last post?  When I look at my last post, I can see a thumbnail of the attachment and the thumbnail looks right.  When I click on the thumbnail, I get a full size image and it’s right also.  But the thumbnail and the full size image in your post are both different than mine.  I’ve attached what should be the correct image again to this post.

Attachments:

You must be logged in to view attached files.

[support]

Hi,

@GeneM, it is hard to say why you would end up with 2 copies of the same BSP. VisualGDB has a mechanism for relocating the BSPs, leaving links to the new location behind, so it could be that you somehow triggered that one. Either way, the best way to get a clean BSP would be to close VS, delete %LOCALAPPDATA%\VisualGDB\EmbeddedBSPs\arm-eabi\com.sysprogs.arm.stm32, and install the BSP again.

As for the old VisualGDB versions, you can download them here: https://visualgdb.com/download/oldversions

@bjornharink, thanks for the screenshot. It looks like you are using the Advanced CMake subsystem (that is the recommended way) that uses the toolchain path to cache toolchain-specific directories. If you installed the new toolchain in the same directory, it would indeed try to use old cached paths. The workaround is very straight-forward: just delete the <project directory>\.visualgdb subdirectory and reopen the solution. We have also fixed it on our side, so VisualGDB will now check both the toolchain version and the toolchain directory when deciding whether to reuse the cache.

[We]

We encountered almost the same problem a few months ago, solved by cleaning all local cache directories like .vs .visualgdb.

[Author]

Posts