[osnwt]

Removal of that file has helped.

Thank you!

[osnwt]

Unfortunately, no. All files are ok.

Also, I created a new connection using IP address as a host name, login/password authentication. Then started to create a new project, and got the same error in XML document 148, 23.

I should tell that user has been logged in successfully in both cases, and error is shown after login.

Please tell me what else can I do to help debugging this issue.

• This reply was modified 8 years, 4 months ago by osnwt.

[osnwt]

Here is some verbose output:

1>------ Build started: Project: trsim1.vgdb, Configuration: Debug Win32 ------
1>  VisualGDB: using project file C:\trsim1.vgdb\trsim1.vgdb.vcxproj
1>  VisualGDB: using solution file C:\trsim1.vgdb\trsim1.vgdb.sln
1>  VisualGDB: using configuration Debug
1>  VisualGDB: Trying to detect if your Makefiles need updating... Using configuration: Debug|Win32
1>  SSH: Looking up host...
1>  SSH: Connecting...
1>  SSH: Handshaking...
1>  SSH: Checking key...
1>  SSH: Authenticating...
1>  Build/launch failed: В документе XML (148, 23) присутствует ошибка.
1>  ------------------------------
1>  Detailed exception info:
1>  System.InvalidOperationException: В документе XML (148, 23) присутствует ошибка. ---> System.Xml.XmlException: "", шестнадцатеричное значение 0x1B, является недопустимым знаком., строка 148, позиция 23.
1>     в System.Xml.XmlTextReaderImpl.Throw(Exception e)
1>     в System.Xml.XmlTextReaderImpl.Throw(String res, String[] args)
1>     в System.Xml.XmlTextReaderImpl.Throw(Int32 pos, String res, String[] args)
1>     в System.Xml.XmlTextReaderImpl.ParseNumericCharRefInline(Int32 startPos, Boolean expand, StringBuilder internalSubsetBuilder, Int32& charCount, EntityType& entityType)
1>     в System.Xml.XmlTextReaderImpl.ParseCharRefInline(Int32 startPos, Int32& charCount, EntityType& entityType)
1>     в System.Xml.XmlTextReaderImpl.ParseText(Int32& startPos, Int32& endPos, Int32& outOrChars)
1>     в System.Xml.XmlTextReaderImpl.ParseText()
1>     в System.Xml.XmlTextReaderImpl.ParseElementContent()
1>     в System.Xml.XmlTextReaderImpl.Read()
1>     в System.Xml.XmlTextReader.Read()
1>     в System.Xml.XmlReader.ReadElementString()
1>     в Microsoft.Xml.Serialization.GeneratedAssembly.XmlSerializationReaderHostWideSettingsCollection.Read2_Record(Boolean isNullable, Boolean checkType)
1>     в Microsoft.Xml.Serialization.GeneratedAssembly.XmlSerializationReaderHostWideSettingsCollection.Read3_ModifiedEnvirionment(Boolean isNullable, Boolean checkType)
1>     в Microsoft.Xml.Serialization.GeneratedAssembly.XmlSerializationReaderHostWideSettingsCollection.Read4_HostSettings(Boolean checkType)
1>     в Microsoft.Xml.Serialization.GeneratedAssembly.XmlSerializationReaderHostWideSettingsCollection.Read5_HostWideSettingsCollection(Boolean isNullable, Boolean checkType)
1>     в Microsoft.Xml.Serialization.GeneratedAssembly.XmlSerializationReaderHostWideSettingsCollection.Read6_HostWideSettingsCollection()
1>     --- Конец трассировки внутреннего стека исключений ---
1>     в System.Xml.Serialization.XmlSerializer.Deserialize(XmlReader xmlReader, String encodingStyle, XmlDeserializationEvents events)
1>     в System.Xml.Serialization.XmlSerializer.Deserialize(Stream stream)
1>     в BSPEngine.XmlTools.LoadObject[_Ty](String xmlFile, Type[] extraTypes)
1>     в VisualGDB.Backend.SharedXmlSettingsContainer`1.c()
1>     в ft.a()
1>     в ft..ctor(yk A_0, SSHConnectionSettings A_1, Boolean A_2, le A_3)
1>     в q8.a(String A_0, String A_1)
1>     в q8.b.a(String A_0, String A_1, a A_2)
1>     в q8.a(RemoteHostSettings A_0)
1>     в rx.a(RemoteHostSettings A_0, Boolean A_1)
1>     в d7.a(SourceTransferAction A_0, SourceCache A_1, aj3 A_2, Int32& A_3)
1>     в acu.a(Boolean A_0, Boolean& A_1)
1>     в ace.a(BuildMode A_0, a A_1)
1>     в ace.b(BuildMode A_0, a A_1)
1>     в no.a(String A_0, String A_1, BuildMode A_2, ael A_3, String A_4, String A_5)
1>     в no.a(String[] A_0)
1>  ------------------------------
1>  Detailed exception info:
1>  System.Xml.XmlException: "", шестнадцатеричное значение 0x1B, является недопустимым знаком., строка 148, позиция 23.
1>     в System.Xml.XmlTextReaderImpl.Throw(Exception e)
1>     в System.Xml.XmlTextReaderImpl.Throw(String res, String[] args)
1>     в System.Xml.XmlTextReaderImpl.Throw(Int32 pos, String res, String[] args)
1>     в System.Xml.XmlTextReaderImpl.ParseNumericCharRefInline(Int32 startPos, Boolean expand, StringBuilder internalSubsetBuilder, Int32& charCount, EntityType& entityType)
1>     в System.Xml.XmlTextReaderImpl.ParseCharRefInline(Int32 startPos, Int32& charCount, EntityType& entityType)
1>     в System.Xml.XmlTextReaderImpl.ParseText(Int32& startPos, Int32& endPos, Int32& outOrChars)
1>     в System.Xml.XmlTextReaderImpl.ParseText()
1>     в System.Xml.XmlTextReaderImpl.ParseElementContent()
1>     в System.Xml.XmlTextReaderImpl.Read()
1>     в System.Xml.XmlTextReader.Read()
1>     в System.Xml.XmlReader.ReadElementString()
1>     в Microsoft.Xml.Serialization.GeneratedAssembly.XmlSerializationReaderHostWideSettingsCollection.Read2_Record(Boolean isNullable, Boolean checkType)
1>     в Microsoft.Xml.Serialization.GeneratedAssembly.XmlSerializationReaderHostWideSettingsCollection.Read3_ModifiedEnvirionment(Boolean isNullable, Boolean checkType)
1>     в Microsoft.Xml.Serialization.GeneratedAssembly.XmlSerializationReaderHostWideSettingsCollection.Read4_HostSettings(Boolean checkType)
1>     в Microsoft.Xml.Serialization.GeneratedAssembly.XmlSerializationReaderHostWideSettingsCollection.Read5_HostWideSettingsCollection(Boolean isNullable, Boolean checkType)
1>     в Microsoft.Xml.Serialization.GeneratedAssembly.XmlSerializationReaderHostWideSettingsCollection.Read6_HostWideSettingsCollection()
1>  ------------------------------
1>  Product version: 5.0.18.529

[osnwt]

PS to bazis: why there are two equal gdbstub baud rate fields in debug settins? One by default is 74800 (shouldn’t it be 74880?), another is 115200. The same labels, though.

[osnwt]

I saw the same behavior, but do not remember exactly when and why. In the end I found it working, but with few issues. For instance, I was not able to run ANY RTOS-based examples at all (even w/o gdbstub), but IoT SDK-based ones worked.

My suggestions:

• First, try IoT SDK based Blink example, comment out any gpio references (gpio_init and gpio control in callback) since serial port uses the same pin as LED (on generic modules). So keep the pin for gdb.
• Second, play with serial baud rate. It uses autobaud for serial downloader, and works well at 230400 for me as well as @ 74880 (74800). But gdbstub might not work with arbitrary baud rate. Try use 115200 or 74800.

Still, expect few issues making things unusable at the moment. For example, if I put breakpoint in callback during run, the program stops and tick counter correctly displayed. Removing BP, continuing and setting BP again shows increased counter as expected. But if you keep BP there and press “Continue”, next stop will NOT change tick counter for unknown reason. If you set BP before program start, it will be zero forever. In disassembly I saw that register loads wrong counter var address (40*), but if you put &var in memory window, it uses real address (3F*). Somewhere on forums I saw that gdb disassembles xtensa code incorrectly. Maybe that’s it.

Unfortunately, with JTAG I also had issues. Tried with FTDI-based JTAG (FOSS JTAG from OpenPilot based on FLOSS JTAG), and Segger J-Link V8. Works well in RAM, but with flash it saves code to flash but does not start program correctly. Pulling down GPIO15 and resetting starts program from flash and then BP works and shows data. I don’t yet know how to overcome this issue observed with both JTAG probes…

 

[osnwt]

Also since VisualGDB supports native builds (that is, builds on the target system via ssh using native toolchains), almost any Linux system with gnu/gcc toolchain should be compatible even if there is no local cross-toolchain available.

[osnwt]

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 🙂

[osnwt]

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]

[osnwt]

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]

[osnwt]

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]

[osnwt]

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-generated

Now 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 subdirectories

because 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.

[osnwt]

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.elf

instead 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.o  

But 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.o

Here 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=1

I can contribute this Makefile to Sysprogs if you are interested in. PM me.

[osnwt]

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).

[osnwt]

@sierra wrote:

Does anybody know the Error Result: “VGDB1000: undefined reference to `_sbrk'”
Has anybody a workaround for that behavior?

You also may consider using the latest arm-none-eabi toolchain from launchpad.com which supports nano lib option (nno version of nwlib). It is usually ok for embedded projects and some projects which require such stubs can be linked just fine with nano lib.

[osnwt]

Yes, I also thought about that. But using Win7 x64, I’ve never had any problem with env size, and it hardly can be called too old version. My environment has around 2K of data, so it should not be a problem. But still I’ve rebooted the system to see if it helps.

[Author]

Posts