Tagged: embedded arm toolchain gcc
May 26, 2019 at 17:51 #25014
I decided to install latest arm embedded-GCC Toolchain, the newest ‘8-2018-q4-major’ found now on arm.
( https://developer.arm.com/open-source/gnu-toolchain/gnu-rm )
which contains I found 8.2.1/8.2.50/r4.
according your Tutorial Using VisualGDB with the Official ARM Toolchain
( https://visualgdb.com/tutorials/arm/gnuarm/ )
with ‘Add registry’ selected, and to my personal new path C:\SysGCC\v82018q4
This toolchain is now offered by VisualGDB new Project-Wizard, correct path, and even compiles fine.
When watching the New Project Wizard :
it indicates a crazy old ‘4.9.3/7.8/r1’ version string! Maybe long time ago I had something like that, but 100% sure not in my C:\SysGCC\v82018q4;
Even worse, also the new project files
stm32.xml and *.vcxproj have this bad old ‘4.9.3/7.8/r1’ reference.
But the called gcc compiler (seen in verbose-log!) is absolutely 8.2.1.
After some forum research, I did edit the FindToolchain at:
to reflect the true version ‘8.2.1/8.2.50/r4’,
but the VisualGDB Project-Wizard still insists in showing it as old ‘4.9.3/7.8/r1’.
QUESTION: how does VisualGDB evaluate the version (gcc/gdb/r string) of an installed arm-gcc toolchain?
I would assume this most critical link (is it FindToolchain ?) to third-party must have been documented somewhere,
but no luck.
Thanks for help!
Attachments:You must be logged in to view attached files.May 27, 2019 at 16:34 #25016
Sorry, this is a side effect of the registry-based toolchain discovery. The toolchain should work correctly, however the tool versions shown in the toolchain selector will indeed be incorrect.
As a workaround, please try importing the toolchain manually by clicking “Locate toolchain by finding the gdb executable” in the toolchain selector.May 27, 2019 at 22:48 #25017
Thanks for your answer.
Good hint, but the result (now using your 5.4R5) is only fine for the first part of GCC version (here 8.2.1), but for the GDB part the version is a crippled string:
see attached screenshot.
Even worse, also the files stm32.xml
are affected, putting a high risk of breaking version checking, sooner or later.
I see *GCC.exe has a nice -dumpversion parameter providing just the plain version string like ‘8.2.1’ .
But for *GDB.exe, the –version call print is chatty,
for your built-in toolchain:
GNU gdb (GDB) 8.0.1
latest arm-GCC package:
GNU gdb (GNU Tools for Arm Embedded Processors 8-2018-q4-major) 220.127.116.1181213-git
Thus some smart parsing logic would be required..
Unfortunately, my first plan to manually modify FindToolchain.props seems no solution, as the file later got overwritten by VisualGDB.
Thanks for any help.
Attachments:You must be logged in to view attached files.May 28, 2019 at 02:31 #25019
We are aware of the -dumpversion switch, however the GNUARM toolchain location logic does not utilize it because the version does not affect anything other than the toolchain selector.
You can override the version by manually editing the toolchain.xml file (either in the toolchain folder or under %LOCALAPPDATA%\VisualGDB\ToolchainProfiles after importing the toolchain. All other files containing the toolchain version are generated based on it.May 28, 2019 at 22:47 #25026
Indeed, editing the toolchain.xml and renaming the folder in ToolchainProfiles / localhost did work, correct versions are shown now and applied to projects.
Now, another point was with the newlib-nano not been offered by the New Project wizard, I had to copy some missing parts like
from your official toolchain.xml to my new toolchain.xml (which was generated by VisualGDB using the ‘Locate toolchain’ menu).
But now I think I have a working setup with this latest GCC toolchain.
Thanks for all your support.June 4, 2019 at 22:49 #25058
You must be logged in to reply to this topic.