start address is indeterminate (because of zp data section)?

[Ben Campbell]

I had an odd problem on the cx16 build where my programs entry point was jumping about. One time the basic header would be "SYS 2071". Then I'd do a trivial code change and recompile... and it would be something else. I saw: 2061 2071, 2072, 2075, 2082, 2087, 2088...
I just shrugged and thought "compiler magic", and worked around it.

But fiddling around with adding Foenix 256k support, I think I might have figured it out:

Looking at mos-platform/common/ldscripts/c.ld, it has:

INCLUDE zp.ld
INCLUDE text.ld
...

Where zp.ld will include whatever initialised variables the compiler has decided to put into the zp. But the data can't be loaded directly into the zp - it appears before the .text section in the binary and is copied into the zp on startup.
But that means that the start address of .text changes depending on what initialised variables the compiler decides to locate in the zp.

Would it make more sense to reorder those two lines in c.ld to ensure that .text is always the first section (and thus has a nice fixed address)?

Doing this seems to have done the trick in my Foenix fork... my start address is now rock-solid. But maybe I'm misdiagnosing the problem?

[Daniel Thornburgh]

We have a specific relocation and assembly directive for generating ASCII strings from runtime values, specifically for use with BASIC headers. Take a look at how the e.g. Commodore BASIC header handles this.

There isn't a completely general way to ensure that the earliest part of .text is fixed, since stuff in text can have any alignment requirements it likes, and the section will be aligned accordingly. There's usually not that many alignments in practice (either one byte or two byte for C++ member functions), but it's also usually preferable to avoid hard-coding numbers, and we've done our best to prevent anything in the SDK from relying upon specific quirks of layout.

All that being said, zp.ld is more like data, bss, and noinit than text, so I could see an argument that it should be next to those in the linker script. It's customary in ELF both to have .text be the first section, and _start at an usually fixed offset from it, and that would be a desirable property for the SDK as well. So, send a PR to move it right before data; if it doesn't break anything, SGTM.

It should to go after rodata.ld though; there's a well worn convention that read-only and read-write data should be contiguous, and the former should preceed the latter.