[uClinux-dev] coldfire build with DISABLE_XIP causes problems

Lennart Sorensen lsorense at csclub.uwaterloo.ca
Wed May 5 16:29:03 EDT 2010


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



More information about the uClinux-dev mailing list