Re: Help with relocation truncation problems on m5235 coldfire target

Larry Baker <[email protected]>
Newsgroups gmane.linux.uclinux.devel
Message-ID <[email protected]>
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
[email protected]



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
> [email protected]
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by [email protected]
> To unsubscribe see:
> http://mailman.uclinux.org/mailman/options/uclinux-dev

_______________________________________________
uClinux-dev mailing list
[email protected]
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by [email protected]
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.