cpctelera/sdcc compilation problem

[ervin]

Hi folks.

Just wondering if anyone has encountered anything like this:

I have main.c in my src folder.
I also have tree0.c in the src folder.
tree0.c simply contains an array of byte values (for a sprite).
This works well and the sprite array is compiled into the program correctly.

However, if I simply rename tree0.c to tree.c, and then compile again, the CPC hangs when I run the program.
The *only* change was the renaming of tree0.c to tree.c.

After a lot of confusion, I noticed that during compilation (in the Linking step), tree.rel is being linked before main.rel.
So the sprite array is being compiled into the memory location where main is supposed to start.

If I rename the sprite file to tree0.c, then main.rel is linked before tree0.rel.
This way, the program works.

I've tried all sorts of random names for the sprite file, and some work and some don't.
I don't understand how the SDCC linking process works, so I've been unable to solve this.

[ronaldo]

Your problem does not make any sense to me in the way you analysed it. If linking order was a problem, most of CPCtelera produced works would fail because of the same issue. Linking order could potentially be a problem only on some very specific circumstances involving memory address calculations, that are not your case now, as I understand.

If you are using CPCtelera 1.4.2. (current master release) this sounds to me like a realization of the iDSK dsk corruption bug. Please, try launching

Code Select Expand

make cleanall && make
to see if that fixes the issue.

[ervin]

Hi ronaldo.

I tried "make cleanall && make" with both 1.4.2 and also the new development branch (with the fast text routines), but the problem still happens.
It's really weird.

Regardless, I'm trying to use a filename that links in the correct order, so I have a workaround for now.

[ronaldo]

Okay then. It's clearly weird.
Could you please post a copy of your project so that I can take a look at it?

[ervin]

Certainly. Here it is.

[Arnaud]

Here my test :
i renamed s0.c into tree0.c -> build & link OKi renamed tree0.c into tree.c -> build & link OKi renamed tree0.c into tree1.c -> build & link OK
It seems your project / SDCC are OK
Are you obj folder and files inside deleted with make cleanall all ?

[ronaldo]

Exactly same as @Arnaud . No problem at all after several tries of renaming the file. In fact, renaming the file affects the linking order, but not the result, which works as expected.
Are you sure you used make cleanall instead of make clean?
Please also check if you have a different SDCC version installed apart from CPCtelera and included in path or something similar interfering.

A side note:
I recommend you to create .s files for your assembly code. It is much more flexbile and convenient than __naked inline functions.
You only need to put your code in a .s file, put an entry label prefixed with underscore (for instance, _myfunction::) and finally add a declaration before using it in your C file (for instance, extern void myfunction();)

[ervin]

Thanks Arnaud and ronaldo.

Yes, my obj folder is completely emptied when I run make cleanall all.
I still get the linking problem... really weird.
I've done a full install of the latest dev branch of cpctelera, which seems to contains sdcc-3.6.8-r9946.

Here is the linking command that is run during compilation:

Code Select Expand


/home/Ervin/cpctelera-development/cpctelera/tools/sdcc-3.6.8-r9946/bin/sdcc -mz80 --no-std-crt0 -Wl-u --code-loc 0x4000 --data-loc 0 -l/home/Ervin/cpctelera-development/cpctelera/cpctelera.lib obj/tree.rel obj/main.rel obj/asm.rel -o "obj/road.ihx"


Also, thanks @ronaldo for the .s files tip.
I've implemented that technique (which is why there is an asm.rel file in the linking phase).

That's ok, I don't mind if I'm having this linking problem.
It's easy to workaround and isn't slowing development down.

[ronaldo]

Here is the linking command that is run during compilation:

Code Select Expand


/home/Ervin/cpctelera-development/cpctelera/tools/sdcc-3.6.8-r9946/bin/sdcc -mz80 --no-std-crt0 -Wl-u --code-loc 0x4000 --data-loc 0 -l/home/Ervin/cpctelera-development/cpctelera/cpctelera.lib obj/tree.rel obj/main.rel obj/asm.rel -o "obj/road.ihx"

That's ok, I don't mind if I'm having this linking problem.t
It's easy to workaround and isn't slowing development down.

There is no evidence at the moment to think it is a linking problem. In fact, after our tests, it seems much less probable than there is any problem with the linking.
The problem must be somewhere else. Which emulator are you using? Which machine are your emulating? Are you executing through DSK, CDT or SNA?
Could you please post a ZIP with your complete project after compilation? Including all objs, DSK, CDT...

[pelrun]

It'd be a useful step to run the linker manually with various object file ordering and compare the output, rather than changing filenames.

[ervin]

There is no evidence at the moment to think it is a linking problem. In fact, after our tests, it seems much less probable than there is any problem with the linking.
The problem must be somewhere else. Which emulator are you using? Which machine are your emulating? Are you executing through DSK, CDT or SNA?
Could you please post a ZIP with your complete project after compilation? Including all objs, DSK, CDT...

You are absolutely correct, I can confirm that it is nothing to do with the linking process.
I've just tried running ROAD.BIN from the DSK file, and it works, even when I use filenames that change the linking order.

The problem appears to be related to WinAPE.
I normally use a short file in WinAPE's assembler, which loads the binary into RAM, and then runs it. This is a much faster process than running the code via the DSK file.

Code Select Expand


org &4000
nolist
write direct
incbin "C:\cygwin64\home\Ervin\cpctelera-development\projects\road\obj\road.bin"
run &4000


The linking order during compilation seems to confuse my WinAPE process, which is very odd!

[pelrun]

Ah, that explains it. The linking order changes where main() ends up in the binary, because you've got nothing to fix it's location. That's fine when you just run the binary directly (the execution address in the header is updated appropriately) but your loader is assuming the location is always &4000... and it often isn't.


Edit: having a quick look inside the cpctelera makefiles, the build actually creates a "binaryAddresses.log" file which contains the load and run addresses for the compiled binary.

[ervin]

Ah, that explains it. The linking order changes where main() ends up in the binary, because you've got nothing to fix it's location. That's fine when you just run the binary directly (the execution address in the header is updated appropriately) but your loader is assuming the location is always &4000... and it often isn't.

Edit: having a quick look inside the cpctelera makefiles, the build actually creates a "binaryAddresses.log" file which contains the load and run addresses for the compiled binary.

Ah, that makes sense.
Thanks.

Sorry for the false alarm regarding linking!