- This topic has 11 replies, 2 voices, and was last updated 10 years, 2 months ago by
.
-
Posts
-
Hi!
As a background, we used to use IAR compilers for ARM development, but first usually simulate as much as possible using native VisualStudio builds from the same sources. Of course, the ability to stay within the same IDE for all Windows, Linux and bare metal development is great, so I’ve started VisualGDB evaluation and the first impression was “WOW!”
But later I met few issues and want to talk to you about them before we can consider any purchases. Please treat thoughts below not like bug reports but questions to be discussed. I’d like to know what you think about that. I will keep updated this thread since don’t remember all issues right now. The issue order is not intentional. I understand that some questions (like registers view) was answered here, but want to keep all my issues in one place,
Most of issues (or maybe even all) are for GUI and configuration.
1. I was interested in bare metal build for LPC ARM CPU. First I tried the “Embedded” project and used suggested arm-eabi toolchain. The supplied stdlib.a was huge for C++ project (code size from 30k grown to 90), so I decided to switch to latest ARM-supported toolchain from launchpad.com for their nano lib. But I found that I CANNOT change toolchain at all after initial project creation, the option is greyed. WHY? If I can have few lately installed gcc-compatible toolchains? Of course, I edited makefiles, but VisualGDB overwrote them… Not good.
2. Ok, I recreated a new “Custom” project and added there existing makefiles. Now I was able to change toolchains. All worked fine for build until I decided to test J-Link debugging. Oops! There is no option for J-Link debugger, just GDB. Why? Sure, I can probably use SEGGER GDB server, and choose “Custom GDB stuff” here. But it is not the same as just select “J-Link”. To my mind, the “Custom” project should be able do anything I want, including all possible options for Embedded project, for instance. But this is somehow limited for unknown reason. Moreover, I’d like to be able to switch from “Embedded” project to “Custom” keeping all config but unlocking changes. This would be the best solution.
3. Would be great to be able do NOT use BSP for particular CPU (even for “Embedded” project). For example, we use full CMSIS + startup file in our project. But after adding one to original “Embedded” project I was not able to remove the auto-added BSP references. From time to time it was added to directories in makefiles after I removed it.
4. Hardware registers display. Found here http://visualgdb.com/tutorials/arm/stm32/uart/ a hardware registers display. Did not remember it for ARM CPU (isn’t it still not implemened?). Can I add a description for ARM by hand not usin any supplied BSP (see above why)?
5. Serious problem with development machine change. I pushed to a repository my test project at home and pulled it at work. Attempt to build failed with “no such toolchain”. Ok, I tried to open the config window, but wasn’t able to change anything – VisualGDB showed me error about missing toolchain and closed the window (VS 2010). Actually, the problem was much worse. Attempt to change toolchain for “Embedded” project (see above) using direct XML edit resulted in a blank configuration window with error message. Actually in that case there is no way to recover the project: the toolchain config/reference/GUID is not in makefiles but in VisualGDB XML, which is undocumented. I found few cases where some inconsistency in config (usually after machine switch or manual edit) resulted in blank page with no configuration at all. It probably was not destroyed, but still was inaccessible.
All issues above are show stoppers for us to consider buying this, otherwise great tool. Maybe I don’t know how to setup an Embedded project with fully customizable settings (including BSP/No BSP, toolchain changes, etc) without overwriting it and being able to use any debugging options like GDB or J-Link? Please suggest what is the best solution to try.
Other toolchain support. As I said, we use IAR. It could be a war about “what is better, IAR or GCC”, but if you have few IAR-based projects, you want to keep the code. I was able to update Makefiles so I can use VisualGDB power in keeping sources in sync and use native IAR compilers. But also there were few issues:
6. Next/Prev error stepping. I’ve read a message on the forum about adding an XML file to parse compiler output. And it actually works for IAR after change. But regexes there I guess can only parse one line at a time. IAR generates messages with file name, line number and error number on one line, and uses next line for error description. I think I can’t parse such messages with such XML template, can I?
7. This option for parsing MUST be at least on a project (or toolchain) level, not to be put into global installation directory. I can have a solution with 3 projects, one of which is VS native, another is Linux and other one is bare metal. And I may want to use default parsing for Linux and IAR parser for embedded. So adding a global XML is not a solution.
8. Did you consider using make templates for generating rules on the fly? They are much more flexible (if you need to support some non-standard features) and at the same time the user still doesn’t have to deal with them if he doesn’t want. At the moment you use static patterns for rules and worse, you update them frequently (so no option for manual edit). And even worse, you generate them only for sources with some extra path, using defaults above for remaining files. I replaced static autogenerated rules with templates, but VisualGDB recreated some rules again, so I had duplicating rules. I guess I cannot disable the rules autogeneration but still have the source list updated from VisualStudio? Assuming that you use GNU make, I would highly recommend using templates for that, so you don’t have to generate ANY rules at all – all can be built dynamically during make run. I use such in my projects so don’t have to worry about updating static rules for every source file.
Minor issues:
9. Trying to remove toolchain from the Embedded tools manager results in deleting all toolchain files. This is also the case when toolchain was “imported” from existing directory. Not OK since I may want to remove just the reference, and before removing any user data you should at least ask if I want to remove toolchain files on drive as well.
10. If I set “Exclude from build” VS mark on some files, VisualGDB ignores that. I can filter out them, but it should be reused from VS, right?
11. Intellisense. There are few issues, but I’ve read that you’ve been working on own engine. Great, because one issue for me was that using VS, it defines _MSC_VER which is NOT actually defined for ARM project, but which IS used by IntelliSense. And the code is highlighted incorrectly (when we use the same source for emulated PC project and the ARM one).
12. As already said on forum, Rebuild a project fails if there was no previous build. But it should ignore the failure (maybe by adding – option to make rule).
Enough for now. Please suggest me at least how to get rid of show stoppers: I need an embedded but fully customizable project with ability to remove BSP, change toolchain, change development machine without “no such toolchain” issues and hardware debugging using all options (with J-Link for this case) with hardware registers view (the only thing I need from BSP for some of projects).
Hi,
First of all, thank you for the detailed feedback. The possibility to use a custom toolchain was designed as a fallback scenario, so it indeed may be quite cumbersome. Based on your inputs we should be able to improve it in the next release. As a temporary workaround, you can manually configure it using the instructions below.
1. VisualGDB is very conservative about changing toolchains because accidentally using a wrong toolchain (e.g. the one with an older version of GCC or mixing the toolchains that have hardfp/softfp enabled by default) can cause VERY hard-to-diagnose problems. GDB simply crashing at random times could be the least of the problems. Hence the normal GUI does not allow changing it. Now if you’re familiar with all the pitfalls and are willing to experiment with the toolchains at your own risk, you can easily configure VisualGDB to recognize them.VisualGDB identifies toolchains by a toolchain ID (unique for the specific toolchain build) and the GNU target ID (e.g. arm-eabi). BSPs and debug methods are bound to a specific GNU target ID. Once a project is created, it is bound to a specific toolchain ID. Once you import a custom toolchain, VisualGDB will generate a unique ID for it and save it under HKCUSoftwareSysprogsVisualGDBThirdPartyToolchains. The toolchain summary will be saved to the toolchain.xml file inside the toolchain folder. The project will refer to the toolchain by its ID (the .vgdbsettings file points to an embedded profile file that in turn contains the toolchain ID).
If you want to switch a project to a new toolchain, please do the following:
a. Replace the generated toolchain GUID in toolchain.xml with a more human-readable ID
b. Edit the embedded profile file (e.g. lpc.xml or mcu.xml in the project directory) to refer to a new ToolchainID.
c. Open VisualGDB Project Properties and change the CPU type to something else and back. VisualGDB will regenerate all settings files to use the new toolchain.Please ensure to rebuild your project after you do that. Also ensure you don’t mix code built with different toolchains.
2. The segger J-Link will only appear for the arm-eabi toolchains. If your toolchain uses a different ID (e.g. arm-none-abi or arm-elf), please edit its toolchain.xml to have
arm-eabi . You can specify the GNU target ID when you are importing the toolchain.3. If you don’t need the BSP, you can simply create a custom project. The only thing that you’ll need to specify manually is the linker script. Let us know if this is too inconvenient.
4. We have added the NXP LPC support fairly recently and don’t provide the hardware register layout yet. As a workaround you can generate a description file yourself. The easiest way to do this is to create an STM32 project and look into the stm32.xml file. If will contain a reference to a MCUDefinitionFile (in %LOCALAPPDATA%VisualGDBEmbeddedBSPsarm-eabicom.sysprogs.arm.stm32). You can use that file as a template for generating one for your MCU. Once you generated it, simply add a reference to it in the embedded profile file. Let us know if you need a C# sample for generating the definition files.
5. Yes, VisualGDB uses toolchain IDs (that are stored intoolchain.xml and referred to from .xml). Please ensure that the ID is the same on all machines. 6. We could add support for combining error message information from different lines, but that would cause confusion with multi-thread builds when several compiler instances are producing output. Would making a basic wrapper (e.g. using PERL) around the IAR compiler that will simply concatenate those lines be a viable solution for you instead?
7. We made it a global XML setting in assumption that the regex alternative syntax allows extending the GCC rules so that they will work for both GCC and the other compiler. If that does not work for you, we can add a per-project option as well.
8. We use the generated rules for sources with extra path because we could not find a reasonable way to make generic templates for those (given that the .o files go to the debug/release directories and don’t stay with the source files). If you have an idea how to achieve it efficiently, feel free to share it with us. Note that we generate the rules based on the templates at the end of the Makefile however, so editing the templates and then changing the source list will propagate your changes to all rules.
9. Thanks for letting us know, we will fix this in the next release.
10. We currently only support file exclusion for Android projects. In the long term we are planning to replace GNU Make with MSBuild-based building (like in vs-android). In the short term we recommend using the filter-out statements as a workaround.
11. Yes, the new engine is based on clang and won’t have that issue. As a workaround you can replace #ifdef _MSC_VER with something like #ifdef WINDOWS_BUILD and define WINDOWS_BUILD inside #if defined(_MSC_VER) & !defined(__GNUC__). As VisualGDB defines __GNUC__ via gcc_.h, this will allow distinguishing between the real Windows build and VisualGDB. This is in our planned fix list, however as the workaround is fairly simple, the priority for it is relatively low. Let us know if it is too annoying.
First, thank you for fast and very useful info. I definitely will try something next days.
1… The possibility to use a custom toolchain was designed as a fallback scenario,
Actually, I didn’t have any problem yet replacing supplied arm-eabi by another arm-none-eabi apart from toolchain verification (sometimes it reports errors which don’t exist using supplied linker script which, of course, isn’t used during verification). But I can’t say about other (non-ARM in general) toolchains.
Actually, I like systems where I can change all behavior at least using manual editing and wrappers. While it is a one time action, it should be quite fine for an advanced developer. Still, you can (should?) screen extra details from unexperienced users who used to work with GUI only. In that regard I value your input on customization by hand, keeping default wizards and UI clean and easy.
2… The segger J-Link will only appear for the arm-eabi toolchains
Is it ok if I have few toolchains with the same arm-eabi ID but different unique GUIDs? Actually, I’ve already seen such in the toolchain list, so it should be possible. But maybe you could relax this requiring just “arm”, not a full string match to “arm-eabi”? Anyway, OpenOCD is another example, it should work for other targets, so the debug method selection should be possible at least for custom projects, I believe.
3… If you don’t need the BSP, you can simply create a custom project. The only thing that you’ll need to specify manually is the linker script. Let us know if this is too inconvenient.
Actually, that is what I’ve done – I used custom linker script. But the issue with custom project was the absense of J-Link. If the solution above helps, it should be quite fine. I will try. I can’t say is that “convenient” for a majority of VisualGDB users, but for embedded developer or any GNU tools user with average skills it should be easy and acceptable.
Oh yes, another issue with Custom project was the absense of memory stats in the end of build. It was useful feature and should work for any GNU toolchain. I replaced it with postbuild size output, but it is not exactly the same. So I would like to be able to enable it with possible options of selecting the target binary – we need to know it anyway – and an option of how to display (in Kbytes or bytes).
4… We have added the NXP LPC support fairly recently and don’t provide the hardware register layout yet. As a workaround you can generate a description file yourself.
That’s exactly what I did yesterday: using STM32 BSP, I created a custom XML with some GPIO registers and had HR display. But I had to specifiy full path to the XML in local toolchain XML. Can relative (ProjectDir-based) path be used? I tried to, but had not succeeded.
Yes, I am interested to have some tools to generate such definitions if you have and can share.
5… Please ensure that the ID is the same on all machines.
I should try that. But there are two issues or suggestions:
– maybe makes sense to use some kind of toolchain info to generated otherwise random IDs? Maybe, say, use hash of gcc version info, or so? I think it is not unusual thing when some developers share the same toolchain on their machines. So the same ID could help them to eliminate the need for manual edits.
– another point was that in cases where VisualGDB has some issues, it does not allow user to fix it via GUI. It just reports error and either closes the dialog or shows blank pages. That could be refined somehow, I think.6. We could add support for combining error message information from different lines, but that would cause confusion with multi-thread builds when several compiler instances are producing output. Would making a basic wrapper (e.g. using PERL) around the IAR compiler that will simply concatenate those lines be a viable solution for you instead?
More than acceptable solution. Actually it may solve any issues with multi-threaded builds, multi-line outputs, etc. Simple regex does not allow it, but a wrapper does. But probably it should be not a wrapper around compiler but optional output filter used to preprocess the compiler output? If no such filter, the output is internally processed as is.
7. We made it a global XML setting in assumption that the regex alternative syntax allows extending the GCC rules so that they will work for both GCC and the other compiler. If that does not work for you, we can add a per-project option as well.
I didn’t think about that, assuming that it was “either internal or external” XML. I should try if both works. But I think that the output filter described above could be more flexible solution. That was the way used yet in old Borland DOS compilers, so it should work here either.
8. We use the generated rules for sources with extra path because we could not find a reasonable way to make generic templates for those (given that the .o files go to the debug/release directories and don’t stay with the source files). If you have an idea how to achieve it efficiently, feel free to share it with us. Note that we generate the rules based on the templates at the end of the Makefile however, so editing the templates and then changing the source list will propagate your changes to all rules.
Yes, I understand what and why. And yes, I have a good solution which uses the power of GNU make which allows to make all of that on-the-fly using gmake templates. In short, if I have a single list of source files with paths and extensions, I generate lists of different types (for different compilers/assemblers) using filter rules. Then I use another rule to create a list of all objects (in binary dir). Finally, for every source I call a corresponding make template which generates all rules on the fly. This is a very flexible solution and I can share more details on it with samples. It does not require any static rules at all, you only update the source list with any paths. And you can modify templates for extra options if necessary – they replace static dependencies.
This has just one limitation: you should use GNU make to support that. It should not be a real problem, actually. But since you have an option in Makefile “update or not update” sources list automatically, I think you should at least have another option to not (re)create static rules. If developers like me use templates, they don’t need static rules at all. I will show you samples later. The same approach should work: if no a special “mark” comment in Makefile – do not alter rules below templates (and they can be replaced by make templates if desired).
10… In the long term we are planning to replace GNU Make with MSBuild-based building (like in vs-android).
This really concerns me. While it looks like natuaral solution for VS, it would create a lot of unnecessary stress for many developers. GNU make is very powerful, and there are lots of ready to use makefiles. So if MSBuild could be an option, it should not replace make completely, I strongly believe. Anyway, how would you like to run builds on remote Linux machines? This is one of strong features I like. Do you want to reinterpret rules locally using MSBuild and run compilation remotely file by file? Oh no, not that!
11. Yes, the new engine is based on clang and won’t have that issue. As a workaround you can replace #ifdef _MSC_VER with something like #ifdef WINDOWS_BUILD…
Sure it is possible. But still there are some minor issues. Let me don’t elaborate them now, I can add more info later if it will be too annoying. Right now I have just two machines (at home and work). I think most of issues may arise if our team switches to VisualGDB. But at the moment it is a bit risky to drop support for legacy environment while we still don’t have licenses for VisualGDB.
And, BTW, new question:
13. Do you provide floating licenses? The issue is that I have 3 machines to work on: home laptop, work desktop and sometimes virtual machine used remotely. Many software vendors use the “book alike” approach: “you can use the software on any number of computers but just on a sinle one at a time”. As far as I understand, your licensing is node-locked. What about floating licenses? It should be ok for me to acquare a license via home-to-work VPN (for home machine) or like that. But I hardly can buy 3 licenses for single user use when I use only one machine at a time. Especially since I am interested in at least Custom version (all below do not fit for my purposes).
8. We use the generated rules for sources with extra path because we could not find a reasonable way to make generic templates for those (given that the .o files go to the debug/release directories and don’t stay with the source files). If you have an idea how to achieve it efficiently, feel free to share it with us. Note that we generate the rules based on the templates at the end of the Makefile however, so editing the templates and then changing the source list will propagate your changes to all rules.
Here is a sample template-based example. It is very simplified, does not contain all dependencies and does not include a lot of nice things like optional kernel-style pretty printing of compilation:
CXX main.cpp CXX cpp-source.cxx CC subdir/c-source.c AS common/asm-source.s LD obj/target.elfinstead of
/some/path/to/toolchain/bin/g++ --common-flags --c++-only-flag main.cpp -o obj/main.o /some/path/to/toolchain/bin/g++ --common-flags --c++-only-flag cpp-source.cxx -o obj/cpp-source.o /some/path/to/toolchain/bin/cc --common-flags --c-only-flag subdir/c-source.c -o obj/c-source.o /some/path/to/toolchain/bin/as --common-flags --asm-only-flag subdir/../common/asm-source.s -o obj/asm-source.o /some/path/to/toolchain/bin/ld -o obj/target.elf obj/main.o obj/cpp-source.o obj/c-source.o obj/asm-source.oBut it shows the basic use of templates (full example attached).
# # Example makefile using GNU make templates for source list management # TARGETNAME := target.elf BINARYDIR := obj # Flags COMMONFLAGS += --common-flags ASFLAGS += --asm-only-flag CFLAGS += --c-only-flag CXXFLAGS += --c++-only-flag # Commands export ECHO := echo # Add any number of source files with different paths and extensions SOURCEFILES := main.cpp cpp-source.cxx subdir/c-source.c ./subdir/../common/asm-source.s # Create lists of files by type ASRC = $(filter %.s %.S, $(SOURCEFILES)) SRC = $(filter %.c, $(SOURCEFILES)) CPPSRC = $(filter %.cpp %.cc %.cxx, $(SOURCEFILES)) all_make_files := $(firstword $(MAKEFILE_LIST)) # Simplified dependencies PRIMARY_OUTPUTS := $(BINARYDIR)/$(TARGETNAME) all: $(PRIMARY_OUTPUTS) all_objs = $(addprefix $(BINARYDIR)/, $(addsuffix .o, $(basename $(notdir $(SOURCEFILES))))) $(BINARYDIR)/$(TARGETNAME): $(all_objs) @$(ECHO) $(LD) -o $@ $(LDFLAGS) $(START_GROUP) $(all_objs) $(LIBRARY_LDFLAGS) $(END_GROUP) # $(LD) -o $@ $(LDFLAGS) $(START_GROUP) $(all_objs) $(LIBRARY_LDFLAGS) $(END_GROUP) $(BINARYDIR): mkdir $(BINARYDIR) # TEMPLATE-BASED DYNAMIC RULES - BEGIN # Assemble: create object files from assembler source files. define ASSEMBLE_TEMPLATE $(BINARYDIR)/$(notdir $(basename $(1))).o : $(1) $(all_make_files) |$(BINARYDIR) @$(ECHO) $(AS) $$(COMMONFLAGS) $$(ASFLAGS) $$< -o $$@ # $(AS) $$(COMMONFLAGS) $$(ASFLAGS) $$< -o $$@ endef # Compile: create object files from C source files. define COMPILE_C_TEMPLATE $(BINARYDIR)/$(notdir $(basename $(1))).o : $(1) $(all_make_files) |$(BINARYDIR) @$(ECHO) $(CC) $$(COMMONFLAGS) $$(CFLAGS) $$< -o $$@ # $(CC) $$(COMMONFLAGS) $$(CFLAGS) $$< -o $$@ endef # Compile: create object files from C++ source files. define COMPILE_CPP_TEMPLATE $(BINARYDIR)/$(notdir $(basename $(1))).o : $(1) $(all_make_files) |$(BINARYDIR) @$(ECHO) $(CXX) $$(COMMONFLAGS) $$(CXXFLAGS) $$< -o $$@ # $(CXX) $$(COMMONFLAGS) $$(CXXFLAGS) $$< -o $$@ endef # Generate rules on the fly using templates # Assemble: create object files from assembler source files. $(foreach src, $(ASRC), $(eval $(call ASSEMBLE_TEMPLATE, $(src)))) # Compile: create object files from C source files. $(foreach src, $(SRC), $(eval $(call COMPILE_C_TEMPLATE, $(src)))) # Compile: create object files from C++ source files. $(foreach src, $(CPPSRC), $(eval $(call COMPILE_CPP_TEMPLATE, $(src)))) # TEMPLATE-BASED DYNAMIC RULES - END # Some info $(info Sources: $(SOURCEFILES)) $(info Objects: $(all_objs)) $(info ASRC=$(ASRC)) $(info SRC=$(SRC)) $(info CPPSRC=$(CPPSRC))The main idea is that we have a single list of $(SOURCEFILES), used to generate the lists of files by type (to pass to different compilers) $(ASRC), $(SRC), $(CPPSRC), which can be also modified by hand, and the list of objects in the $(BINARYDIR) with stripped source paths and extensions but added output dir and .o suffixes. Then we define 3 templates for asm, c and c++ sources accordingly. The main magic is done by $(foreach) functions which generate rules on the fly using supplied source lists. For each source the template is called to return a rule with correct paths: $(BINARYDIR) for .o and original full path for the source file. These rules then evaluated by make ($(eval)) as normal rules, including other dependencies, using deferred evaluation (notice the double $$ in some variables of templates).
The output of make run is:
Sources: main.cpp cpp-source.cxx subdir/c-source.c ./subdir/../common/asm-source.s Objects: obj/main.o obj/cpp-source.o obj/c-source.o obj/asm-source.o ASRC=./subdir/../common/asm-source.s SRC=subdir/c-source.c CPPSRC=main.cpp cpp-source.cxx g++ --common-flags --c++-only-flag main.cpp -o obj/main.o g++ --common-flags --c++-only-flag cpp-source.cxx -o obj/cpp-source.o cc --common-flags --c-only-flag subdir/c-source.c -o obj/c-source.o as --common-flags --asm-only-flag subdir/../common/asm-source.s -o obj/asm-source.o ld -o obj/target.elf obj/main.o obj/cpp-source.o obj/c-source.o obj/asm-source.oHere make first prints some info for you during Makefile processing, and then make runs rules with echo to show you how it creates the "all" target.
You can play with it adding any number of source files with any directories into $(SOURCEFILES), and they will be processed without extra Makefile changes. If some source is missing, you will get normal make error:
g++ --common-flags --c++-only-flag main.cpp -o obj/main.o g++ --common-flags --c++-only-flag cpp-source.cxx -o obj/cpp-source.o cc --common-flags --c-only-flag subdir/c-source.c -o obj/c-source.o make: *** No rule to make target `subdir/../common/asm-source.s', needed by `obj/asm-source.o'. Stop.If the approach is interesting for you, I can try to help with more real templates. But for now to be able to use this I need at least the ability to tell VisualGDB don't generate static rules. Then I will replace default Makefile with mine.
PS. I see you have makefile templates in the code. Can internal templates be replaced by adding some files to the VisualGDB? I'd like to use my templates instead of default ones, and would be good to do that once, not every time it generates a new project.
[attachment=0:2sgc9vdx]templates.zip[/attachment:2sgc9vdx]
EDIT: here is how it works now for my newest template version:
1>Build started 06.08.2014 15:39:39.
1>Build:
1> VisualGDB: Attempting inline build...
1> VisualGDB: Run "cmd.exe /c "C:Program FilesSysprogsVisualGDBmake.exe" CONFIG=Debug" in directory "D:WorkprojectXvortexworkabmstdstdc" on (unspecified)
1> CC common/LPC1700CMSIS/CoreSupport/core_cm3.c
1> CC common/LPC1700CMSIS/DeviceSupport/system_LPC17xx.c
...
1> CXX common/memalloc.cpp
1> CXX common/msgs.cpp
...
1> CXX common/wdt.cpp
1> CXX std/stdc/main.cpp
1> CXX std/stdc/prgversion.cpp
1> CXX std/stdc/stdafx.cpp
1> CXX std/stdc/stdcmngr.cpp
1> CXX std/stdc/stdcmngrrf.cpp
1> LD std/stdc/Debug.arm-eabi/stdc-arm-eabi.elf
1> BIN/HEX std/stdc/Debug.arm-eabi/stdc-arm-eabi.bin
1> BIN/HEX std/stdc/Debug.arm-eabi/stdc-arm-eabi.ihex
1> VisualGDB: Executing postbuild actions
1> VisualGDB: Run "C:Appstoolchainsgcc-arm-none-eabi-4_8-2014q2-20140609binarm-none-eabi-size.exe stdc-arm-eabi.elf" in directory "D:WorkprojectXvortexworkabmstdstdc/Debug.arm-eabi" on local computer
1> text data bss dec hex filename
1> 31988 216 6748 38952 9828 stdc-arm-eabi.elf
1>
1>Build succeeded.
Errors are still shown as always, and navigation works. Absolute paths are stripped for pretty printing but used internally by make. The root of source in this example is 2 levels up from the project (for pretty printing of relative paths in ../../common/). By default it would be the project directory, so paths std/stdc will not be shown. GCC-generated dependency rules are of course handled properly.
If you need to see full command lines, just add a V=1 to make:
make V=1I can contribute this Makefile to Sysprogs if you are interested in. PM me.
Note: tried to add conditional “if false – endif” into Makefile to disable autogenerated rules – no luck. VisualGDB cuts off the end of file and removes “endif”, so make complains.
EDIT: I removed this line and all below:
#VisualGDB: GeneratedRules #<--- All lines below are auto-generatedNow VisualGDB does not generate static rules, but still updates source list. That is exactly what I was looking for. Still can't remove rules below this line:
#VisualGDB: FileSpecificTemplates #<--- VisualGDB will use the following lines to define rules for source files in subdirectoriesbecause VisualGDB clears the source list in that case. But even now the solution is pretty good, and can be used with present VisualGDB version by replacing only Makefile once.
Continue evaluating.
If you want to switch a project to a new toolchain, please do the following:
a. Replace the generated toolchain GUID in toolchain.xml with a more human-readable ID
b. Edit the embedded profile file (e.g. lpc.xml or mcu.xml in the project directory) to refer to a new ToolchainID.
c. Open VisualGDB Project Properties and change the CPU type to something else and back. VisualGDB will regenerate all settings files to use the new toolchain.I tried to do this for my Custom project. It resulted in inconsistency in toolchain lists.
The Custom project settings showed me just current toolchain regardless of few others in “Embedded Toolchain Manager”. I added a Beaglebone toolchain. As a result, I have TWO identical Beaglebone toolchains in the project settings, but still old toolchains and no BB one in the “Embedded Toolchain Manager”. See images below.
[attachment=1:3sqv0a37]Issue-1-01.png[/attachment:3sqv0a37]
[attachment=0:3sqv0a37]Issue-1-02.png[/attachment:3sqv0a37]2. The segger J-Link will only appear for the arm-eabi toolchains. If your toolchain uses a different ID (e.g. arm-none-abi or arm-elf), please edit its toolchain.xml to have
arm-eabi . You can specify the GNU target ID when you are importing the toolchain.I tried to do this and replaced GNUTargetID in toolchain.xml located in the toolchain root directory by arm-eabi. This did not help for my custom project.
First, the toolchain still was missing in the Project settings list (see my message above on issue 1).
Second, after importing again it appeared as arm-none-eabi, not arm-eabi.
Finally, after importing auto-downloaded arm-eabi toolchain it was in the settings, but still there was no OpenOCD or J-Link options.See images below:
[attachment=1:35p85bmo]Issue-2-01.png[/attachment:35p85bmo]
[attachment=0:35p85bmo]Issue-2-02.png[/attachment:35p85bmo]11. Intellisense. There are few issues…
Another problem is that after few toolchain changes VisualGDB duplicates project directories for unknown reason:
[attachment=0:2aqd1e3a]Issue-11-01.png[/attachment:2aqd1e3a]
Hi,
We have re-ran the scenarios you described and will be publishing a maintenance release with a few fixes in the next few days. Meanwhile, here are the answers to the things you mentioned:
• It is OK to have several toolchains with the same arm-eabi ID. Actually, OpenOCD and Segger J-Link should work for any arm* toolchain (see %LOCALAPPDATA%VisualGDBEmbeddedDebugPackagescom.sysprogs.arm.openocdedp.xml:
^arm-.* ).
• Looks like there I may have been ambiguous about the custom projects. If you want to create a custom Embedded project with all Embedded functionality present, you still need to use the Embedded wizard and the select ‘specify flags manually’ on the Device Selection page:
[attachment=0:v5yzx4c9]flags.png[/attachment:v5yzx4c9]
• The memory stats and other embedded features should also work if you use the Embedded wizard in the manual flags mode.
• By default VisualGDB shows sizes in kilobytes if they exceed 10K and in bytes otherwise. Would you still prefer an option to override this manually?
• If you are selecting a device via the Embedded Wizard, the MCU definition file path is relative to the BSP directory. If you are specifying flags manually, it is relative to the toolchain directory. Hence simply place the definition files under the toolchain directory.
• We have added a check for the previous toolchain ID to the upcoming maintenance release. When you import a toolchain, VisualGDB saves its ID and other data in the toolchain.xml file in the toolchain directory. When you import a toolchain containing toolchain.xml one directory above gdb.exe, VisualGDB will now ask if you want to reuse the stored toolchain summary (including ID). Hence after importing the toolchain on one machine, simply copy the toolchain.xml to any other machine where you want to use the toolchain.
• You can achieve error line merging by creating a batch file and a PERL file. The batch file should be invoked from the Makefile and should invoke the compiler and redirect its output to the filter:<> %* 2>&1 | C:cygwinbinperl.exe filter.pl The filter should buffer the error information and merge it with line number information in a GCC-compatible format:
foreach ()
{
if (/<>/)
{
$error_info = $1;
}
elsif (/<>/)
{
if ($error_info ne '')
{
print "error: $error_info, $1, $2, <>";
$error_info = '';
}
}
else
{
$error_info = '';
print;
}
}Let us know if you need more details.
• Your template-based solution looks very good and flexible. We will consider including something similar to one of the new releases.
• We won’t be removing the Makefile support. Currently MSBuild integration is implemented in the vs-android project that facilitates building native Android code with Visual Studio and many our customers prefer it to the Android Make files due to its relative simplicity. We may provide a similar back-end for Linux and Embedded targets, but we will surely not drop GNU Make support.
• We don’t currently offer floating licenses, but if you want to move VisualGDB from one machine to another, you can contact our support to get the first one deactivated. Also for personal licenses we allow the use on one extra machine (e.g. a laptop).
• Beaglebone toolchain is not shown for the embedded projects as it is a Linux-based toolchain that is used with a different project type. This is by design.
• The custom project we mentioned before is an Embedded project with manually specified flags and not the project created with the custom wizard. Sorry for the ambiguity.Regarding the IntelliSense directories issue, this may have happened if the toolchain test was aborted due to some reason. If you can provide us with exact repro steps, we should be able to fix it.
Sorry for the late reply, I had some play with it. And here are few comments:
About fully customizable embedded projects: I tried to specify flags manually, and it allows me to set most of options, and memory summary also works. But now it stores toolchain details in mcu.xml/mak, in GUI shows me particular toolchain greyed. I think it is ok to store toolchain data in *.mak, but I would prefer VisualGDB to show me this toolchain path in GUI and not one of “preinstalled”, so I can just change it in the Makefile. Also in this configuration I cannot run simulated GDB as debug method. It tells me “don’t have sim command”. All I need there is to see assembler (disassembled) code quickly and easily.
I got a bit better results after I created a “Custom” project, then manually edited project XML and replaced
and entries by “.embedded” but kept set to “.make”. Thus, I had simulated GDB working, easy toolchain change (but it now is defined in 2 files instead of one only). Actually, neither solution was clean (if you do that often). But there are at least two ways to do so once per project. Acceptable.
Notice: using supplied toolchains and BSPs work flawlessly. It’s me who likes a lot of customization that many (most of) customers don’t need.Anyway, maybe makes sense to define toolchains like
TOOLCHAIN_ROOT ?= ….
TOOLCHAIN_PREFIX ?= arm-eabi-And reuse these variables everywhere? Right now I see full paths stored in VisualGDB XML config (if make was selected as a builder) and they also are duplicated in debug/release.mak. That is, to have path and prefix defined just once and then reuse them everywhere. Now in different project types VisualGDB uses different approaches.
By default VisualGDB shows sizes in kilobytes if they exceed 10K and in bytes otherwise. Would you still prefer an option to override this manually?
Yes, I do. But that’s just my wish, don’t think all customers need that. But would it be customizable on the XML level, I’d be happy.
If you are selecting a device via the Embedded Wizard, the MCU definition file path is relative to the BSP directory. If you are specifying flags manually, it is relative to the toolchain directory. Hence simply place the definition files under the toolchain directory.
Great, works!
Hence after importing the toolchain on one machine, simply copy the toolchain.xml to any other machine where you want to use the toolchain.
Great solution, thanks!
You can achieve error line merging by creating a batch file and a PERL file. The batch file should be invoked from the Makefile and should invoke the compiler and redirect its output to the filter:
Yes, it should work (assuming that make compiler rules are preserved by VisualGDB).
Your template-based solution looks very good and flexible. We will consider including something similar to one of the new releases.
My Makefile is now just a “drop-in” replacement of yours. All I need to change is SOURCEFILES list (or run VisualGDB once to do so), and the rest works as shown above. I can contribute that to you if you like.
Also for personal licenses we allow the use on one extra machine (e.g. a laptop).
That’s good. Anyway, I should know more about licensing since we are a small group of developers but few of us work also at home. So it could be a team license or few personal licenses. But that is another topic, and maybe I will talk to you later on that.
Beaglebone toolchain is not shown for the embedded projects as it is a Linux-based toolchain that is used with a different project type. This is by design.
It was a custom project (IIRC). But issue was that I had few toolchains in “Embedded Toolchain Manager”, and no one of them was shown in the selection list for the project. After I installed Beaglebone toolchain from the project settings, it was shown TWICE in the list, while other (earlier installed) toolchains were still not shown. Some GUI bug?
Regarding the IntelliSense directories issue, this may have happened if the toolchain test was aborted due to some reason. If you can provide us with exact repro steps, we should be able to fix it.
Yes, toolchain tests were aborted (failed) because I used Makefile variable with linker script which was not defined during toolchain test. So test failed, I ignored it, and got that.
New question: any way to syncronize VisualStudio output folder and $(BINARYDIR)? If I have simulated PC project and ARM one in the same directory, I wish I have different build directories. Now I have to set both BINARYDIR and a build directory in VS, because latter is Debug/Release by default and it breaks PC project.
Finally, I think this thread is too oveloaded now. I will try to summarize my questions and answers and see what else still isn’t clear to me.
PS. You promised me C# project to help with generating ARM Hardware Register definitions for my chip 🙂
Hi,
Sorry for the delayed reply. We are currently investigating a potential regression with our updated ARM toolchain. We will address your issues within the next week. Sorry again for the delay.
Hi,
You can change the toolchain shown in the GUI by editing mcu.xml (
field). Again, the reason why we are extremely conservative about allowing the user to change the toolchain for an existing project is the amount of “strange” bugs it can cause. A few examples: - Different toolchains can be configured with different –with-fpu, –with-arch and –with-abi flags. If you change the toolchain to a one that was configured differently and forget to rebuild your project, trying to call arbitrary functions can just randomly crash your firmware.
- If you do rebuild your project, but link against a static library built with another incompatible toolchain, you’ll hit the same problem.
- Different toolchains can have different multilib configurations (combinations of flags for which separate versions of libc/libgcc are built). Even given that you’ve specified all flags correctly, this could easily link incompatible code together.
Yes, you know, what you are doing when hacking the toolchains (and that’s why we allow changing it by editing XML/MAK files), but if we support any sort of toolchain swapping feature, we’ll immediately get lots of feedback from people less familiar with GCC guts that their project is suddenly broken for no apparent reason.
Can you compare the full GDB logs for normal and custom projects to see what is different and hence why “sim” is not working? Normally it should not be affected by the project type.
The duplication of the toolchain prefix comes from the internal format VisualGDB uses to represent toolchains that does not support variables. We also try to minimize the complexity of the Makefile parsing hence limiting it to querying basic things only and not expanding variables. Yes, we could design a more solid way of storing that information internally, but it would probably affect less than 1% of the users, while potentially introducing bugs that could break more widely used functionality. As a workaround, you can edit the XML files programmatically (example at the end of the message).
Regarding the ability to control the “10K” format, this sounds reasonable. Would a selection between bytes, kilobytes and automatic modes be reasonable for you?
As for the Makefile replacement, our main concern is that it could be incompatible with older versions of GNU Make or have strange problems if paths have spaces or some other rare scenarios, so we would like to give it some testing before shipping it. We are currently focusing on the new IntelliSense engine, so we will probably look at the Makefile improvements after it’s done.Regarding missing toolchains for custom projects, this sounds like a bug. We’ll look into it more. Normally the toolchains are filtered by the
field in Toolchain.xml.
There is currently no way of synchronizing the VS output directory and the Makefile build directory. Normally when you create a new configuration both should match the configuration name, but if you want to change them, you have to edit them both.Finally, here’s an example of a C# tool that can generate a basic BSP including register definitions. Simply add BSPEngine.dll to the project references and build it:
using System; using System.Collections.Generic; using System.Text; using BSPEngine; namespace BspGenerator { class Program { static void Main(string[] args) { MCUFamily[] familyList = new MCUFamily[] { new MCUFamily { ID = "Family1", CompilationFlags = new ToolFlags{COMMONFLAGS = "-mcpu=cortex_m3"}, } }; MCU[] mcus = new MCU[] { new MCU { FamilyID = "Family1", ID = "Device1", FLASHBase = 0x1000, FLASHSize = 1024, MCUDefinitionFile = "mcu1.xml" } }; BoardSupportPackage bsp = new BoardSupportPackage { PackageID = "com.sysprogs.demo", PackageDescription = "TestDevices", GNUTargetID = "arm-eabi", GeneratedMakFileName = "test.mak", MCUFamilies = familyList, SupportedMCUs = mcus }; XmlTools.SaveObject(bsp, "BSP.XML"); string regDefinition = "REG1=0x1234,REG2=0x5678"; //Replace this by a real definition extracted from somewhere Listregisters= new List ();
foreach(var def in regDefinition.Split(','))
{
int idx = def.IndexOf('=');
registers.Add(new HardwareRegister { Name = def.Substring(0, idx), Address = def.Substring(idx + 1) });
}
MCUDefinition mcuDef = new MCUDefinition
{
MCUName = "MCU Subtype 1",
RegisterSets = new HardwareRegisterSet[] { new HardwareRegisterSet { Registers = registers.ToArray() } }
};
XmlTools.SaveObject(mcuDef, "mcu1.xml");
}
}
}
- You must be logged in to reply to this topic.