Migrating from Winarm to Yagarto

Question

Hi

This question must apply to so few people...

I am busy mrigrating my ARM C project from Winarm GCC 4.1.2 to Yagarto GCC 4.3.3.

I did not expect any differences and both compile my project happily using the same makefile and .ld files.

However while the Winarm version runs the Yagarto version doesn't. The processor is an Atmel AT91SAM7S.

Any ideas on where to look would be most welcome. i am thinking that my assumption that a makefile is a makefile is incorrect or that the .ld file for Winarm is not applicable to Yagarto.

Since they are both GCC toolchains and presumably use the same linker they must surely be compatable.

TIA

Ends.

Answer 1

Both WinARM and YAGARTO are based on gcc and should treat ld files equally. Also both are using gnu make utility - make files will be processed the same way. You can compare the two toolchains here and here.

If you are running your project with an OCD, then there is a difference between the implementation of the OpenOCD debugger. Also the commands sent to the debugger to configure it could be different.

If you are producing an hex file, then this could be different as the two toolchains are not using the same version of newlib library.

In order to be on the safe side, make sure that in both cases the correct binutils are first in the path.

Answer 2

I agree that the gcc's and the other binaries (ld) should be the same or close enough for you not to notice the differences. but the startup code whether it is your or theirs, and the C library can make a big difference. Enough to make the difference between success and failure when trying to use the same source and linker script. Now if this is 100% your code, no libraries or any other files being used from WinARM or Yagarto then this doesnt make much sense. 3.x.x to 4.x.x yes I had to re-spin my linker scripts, but 4.1.x to 4.3.x I dont remember having problems there.

Answer 3

If I were you I'd check the compilation/linker flags - specifically the defaults. It is very common for different toolchains to have different default ABIs or FP conventions. It might even be compiling using an instruction set extension that isn't supported by your CPU.

Answer 4

It could also be a subtle difference in compiler behavior: code generation does change from gcc release to gcc release, and if your code contains pieces which are implementation-dependent for their semantics, it might well bite you in this way. Memory layouts of data might change, for example, and code that accidentally relied on it would break.

Seen that happen a lot of times.

Try it with different optimization options in the compile and see if that makes a difference.