Thanks, Serhii, for your PR. The ./testAll.sh script passes. But I have a few questions:

• ./testAll.sh runs on my PCs under Debian, MacOS and Windows. I would like to learn, why it causes issues on your machine. Would you please tell me a few more details about your problem concerning ./testAll.sh. Maybe only a specific part fails?
• When some legacy code contains for example DEBUG_LOG_MSG( "a problem\n" );, a manual replacement would give trice( "a problem\n" ) and the string "a problem" goes into til.json and "a problem" will not get compiled into the target code and there is no need to transmit the string. If I understand your approach right, the PR will result in compiling "a problem" into the target code and transmitting it over the output channel byte-by-byte.
• Having DEBUG_LOG_VALUE(42), would manually result in trice("42"); or trice("%d", 42); The -salias DEBUG_LOG_VALUE would result in triceS( "%s", "42"); if I understand your technique right, but I see SAlias_NO_MESSAGE(iD(998), 42); in your test function.
• A DEBUG_ASSERT(myFlag, "MyFail") would manually result in triceAssertTrue("myFail", myFlag);. An universal automatic seems to make things too complicated. But we can ignore such specific stuff right now.
• When I look at your test function TestAliasesInsertion (thanks for it!), I see for example Alias(iD(999), "Simple message: %d\n", 42); being finally in the target code. So what will do the compiler with it? Simply having a file print_macro.h containing #define Alias trice or the like may not work.

An example project containing legacy code with DEBUG_... macros would be very helpful for understanding.

The "Alias": "CUSTOM_ASSERT" option improves usability and debugging by preserving the original macro name. It is beneficial for developers to use aliases the first time.

Keeping the til.json file clean from aliases seems to be an approach causing less trouble in the future. What, if a user calls trice insert -alias MY_PRINT and later somehow trice insert -alias ME_PRINT accidentally? If you really need the alias information stored on a 2nd place, an additional aliases.json file is maybe an option. And: The "Alias": "CUSTOM_ASSERT" line will occur 200 times inside til.json, if CUSTOM_ASSERT occurs 200 times in the legacy code.

Additionally, I have one more feature in mind (if I have time for that): customizable color mapping based on macro usage (e.g., asserts in red, warnings in purple). Unlike the current intrusive, hardcoded approach, this would allow non-intrusive styling via CLI/config files. Retaining aliases is crucial for enabling this functionality without modifying the source code.

That is a good point. Putting the -alias information into a config file seems to be possible too.

Should I wait for a PR update?

.. if I understand your technique right, but I see ..

Yes, you've understood it correctly: there's a straightforward mapping — -alias maps to trice(), and -salias to triceS(). This PR enforces the "%s" format for triceS (-salias).

Good catch with SAlias_NO_MESSAGE(iD(998), 42); — it's just an example to illustrate the flexibility. I see it as the user's prerogative to choose between trice and triceS, based on context or personal preference. This pattern can be used for concise, assert-style logging if needed, while also providing additional info via an extended assert message format (under the assumption of neglecting performance impact, as it’s within an asserted condition).

Hope the following example clarifies and aligns our understanding. The ASSERT demonstrates the utilization of flexibility, and PRINT is just a simple alias; it also demonstrates backend flexibility, such as Trice or standard blocking Arduino Serial.print (note VA_OPT requires C++ 20):

#define ASSERT_MESSAGE_HELPER(condition_str, file_path, line_number, ...) \
  ([&]() -> const char* { \
    __VA_OPT__(const char* user_msg = format_message<256>(__VA_ARGS__);) \
    const char* file = strrchr(file_path, '/'); \
    file = file ? file + 1 : file_path; \
    return format_message<384>( \
      "[ASSERT] %s:%d: %s" __VA_OPT__(" -> %s") "\n", \
      file, line_number, condition_str __VA_OPT__(, user_msg)); \
  }())

