Proxy wrote:
wait so it's a limitation of the object file format? then what is cc65 using that it works there? or is it because cc65's section symbols are just regular old symbols that get defined at the linking stage, instead of special ".sectionxyz" directives?
Unresolved expressions are turned into relocations. What relocations are available depends on the target. In general, relocations are really simple and meant to resolve a single location with an offset. The result can be stored into the code stream in different ways, typically needed by the target at hand are provided.
The section start, end and size are just a name mangled symbol in Calypsi that is deciphered by the linker. This is of course non-standard, but it was the only way I could see that could do it. I limit my extension to a single section, no arbitrary expressions are allowed in ELF, which is why it failed. It could potentially be done in a different (non-standard) way, but that is how I implemented it.
Quote:
it is not an official header, i designed by and for myself to be the "simpliest universal executable header possible" since it's not specific to any one system or architecture.
looking at the ones you mentioned, PGX wouldn't be a good choice as it doesn't specify the size of the program, making it impossible to load from Serial as the CPU wouldn't know when to stop reading/waiting for more data.
PGZ seems good though, i'd like it more if the signature was larger so it can be used for CPU/System Identification. but whatever, it'll do.
PGZ is defined for 65816 and 68000, well, any byte oriented target that usues either 24 and 32 bit address ranges.
Quote:
hth313 wrote:
In either case, I prefer that this is solved by an output format, as that is what it is about.
any specific reason for that? wouldn't that just mean more work for you instead of just having the users do it themselves in assembly (when possible of course)?
Well, you can see from all the hoops you are trying to do that it takes time. It is that "when possible" and trying to figure out how to do it. The header and metadata also exists in memory when done this way, when it really just is supposed to be in the file.
The PGZ format is about 20 lines of code for me, it is a simple format. Adding another (simple) format is not all that expensive, but there is of course long term maintenance of it. I think the best is to use an existing format, if there are limitations with them, then I think the second best is to add a new format to take care of that use-case. It may also be possible to write a simple converter tool.
Quote:
oh i see, so the librarian utility is just a bit bare bones at the moment, i assume someday in the future it will get some more features like adding/removing/extracting individual object files, listing all the symbols in the library, etc.
The file format used is one of the two that is common on Unix, you should be able to use other (existing) tools to manipulate the library archives.
Quote:
anyways doing that worked fine and i was actually able to generate an output file for once! milestone reached!
but the victory was short lived because the generated .pgz file is only 7 bytes large despite the linker's generated .lst file saying that the executable section is 494 bytes in size... so where is all of that code? (btw why is the startup code 490 bytes? that seems a little much)
[...]
interestingly, when i change "--output-format pgz" to "--output-format raw" to see if it's just a problem with the format, the linker straight up crashes with this error:
Code:
internal error: Translator\Linker\Output\Raw.hs:14:1-60: Non-exhaustive patterns in function dumpRawProgram
so am i doing something wrong here and the linker won't tell me, or is it just having a bad day?
The internal error is caused by a bug. The Raw format only supports one "progbits" memory and there is a guard that checks if there are multiple. In this case it is none and that error guard did not trigger, but the code later did as it expected one. I need to add another error guard for this case.
The list file looks a bit fishy in that it seems like it has managed to mix zfar and farcode in the same memory, which is not allowed. zfar is bss (no bits) and farcode has bits.
What version are you using of Calypsi 65816? Is your project available on some hosting service so that I can take a look at it?
I would like to see the .scm file.
Rather than discussing here, maybe you could file an issue at
https://github.com/hth313/Calypsi-tool-chains