Including assembly file as part of .elf build

Help
1

I am porting my old 0.8.1 Zig PinePhone project to 0.14.0 under Asahi Linux. I especially wanted to simplify the very long build shell script. Also, because of the large number of code changes required, I decided I should start with a single simple Zig program, just to toggle the Phone LEDs.

My program builds, and using addObjCopy I am able to extract the binary from the elf file ready for packaging up for my JumpDrive SDCard. However, I suspect I need to include some arm64 CPU initialisation. Since I am replicating a lot of the articles from porting NuttX with Zig to PinePhone. I can see such an assembly file exists there.

My question: when I add this assembly to my buildfile using addAssemblyFile it skips over #includes and #defines, leading to errors when they are used in the assembly. I started to tweak the assembly to remove them, but it feels wrong. Then I recalled that I changed the file extension for .S to .s and a little research is showing that maybe the assembly file I have needs to be handled in Zig differently, but I dont know how. Is there an option on addAssemblyFile that supports macros/defines/includes etc ?

2

If an assembly file needs to be preprocessed, its extension should indeed be .S; .s assembly files are assembled as-is without running the preprocessor. This is the case with gcc/clang command line drivers too.

1 Like
3

Thanks for the confirmation. Is there a way to process the .S file using addAssemblyFile or do I need to drop out to a command line tool for this?

4

I’m not sure what you mean. If the file name ends in .S (upper case), it will be preprocessed; you don’t need to do anything special.

5

I think I was building the wrong ‘flavour’ of arm code and my ld file was wonky as probably still is, since the first 8 bytes of assembly look garbage, but it is processing the macros and defines now, thanks. (aarch64,freestanding,none with cpu set as cortex_a53). I can see a asm-nop from Zig appearing which is also reassuring. Are there more options on addObjCopy available, other than the .format=.bin I am using? Maybe the extra 8 bytes are something that needs to be stripped…

My code still doesnt run, but a step closer, thanks!

6

Only what you see here at the moment: Zig Documentation

7

Thanks. I was having wasm exception on the docu in Brave, but works in Icecat. Seems like the binary option is already stripped, so must be my .ld file.

I stripped the 8 bytes manually, and thought I’d cracked it. Flashing LED is my test case, which it did! but turns out the pinePhone error state is also a flashing LED :slight_smile:

[edit] I suspect I might be seeing some instruction reordering, of course, silly me. But still a couple strange values in the output, almost like the address of the functions. Probably because I use LONG(symbol) to get my functions into .text. Lots to learn, sorry for the noise!

8

Good news, I’m booting ‘baremetal’ Zig code! :slight_smile:

The main problem was that my exported symbols were being stripped in ReleaseSmall. Fixed by taking the address of them in the .ld file using LONG(symbol). And I needed some magic number markers as the first bytes in the binary output. The assembly is now simple enough that it also works as ‘global assembly’, but not being keen on ‘\’ clutter, I’ll keep it in a separate file.

Thanks again for the help.