#if !defined(TRICE_OFF) || TRICE_OFF == 0
  #define ALIAS_PRINT(...) trice(__VA_ARGS__)

  #define ALIAS_ASSERT(id, condition, ...) \
    do { if (!(condition)) { \
      const char* full_msg = ASSERT_MESSAGE_HELPER(#condition, __FILE__, __LINE__ __VA_OPT__(, __VA_ARGS__)); \
      triceS(id, "%s", full_msg); \
    } } while(0)
  
#else
  #define ALIAS_PRINT(fmt, ...) Serial.print(format_message(fmt, ##__VA_ARGS__));  
  
    #define ALIAS_ASSERT(condition, ...) \
    do { if (!(condition)) { \
      const char* full_msg = ASSERT_MESSAGE_HELPER(#condition, __FILE__, __LINE__ __VA_OPT__(, __VA_ARGS__)); \
      Serial.print(full_msg); \
    } } while(0)
#endif

triceAssertTrue("myFail", myFlag);

Yes, if I’m not missing anything, that basically requires either a more sophisticated mapping method (like a config file), which increases the learning curve, or—as I briefly mentioned earlier—more advanced tooling that can potentially track macro expansion and perform “magic,” but at the cost of added complexity in the toolchain execution:

Improving this would likely require Clang integration—adding complexity (e.g., full build flags, complete source context)—whereas Trice’s current regex-based approach remains lightweight and simple to use.

Would you please tell me a few more details about your problem concerning

That's a bit odd — the untrimmed execution checks don't seem to fail anymore, but there are still other errors.

Sorry for the confusion. I've attached the log in case it helps identify the issues. I'm simply running ./testAll.sh as-is testAll.log

gcc --version
Apple clang version 16.0.0 (clang-1600.0.26.4)
Target: arm64-apple-darwin24.5.0
Thread model: posix

Keeping the til.json file clean from aliases seems to be an approach causing less trouble in the future. What, if a user calls trice insert -alias MY_PRINT and later somehow trice insert -alias ME_PRINT accidentally? If you really need the alias information stored on a 2nd place, an additional aliases.json file is maybe an option. And: The "Alias": "CUSTOM_ASSERT" line will occur 200 times inside til.json, if CUSTOM_ASSERT occurs 200 times in the legacy code.

At this point, it might be simpler to just remove it. Do you want me to do it?

At this point, it might be simpler to just remove it. Do you want me to do it?

Yes, please. There is one more reason:

• An extended til.json format is a breaking change. A til.json file modified with a Trice tool version "1.1" is expected to cause issues with a Trice tool version 1.0.

I've attached the log in case it helps identify the issues. I'm simply running ./testAll.sh as-is testAll.log

/bin/sh: arm-none-eabi-gcc: command not found in line 899

• The script test.ALL.sh is changed now to check first and give a warning if arm-none-eabi-gcc is not installed and to skip that tests. I also added a clang translation for the G0B1_inst example.

./../testdata/triceCheck.c:2761:8: error: incompatible pointer to integer conversion passing 'char[70]' to parameter of type 'uint16_t' (aka 'unsigned short') [-Wint-conversion]
 2761 |         Trice("att:MyStructEvaluationFunction(json:ExA{Apple:%d, Birn:%u, Fisch:%f}\n", Ex.Apple, Ex.Birn, aFloat(Ex.Fish));

This tells us, that in triceCheck.c line 2761 is no iD(n) is inserted. That is somehow strange for 2 reasons:

• ./trice_insertIDs_in_examples_and_test_folder.sh should insert the IDs in triceCheck.c everywhere.
• The lines before 2761 seem to be ok.

I added for now a few sleep 1.0 lines to check if it is somehow a timing issue. If the problem persists, please comment out the ./trice_cleanIDs_in_examples_and_test_folder.sh lines inside testAll.sh and try again.

If the problem still persists, please try the released Trice tool version 1.0 for the ID handling. Maybe the parsing now is somehow different.

Concerning your code snippets:
Unfortunately cannot understand this fully. A complete example project to see the whole thing in action would be helpful. I propose to fork the G0B1_inst example project as G0B1_alias project and to enrich it with the complete alias functionality. This is good for documenting and understanding and also we can run real tests including performance checks. I don't mind, if you provide a complete different example project, PC based or with an evaluation board you have.

I understand the need to merge legacy code without or maybe only little changing it.

In #527 I mentioned:

For example, in your SOC, when a string is to be transmitted, simply prefix it with a 2-byte count containing its length and frame it as configured in triceConfig.h. Extend the Trice tool with a CLI switch to tell about the handling of such buffers. This should be no big deal. Then you can have prints and Trices parallel on the same output.

This could be a parallel way to go, but the -alias approach seems to be a better solution. Also it is good to keep the unused encoding reserved for the future.

@rokath Thank you for adding the gcc-arm-embedded warning; it helped me move forward.

As requested, I removed Alias serialization from til.json and committed that change separately (436fb05).

I chose not to clone G0B1_inst here (we can do that before merging if needed) to keep the review focused on my changes. Instead, I updated G0B1_inst with custom macro examples. These are similar but differ slightly since sprintf isn’t available; nanoprintf was added to address this. I can't confirm full functionality without hardware, but it should illustrate the need for "%s" enforcement—happy to get suggestions (966b63f).

It seems buildAllTargets_TRICE_OFF.sh always inserts IDs. I only got a clean build after commenting out the ID insertion script line in examples/G0B1_inst/build.sh.

It also fails to build buildAllTargets_TRICE_ON.sh — please see the build.log.

The testAll.sh is still failing, even after I rebased from the latest upstream and installed gcc-arm-embedded, please see
testAll.log (some G0B1_inst errors caused by 'always inserts IDs' described above)

When you have a moment, please review the changes and let me know if you have any questions, suggestions, or if I’ve overlooked anything.

Disclaimer: I'm not an embedded specialist—my experience is primarily with CPUs, not MCUs—so I lack the necessary hardware to verify and could be off on embedded-specific details. Please forgive any errors.

Hi Serhii,

I just looked at your logs.

build.log line 15: ../../_test/testdata/triceCheck.c:2761:15: error: passing argument 1 of 'Trice32fn_2' makes integer from pointer without a cast [-Wint-conversion]

This is still the mentioned issue. So it seems to be no timing issue because of the inserted sleeps.

Questions:

• Do you have this problem with the Release 1.0 files and Release 1.0 Trice binary?
  • If yes, things are getting very interesting. Please try on different PCs and OSs, for example in a virtual machine.
  • If no:
    • please try it with the Trice binary you build but use the Release 1.0 files.
    • please try the fresh cloned files and from there and Release 1.0 Trice binary.
    • please try the fresh cloned files and from there and the from there build Trice binary. This already contains your parser modifications.
    • please try the fresh cloned files and from there and the from your PR build Trice binary. This contains your latest modifications.

When I look at testAll.log, I see:

ID 13003 inside examples/G0B1_inst/Core/Src/main.c line 127 refers to {triceS heFastFoundAnswer == theRightAnswe CUSTOM_ASSERT} but is used inside til.json for {triceS %s CUSTOM_ASSERT} - setting it to 0.
ID 13004 inside examples/G0B1_inst/Core/Src/main.c line 130 refers to {triceS heFastFoundAnswer == theRightAnswer, (char*)theQuestion CUSTOM_ASSERT} but is used inside til.json for {triceS %s CUSTOM_ASSERT} - setting it to 0.
ID 13005 inside examples/G0B1_inst/Core/Src/main.c line 133 refers to {triceS heFastFoundAnswer == theRightAnswer, (char*)"'%s' Am, it is %d CUSTOM_ASSERT} but is used inside til.json for {triceS %s CUSTOM_ASSERT} - setting it to 0.
ID 13006 inside examples/G0B1_inst/Core/Src/main.c line 336 refers to {TRice msg:StartDefaultTask\n } but is used inside til.json for {TRice msg:StartDefaultTask\n CUSTOM_ASSERT} - setting it to 0.
ID 13007 inside examples/G0B1_inst/Core/Src/main.c line 363 refers to {TRice msg:StartTask02:Diagnostics and TriceTransfer\n } but is used inside til.json for {TRice msg:StartTask02:Diagnostics and TriceTransfer\n CUSTOM_ASSERT} - setting it to 0.

This noise tells us, that you have the problems with by the PR modified files. CUSTOM_ASSERT does not exist in the current Trice folder, if I remember right. Also others like npf_pprintf is not part of the Release 1.0.

For the errors starting in line 875 you got a hint in line 900: examples/G0B1_inst/Makefile: C_INCLUDE_PATH ok?
The clang compiler needs to know, where the arm-none-eabi-gcc headers are. For that it uses the C_INCLUDE_PATH value. You should adapt the Makefile to your system. Maybe you have C_INCLUDE_PATH defined in your system, but it needs to point to the arm-none-eabi GCC header files to get the project compiled. Therefore it is defined inside of the Makefile to not screw up other systems, but the user needs to adapt that manuallly. Maybe you have an idea how to do that better.

Recommendation:

• Start with the Release 1.0 files and try to run all tests successfully.
  • That should work first!
• Add your changes slowly step by step and repeat the test steps.
• First exclude any chance, that the changed parsing causes some issues. For that you could comment out most parts of triceCheck.c first and then enable in some steps. Please check if chapter https://github.com/rokath/trice/blob/master/docs/TriceUserManual.md#parser-limitation gives some hint.

The testAll.sh script now displays some context information.

Probably on Wednesday I will be able to have a closer look to your code.

I am sorry Serhii, today I was only working on TriceUserManual.md/#trice-structured-logging which was triggered by #531 and could not proceed with your PR. Please be patient, I will do my best asap. Even it is off-topic here I would be happy to get your critical feedback on the mentioned draft.

Info about error in file triceCheck.c line 2761

Accidentally there is a missing closing bracket inside of the format string at this position. The legacy parsing tolerated it, because the user is allowed to write whatever he/she wants inside the Trice format string. It is the users world. The PR536 parsing behaves differently and that is the reason, the test fails here. File ./internal/id/insertIDs_test.go contains now a new test function TestInsertWithBrackets in the main branch, which fails with the PR536 parsing but passes with the legacy parsing. Please have a look at it.

Info about build errors

There is now a file ./build_environment.sh, which needs to be adapted to the users system. Hopefully this is now the only place to edit.

Over the weekend I hopefully will be able to look deeper in the proposed changes.

Thomas, thank you.. I will look at all of it over the weekend too (including the draft).

Hi Serhii,

Trying to run ./testAll.sh on the PR goes well after "fixing" the triceCheck.c file and deactivating the new test function despite translating the G0B1_inst example:

Core/Src/main.c: In function 'StartDefaultTask':
Core/Src/main.c:337:33: error: macro "TRice" requires 3 arguments, but only 1 given
  337 |   TRice("msg:StartDefaultTask\n");

In line 337 no iD gets inserted anymore. If I build the Trice tool in the main branch and run trice insert directly or use the legacy Trice tool with the deactivated aliases in trice_environment.sh the ID insertion goes well.

To proceed, please, I need your help. I guess you have to check the PR536 parser functionality.

As of my knowledge right now, after adapting build_environment.sh to your system, the main branch should let pass the whole ./testAll.sh script successfully on your mashine.

Editing the main branch in a way to just change the parser functionality according PR536 somehow updated, should firstly give success on testAll.sh runs.

Then adding the G0B1_inst changes would be the next step.

Looking forward to your response.

Thomas, I have pushed some fixes, please see below, so far it seems that G0B1_inst example is the only remaining:

Info about error in file triceCheck.c line 2761

Thanks for flagging the issue in triceCheck.c:2761. I've addressed it with a separate, granular commit. If you'd prefer to apply the fix directly to master/upstream, I can roll back my change and rebase accordingly.

There is now a file ./build_environment.sh, which needs to be adapted to the users system. Hopefully this is now the only place to edit.

I've updated build_environment.sh to detect the gcc-arm-embedded version installed via Homebrew. While this isn't a universal solution, it fits with the existing use of Brew in the project.

The PR536 parsing behaves differently and that is the reason, the test fails here. File ./internal/id/insertIDs_test.go contains now a new test function TestInsertWithBrackets in the main branch, which fails with the PR536 parsing but passes with the legacy parsing. Please have a look at it.

Fixed. The root cause was improper handling of parentheses within string literals. I have added two more test cases to match test. Please see go test logs:

 go test ./...                  
go: downloading go.bug.st/serial v1.6.0
go: downloading github.com/rokath/cobs v0.0.0-20230425030040-4ebbe9b903b9
go: downloading github.com/spf13/afero v1.9.5
go: downloading github.com/mgutz/ansi v0.0.0-20200706080929-d51e80ef957d
go: downloading github.com/rokath/tcobs v0.9.1
go: downloading github.com/tj/assert v0.0.3
go: downloading github.com/kr/pretty v0.1.0
go: downloading golang.org/x/crypto v0.35.0
go: downloading github.com/stretchr/testify v1.8.4
go: downloading github.com/udhos/equalfile v0.3.0
go: downloading github.com/fsnotify/fsnotify v1.6.0
go: downloading github.com/pkg/errors v0.9.1
go: downloading github.com/mattn/go-colorable v0.1.13
go: downloading golang.org/x/text v0.22.0
go: downloading github.com/kr/text v0.1.0
go: downloading github.com/pmezard/go-difflib v1.0.0
go: downloading github.com/davecgh/go-spew v1.1.1
go: downloading gopkg.in/yaml.v3 v3.0.1
go: downloading golang.org/x/sys v0.30.0
go: downloading github.com/creack/goselect v0.1.2
go: downloading github.com/mattn/go-isatty v0.0.19
ok  	github.com/rokath/trice/cmd/trice	1.203s
ok  	github.com/rokath/trice/internal/args	0.838s
ok  	github.com/rokath/trice/internal/charDecoder	0.579s
ok  	github.com/rokath/trice/internal/com	3.860s
ok  	github.com/rokath/trice/internal/decoder	0.706s
?   	github.com/rokath/trice/internal/do	[no test files]
ok  	github.com/rokath/trice/internal/dumpDecoder	0.822s
ok  	github.com/rokath/trice/internal/emitter	0.948s
ok  	github.com/rokath/trice/internal/id	3.676s
ok  	github.com/rokath/trice/internal/keybcmd	1.178s
ok  	github.com/rokath/trice/internal/link	1.047s
ok  	github.com/rokath/trice/internal/receiver	0.901s
?   	github.com/rokath/trice/internal/translator	[no test files]
ok  	github.com/rokath/trice/internal/trexDecoder	0.853s
?   	github.com/rokath/trice/pkg/ant	[no test files]
ok  	github.com/rokath/trice/pkg/cipher	0.728s
ok  	github.com/rokath/trice/pkg/endian	1.077s
ok  	github.com/rokath/trice/pkg/msg	0.968s
ok  	github.com/rokath/trice/pkg/tst	1.196s

Here is a recent testAll.log

Some Observations

• ./repos/wt_trice_pr536b/examples/G0B1_inst/Core/Src/main.c:
  • Missing #include "trice.h" inserted into line 25.
  • Adding trice(":-)\n"); in lines 117 and 134 (around the CUSTOM_* code).
    • When calling ./trice_insertIDs_in_examples_and_test_folder.sh and ../../trice_cleanIDs_in_examples_and_test_folder.sh only line 117 get ID inserted/cleaned but not line 134 and the following Trices.
    • Renaming CUSTOM_ASSERT into //XXX_CUSTOM_ASSERT fixed that. The CUSTOM_PRINT in line 124 got an iD too.
    • make builds error free inside ./examples/G0B1_instthen.
    • Even with enabled CUSTOM_ASSERT in lines 130 and 133 an error free build was possible (No inserted iDs there!).
    • Enabling CUSTOM_ASSERT(theFastFoundAnswer == theRightAnswer); in line 127 causes build errors.
• Fazit:
  • Any visible CUSTOM_ASSERT, even commented out, inhibits ID insertion/cleaning after it in that file.
  • No CUSTOM_ASSERT gets an ID.
  • Without any visible CUSTOM_ASSERT, even not in comments, .testAll.sh succeeds.
• Todo for me:
  • Run G0B1_inst code with CUSTOM_PRINT on evaluation board.

EDIT

The G0B1_inst build with -DTRICE_OFF=1 fails on CUSTOM_PRINT, but that we can fix later.

EDIT

These warnings are somehow connected with CUSTOM_PRINT:

./renewIDs_in_examples_and_refresh_test_folder.sh
ID 13004 inside examples/G0B1_inst/Core/Src/main.c line 134 refers to {trice :-)\n } but is used inside til.json for {trice :-)\n CUSTOM_PRINT} - setting it to 0.
ID 13006 inside examples/G0B1_inst/Core/Src/main.c line 337 refers to {TRice msg:StartDefaultTask\n } but is used inside til.json for {TRice msg:StartDefaultTask\n CUSTOM_PRINT} - setting it to 0.
ID 13007 inside examples/G0B1_inst/Core/Src/main.c line 364 refers to {TRice msg:StartTask02:Diagnostics and TriceTransfer\n } but is used inside til.json for {TRice msg:StartTask02:Diagnostics and TriceTransfer\n CUSTOM_PRINT} - setting it to 0.

SORRY

The observations, I told you where accidently done not with a fresh build Trice tool!

Tomorrow you will get an update!

Things are much better now :-)

