Awesome. That will be good enough to start to move my experiment on. Thanks Joe. :)
This is possibly unlikely to end up in production on my platform. I’m mainly using it for diagnosis. Until now, I was indeed using llc to write AVR object files. However, since swift 5 I am getting obscure linker errors about overlapping sections when I go to link the elf file. I think it’s probably a target specific bug in the AVR object file writer. I’m trying to help track it down for the AVR llvm team. In order to do so I tried outputting assembly files then using avr-gcc to compile object files and looking at if they link, what is different to track down the bug.
Technically I am pretty sure in modern gcc any identifier enclosed in double quotes is legitimate so it should work with modern swift name mangling.
But I think the version of avr-gcc I’m using from CrossPack, built in 2013 is maybe too old so it’s breaking. (I’m using it to help with compatibility for people on older macs, my home compiles versions were breaking on 2013 Mac Pro’s but I’ll probably upgrade soon.)
The mangling format seems to have changed in swift 4.1 or 4.2?
Also, and this isn’t a swift issue, it’s llvm, the llvm ir looks like call “$s3AVR...” and llc seems to compile that to call ($s3AVR...) which is also breaking I think. Reading the gcc standards, even modern gcc might not like that as I’m not sure if the parentheses instead of quotes matches the gcc identifier standards.
Is there any mission goal for llvm to generally produce gcc compatible assembly language? I’m not sure what the applicable standards are here. I’ll raise a bug with the llvm guys if that’s breaking an agreed standard practice.