Author Topic: CS GCC Lite vs Yagarto  (Read 9389 times)

Offline paulk

  • Newbie
  • *
  • Posts: 45
    • View Profile
CS GCC Lite vs Yagarto
« on: November 24, 2009, 03:12:53 AM »
I'd been having issues with CS GCC Lite, and decided to give Yagarto a whirl.  As it turns out, Yagarto wasn't any better (actually, it was worse!).  After fighting with it for some time, I was able to finally adjust the .ld script for both CS GCC and Yagarto to work.  I made separate batch files for both, so I could compile the same code using either one.

I found that the Yagarto toolchain is significantly worse with regards to code density.  In all fairness, I'm not sure if I had all the optimization settings set properly (ie: I took Mark's makefile and ld script from the GNU directory and modified them for Yagarto to work.  Here are some notes, in case anyone else is interested:

Yagarto:
1) You should add "-mfpu=vfp" to the CFLAGS section in the makefile.  Otherwise you'll get errors regarding "VFD instructions"
2) Make sure you update the makefile with the name of the new .ld file that you create (in case you aren't editing the existing one)
3) Any changes to the xxxx.ld file should be mirrored in the xxxx_BM.ld file
4) Add the following section to the xxxx.ld file(s).  It should go right after the "vectors_ram" section:
Code: [Select]
  __eh_frame_ram_start__ = ALIGN(__vectors_ram_end__, 4);
  .eh_frame ALIGN(__vectors_ram_end__, 4):
  {
     KEEP(*(.eh_frame));
  }
  __eh_frame_ram_end__ = __eh_frame_ram_start__ + SIZEOF(.eh_frame);

  . = ASSERT(__eh_frame_ram_end__ >= __SRAM_segment_start__ && __eh_frame_ram_end__ <= (__SRAM_segment_start__ + 0x00010000) , "error: .eh_frame is too large to fit in SRAM memory segment");

CS
1) if linking any routines from libc, you'll probably get errors about the section ".ARM.exidx" overlapping with vectors.  I think this is because libc requires this section (apparently, it's for exceptions).  You'll have to add it to the xxxx.ld file (after .ctors, before .rodata) section as follows:
Code: [Select]
/* .ARM.exidx is sorted, so has to go in its own output section. */

  __exidx_start = ALIGN(__ctors_end__, 4 );

  .ARM.exidx ALIGN(__ctors_end__, 4) :
  {
    *(.ARM.exidx* .gnu.linkonce.armexidx.*)
  }
  __exidx_end = __exidx_start + SIZEOF(.ARM.exidx);

With these changes I was able to compile the same snippet of code....(although Yagarto puked when I tried to use the ctime function because of unresolved references to a bunch of system calls....I suspect I'd have to play more with syscalls.c and include it).

Anyways, on a rather hacked up piece of code (not using any libc functions), these are the results I got:

Yagarto:
Code: [Select]
   text    data     bss     dec     hex filename
  68780     107     972   69859   110e3 uTaskerV1.4.elf

CS GCC Lite:
Code: [Select]
   text    data     bss     dec     hex filename
  57552     107     976   58635    e50b uTaskerV1.4.elf

As you can see, there is > 10k difference!  After seeing this, and after Yagarto died totally with the ctime() function (I *did* manage for CS GCC Lite to compile it), I think I'll stick with CS for the moment.