I am still investigating but a small problem is this test, I added into ./repos/wt_trice_pr536b/internal/id/insertIDs_test.go locally:

func TestInsertKnownID2(t *testing.T) {
	defer Setup(t)() // This executes Setup(t) and puts the returned function into the defer list.

	// create existing li.json file
	exsLI := `{
	"55": {
		"File": "file1.c",
		"Line": 3
	},
	"77": {
		"File": "file1.c",
		"Line": 2
	},
	"999": {
		"File": "fileX.c",
		"Line": 2
	}
}`
	assert.Nil(t, FSys.WriteFile(LIFnJSON, []byte(exsLI), 0777))

	// create existing til.json file
	exsTIL := `{
	"55": {
		"Type": "trice",
		"Strg": "msg:value=%d\\n"
	},
	"77": {
		"Type": "trice",
		"Strg": "%x"
	}
}`
	assert.Nil(t, FSys.WriteFile(FnJSON, []byte(exsTIL), 0777))

	// create src file1
	src1 := `
	trice("%x", 123 );
	trice("msg:value=%d\n", 123 );
	`
	assert.Nil(t, FSys.WriteFile("file1.c", []byte(src1), 0777))

	// action
	assert.Nil(t, args.Handler(W, FSys, []string{"trice", "insert", "-alias", "log", "-src", "file1.c", "-IDMin", "100", "-IDMax", "999", "-IDMethod", "downward", "-til", FnJSON, "-li", LIFnJSON}))

	// check modified src file1
	expSrc1 := `
	trice(iD(77), "%x", 123 );
	trice(iD(55), "msg:value=%d\n", 123 );
	`
	actSrc1, e := FSys.ReadFile("file1.c")
	assert.Nil(t, e)
	assert.Equal(t, expSrc1, string(actSrc1))

	// check til.json
	actTIL, e := FSys.ReadFile(FnJSON)
	assert.Nil(t, e)
	assert.Equal(t, exsTIL, string(actTIL))

	// check li.json
	actLI, e := FSys.ReadFile(LIFnJSON)
	assert.Nil(t, e)
	assert.Equal(t, exsLI, string(actLI))

	// cleanup
	FSys.Remove(FnJSON)
	FSys.Remove(LIFnJSON)
	FSys.RemoveAll(UserHomeDir)
}

