On Wed, May 05, 2010 at 02:40:27PM -0400, Michael C. Silva wrote: > The company I work for has long-stable software implementation based on > uCLinux Coldfire. > > Some of our apps are approaching a size limit that I believe is caused by the > use of -msep-data (which I believe is used for XIP support - which we don't > use). Here's a typical link error from this change: > > hacl.elf2flt(.text+0x938): In function `hacl_InitTimer': > hacl.c:250: relocation truncated to fit: R_68K_GOT16O > haclid_HaclServer_infoGet_Handler > > > So I tried to build the entire product with DISABLE_XIP=1. This caused > problems that appear to be an error in disk image creation (there seemed to > be nothing in the mounted root filesystem). > > So I then tried to remove the -msep-data for just this one application. In > that case the application appears to crash: > > Exception Vector 8 > PC: [<00000cec>] > SR: 0004 SP: 01ee9fcc a2: 00000054 > d0: 01ecf8ac d1: 00000110 d2: 01f80116 d3: 01edfef8 > d4: 000296e0 d5: 01ec0004 a0: 00000cec a1: fffe203a > Process rpmlaunch (pid: 19, stackpage=00794320) > Stack from 01ee9fcc:<0> > <0> 00000110<0> 01f80116<0> 01edfef8<0> 000296e0<0> 01ec0004<0> > 00000cec<0> fffe203a<0> 00000054<0> > <0> 01ecf8ac<0> ffffffff<0> 00000000<0> 40200004<0> 00000cec<0> > Call Trace:<0> > > I am using gcc v3.4.0 (we've been using the same toolchain and distribution > source code for some time now). > > Are there any general suggestions? It seems if I try to adjust anything in > this regards there are severe negative consequences.
When we started using uclinux on the coldfire last year, we ran into problems compiling programs with relocation limits. Going to gcc 4.3 using an up to date elf2flt solved the problem completely since gcc now uses a different method for handling relocations and no longer has the same hard to define limitations it had before. The older gcc would compile for a while, but then once you added some more code it would suddenly reach a point where it simply couldn't anymore. Based on what I found at the time, the answer was pretty much that the old style simply couldn't handle code above a certain "size" in terms of the number of relocations that were being done. The new style seems pretty much unlimited. Of course going to the new style means now gcc (and new bugs too I am sure), new binutils, new elf2flt, new uclibc I suspect, and perhaps even new kernel. On the other hand the result for us has been great. -- Len Sorensen _______________________________________________ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
