[uClinux-dev] GOT size limit reached

Pauli pauli at bne.snapgear.com
Wed Aug 31 16:53:46 EDT 2005

Anders Holmberg wrote:

> I am working for a customer that is implementing a C++ application on  
> a Coldfire 5272 target; and this application has reached the GOT size  
> limit. I am sure that this is the problem, because when examining the  
> disassembly from a previous release (without the GOT size error) and  
> grepping for "movel %a5(" you can see that it is very close to the  
> 32k limit. One solution would of course be to skip XIP but this will  
> bring other problems; so I am currently trying to expand the GOT  
> table size.

Have you considered using shared libraries?  Each library gets its own GOT 
which is limited to 32k.

You would save immediately since libc would go shared and all its internal 
symbols would move out of the GOT of the main program.

Much better savings would be available by breaking your application into a 
main program and a shared library you've effectively doubled the GOT space 
available.  Make it two shared libraries and a main program.

> So, my question is, has anyone done something like this before? Is  
> there anything I am missing in the strategy above?

I don't believe anyone has done this.  I thought about using the negative %a5 
offsets when I first did the XIP and shared library support but decided it was 
too much pain :-)  I think the procedure linkage table used these for a 
"normal" relocatable build.  I fixed things so calls went through the GOT.

Most definitely have a compiler switch.  Don't want to be paying the extra 32k 
on every application unnecessarily.  You're also not going to be compatible 
with shared libraries.  They use the negative offsets from %a5 to figure out 
where their data segment lies.  So make sure the compiler switch errors out if 
it is specified along with shared libraries.

> 2. Change the crt0.S startup code to set a5 to .data + 32768 instead  
> of .data.

I'd also think about moving the %a5+32k into the binfmt_flat loader in the 
kernel and grabbing another flag bit from the flat file header to specify this 
case.  That way you could (in theory at least) have both your big C++ 
application and lots of normal ones on the same unit.


Dr Paul Dale, Software Grunt, SnapGear - A CyberGuard Company
Leaders in embedded Linux security   http://www.SnapGear.com/

More information about the uClinux-dev mailing list