In this form the test passes. I would expect a pass as well, when in the src file one "trice" gets replaced by "log". But in that case a new ID is assigned, what I consider as a bug.

:-)

Should I merge for now, or should we wait? Some details need a better documentation. I could try to write s.th. but probably you can do this better.

Sure, I can take care of it—just let me know which parts you'd like documented.

Sure, I can take care of it—just let me know which parts you'd like documented.

Ok, then I will merge tomorrow and start to document and also try to debug the small problem.

Hi Serhii, please one question:

Why did you add PATH="/Library/Developer/CommandLineTools/usr/bin:$PATH" (line 28) into build_environment.sh?
On my sytem I can remove it and all works still fine. The problem is, once I did source ./build_environment.sh I cannot run the CGO tests anymore in that terminal. I need to clear $C_INCLUDE_PATH for that too, but that is ok. When commenting out line 28, all works fine. Somhow the cgo compiler grabs some information over the $PATH variable for its library search.

Best, Thomas

ms@Mac trice % ls /Library/Developer/CommandLineTools/usr/bin 
2to3					clangd					git-upload-pack				llvm-size				Rez					swift-package-collection
2to3-3.9				cmpdylib				gm4					lorder					rpcgen					swift-package-registry
aarch64-swift-linux-musl-clang.cfg	codesign_allocate			gnumake					m4					scalar					swift-plugin-server
aarch64-swift-linux-musl-clang++.cfg	codesign_allocate-p			gperf					make					segedit					swift-run
ar					cpp					hdxml2manxml				mig					SetFile					swift-sdk
as					crashlog				headerdoc2html				nm					size					swift-stdlib-tool
asa					ctags					indent					nm-classic				size-classic				swift-symbolgraph-extract
bison					ctf_insert				install_name_tool			nmedit					sourcekit-lsp				swift-synthesize-interface
bitcode_strip				DeRez					ld					notarytool				SplitForks				swift-test
bm4					dsymutil				ld-classic				objdump					stapler					swiftc
byacc					dwarfdump				lex					otool					strings					tapi
c++					dyld_info				libtool					otool-classic				strip					tapi-analyze
c++filt					flex					lipo					pagestuff				swift					unifdef
c89					flex++					lldb					pip3					swift-api-digester			unifdefall
c99					g++					lldb-dap				pip3.9					swift-build				unwinddump
cache-build-session			gatherheaderdoc				llvm-cov				pydoc3					swift-cache-tool			vtool
cc					gcc					llvm-cxxfilt				pydoc3.9				swift-demangle				x86_64-swift-linux-musl-clang.cfg
clang					gcov					llvm-dwarfdump				python3					swift-driver				x86_64-swift-linux-musl-clang++.cfg
clang-cache				GetFileInfo				llvm-nm					python3.9				swift-experimental-sdk			xcindex-test
clang-format				git					llvm-objdump				ranlib					swift-format				xml2man
clang-format-diff.py			git-receive-pack			llvm-otool				readtapi				swift-frontend				yacc
clang-stat-cache			git-shell				llvm-profdata				ResMerger				swift-help
clang++					git-upload-archive			llvm-readtapi				resolveLinks				swift-package

Thomas, thank you for reviewing and merging the PR.

I'm not quite sure about line 28. It seems that it was initially there. As I cannot thoroughly test it due to the lack of hardware and software, and it compiles as "it is" on my environment, I've introduced only minimal changes to detect the GCC-arm-embedded version installed via Homebrew.. Here is the corresponding commit 171fa47.

For some reason I added this line and forgot about it. Probably I was extending the path for objcopy. It is commented out now and we will see.... Sorry for the noise.