Steve,

I found this at 
http://gcc.gnu.org/onlinedocs/gcc-4.5.4/gcc/M680x0-Options.html.  I don't know 
if gcc 4.3.2 has this option, but it's worth a try.  Maybe you only have to use 
this in certain routines?  Maybe not, if there is just one GOT for the entire 
program.  Other google hits for "relocation truncated to fit: R_68K_GOT16O" 
said to remove XIP options or shared library, like -msep-data.  I'm not sure 
that is possible on a ColdFire.  I noticed you are using -O1.  Did you try -Os? 
 My ColdFire distribution uses -Os.

> -mxgot
> -mno-xgot
> When generating position-independent code for ColdFire, generate code that 
> works if the GOT has more than 8192 entries. This code is larger and slower 
> than code generated without this option. On M680x0 processors, this option is 
> not needed; -fPIC suffices.
> GCC normally uses a single instruction to load values from the GOT. While 
> this is relatively efficient, it only works if the GOT is smaller than about 
> 64k. Anything larger causes the linker to report an error such as:
> 
> 
>           relocation truncated to fit: R_68K_GOT16O foobar
>      
> If this happens, you should recompile your code with -mxgot. It should then 
> work with very large GOTs. However, code generated with -mxgot is less 
> efficient, since it takes 4 instructions to fetch the value of a global 
> symbol.
> 
> Note that some linkers, including newer versions of the GNU linker, can 
> create multiple GOTs and sort GOT entries. If you have such a linker, you 
> should only need to use -mxgotwhen compiling a single object file that 
> accesses more than 8192 GOT entries. Very few do.
> 
> These options have no effect unless GCC is generating position-independent 
> code.
> 

Larry Baker
US Geological Survey
650-329-5608
ba...@usgs.gov



On 7 Feb 2013, at 10:08 AM, Steve deRosier wrote:

> I hope someone here can help.  I'm trying to port an older project
> from ~5 year old version of uClinux to a current version.  I've
> managed to get everthing done, until I went to actually port the
> business logic app.  I'm getting the following types of errors when it
> goes to link:
> 'relocation truncated to fit: R_68K_GOT16O'
> 
> Some searching and I roughly understand the problem, and the alleged
> solution is to build some of the problem files with the -mxgot flag.
> Fine.  Then the following error:
> '/usr/local/CodeSourcery/Sourcery_CodeBench_Lite_for_ColdFire_uClinux/m68k-uclinux/bin/elf2flt:
> error: reloc type R_68K_GOT32O is not supported'
> 
> @#$%^#@!
> 
> Compile command line:
> ucfront-gcc m68k-uclinux-gcc -mcpu=5235 -DCONFIG_COLDFIRE -O1 -g -pipe
> -fno-common -fno-builtin -Wall   -DEMBED -msep-data -Dlinux
> -D__linux__ -Dunix -D__uClinux__ -Wall -Werror -Wno-unused
> -Wpointer-arith  -MD
> -I/home/derosier/inthinc/projects/mcm820kernel/lib/libhessian/include
> -I/home/derosier/inthinc/projects/mcm820kernel/user/iwi/src
> -DCONFIG_5235 -DDIRECT_CALL -I./include -I/usr/include/libxml2
> -I/home/derosier/inthinc/projects/mcm820kernel/staging/include
> -I/home/derosier/inthinc/projects/mcm820kernel/user/iwi/src/common
> -I/home/derosier/inthinc/projects/mcm820kernel/user/iwi/modules/sbs_module/include
> -I/home/derosier/inthinc/projects/mcm820kernel/lib/libhessian/include
> -c -o src/controller/queue.o src/controller/queue.c
> 
> When I keep the intermediates, here's the header at the top of the .s file:
> | GNU C (Sourcery CodeBench Lite 2011.09-23) version 4.6.1 (m68k-uclinux)
> | compiled by GNU C version 4.3.2, GMP version 4.3.2, MPFR version
> 3.0.1-p4, MPC version 0.9
> | GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
> | options passed:  -fpreprocessed controller.i -mcpu=5235 -msep-data
> | -auxbase-strip src/controller/controller.o -g -O1 -Wall -Werror
> | -Wno-unused -Wpointer-arith -fno-common -fno-builtin -fverbose-asm
> | options enabled:  -fPIC -fauto-inc-dec -fbranch-count-reg
> | -fcombine-stack-adjustments -fcompare-elim -fcprop-registers -fdefer-pop
> | -fdelete-null-pointer-checks -fdwarf2-cfi-asm -fearly-inlining
> | -feliminate-unused-debug-types -fforward-propagate -ffunction-cse
> | -fgcse-lm -fguess-branch-probability -fident -fif-conversion
> | -fif-conversion2 -finline -finline-functions-called-once -fipa-profile
> | -fipa-pure-const -fipa-reference -fira-share-save-slots
> | -fira-share-spill-slots -fivopts -fkeep-static-consts
> | -fleading-underscore -fmath-errno -fmerge-constants -fmerge-debug-strings
> | -fmove-loop-invariants -fpeephole -fprefetch-loop-arrays
> | -freg-struct-return -fsched-critical-path-heuristic
> | -fsched-dep-count-heuristic -fsched-group-heuristic -fsched-interblock
> | -fsched-last-insn-heuristic -fsched-rank-heuristic -fsched-spec
> | -fsched-spec-insn-heuristic -fsched-stalled-insns-dep -fshow-column
> | -fsigned-zeros -fsplit-ivs-in-unroller -fsplit-wide-types
> | -fstrict-volatile-bitfields -ftoplevel-reorder -ftrapping-math
> | -ftree-bit-ccp -ftree-ccp -ftree-ch -ftree-copy-prop -ftree-copyrename
> | -ftree-dce -ftree-dominator-opts -ftree-dse -ftree-forwprop -ftree-fre
> | -ftree-loop-if-convert -ftree-loop-im -ftree-loop-ivcanon
> | -ftree-loop-optimize -ftree-parallelize-loops= -ftree-phiprop -ftree-pta
> | -ftree-reassoc -ftree-scev-cprop -ftree-sink -ftree-slp-vectorize
> | -ftree-sra -ftree-ter -ftree-vect-loop-version -funit-at-a-time
> | -fvar-tracking -fvar-tracking-assignments -fverbose-asm
> | -fzero-initialized-in-bss -mdiv -msep-data
> 
> 
> Link:
> 
> ucfront-gcc m68k-uclinux-gcc -mcpu=5235 -DCONFIG_COLDFIRE -Wl,-elf2flt
> -Wl,-move-rodata -msep-data -Wl,-elf2flt -Wl,-move-rodata -msep-data
> -L/home/derosier/inthinc/projects/mcm820kernel/user/iwi/libhessian -o
> controller {...lots of .o...} libhessian/libhessian.a -lz -lm  -lm
> 
> I suspect one of the fundamental problems is the code has some HUGE
> functions (2500+ lines) with huge switch blocks, but I'm here mainly
> to port not to muck with (ne refactor) the logic.
> 
> All help will be appreciated.
> 
> Thanks,
> - Steve
> _______________________________________________
> 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

_______________________________________________
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

Reply via email to