[uClinux-dev] M68K Compiler/Binutils - Problems with relocations

David McCullough davidm at snapgear.com
Mon Oct 31 23:20:44 EST 2005


Jivin Paul McGougan lays it down ...
> Hi all.
> 
> We are using uClinux-dist-20041215.tar.gz, compiling for the 2.6 kernel. We
> have tried many toolsets so far (all with no success), and are currently
> switching between both the pre-built binary and source-built versions from
> http://www.develer.com/uclinux/uclinux-tools-20050221/, using gcc 3.4.3.
> (with the same results).
> 
> We are working on a Coldfire 5272 chip, using XIP, uClibc and are trying to
> get our C++ application going with shared libraries.
> 
> The problem we are having (so far) is that when we try to run any program
> that we have linked against uClibc once we have compiled/linked it with the
> shared library flags (-mid-shared-library, etc), we get the following error
> (with some extra debugging I've added to find the faulting relocation):
> 
> BINFMT_FLAT: ROM mapping of file (we hope)
> BINFMT_FLAT: Allocated data+bss+stack (75981 bytes): 1fed010
> load_flat_file - Starting PIC relocs
> load_flat_shared_library - id 1
> BINFMT_FLAT: ROM mapping of file (we hope)
> BINFMT_FLAT: Allocated data+bss+stack (84896 bytes): 1fd8010
> load_flat_file - Starting PIC relocs
> load_flat_file - Starting NORMAL relocs
> load_flat_file - Doing reloc 0
> load_flat_file - Doing reloc 1
> load_flat_file - Doing reloc 2
> load_flat_file - Doing reloc 3
> load_flat_file - Doing reloc 4
> load_flat_file - Doing reloc 5
> load_flat_file - Doing reloc 6
> load_flat_file - Doing reloc 7
> load_flat_file - Doing reloc 8
> load_flat_file - Doing reloc 9
> load_flat_file - Doing reloc 10
> load_flat_file - Doing reloc 11
> load_flat_file - Doing reloc 12
> load_flat_file - Doing reloc 13
> load_flat_file - Doing reloc 14
> BINFMT_FLAT: reference 0x640104 to shared library 71, killing init!
> BINFMT_FLAT: failed to load library 1, killing init!
> 
> What you see there is us just trying to start init that we linked against a
> shared version of uClibc (we haven't even gotten to trying to see if our
> program starts yet... :( )
> 
> Originally I thought it was a problem with elf2flt, however with some
> debugging I have found that the mechanism of the relocation failure is:
> 
> Relocation table memory block: (relocations for our uClibc start at
> 0x0003F8A0)
> I have marked with asterixes the relocation that causes our fault (as
> counted by the debugging above)
> 
> 0003F8A0  00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00
> 0003F8B0  01 03 B0 48  01 03 B0 58  01 03 F0 40  01 03 F0 44
> 0003F8C0  01 03 F0 48  01 03 F0 4C  01 03 F0 7C  01 03 F0 A4
> 0003F8D0  01 03 F1 F2  01 03 F2 40  01 03 F2 44  01 03 F2 5C
> 0003F8E0  01 03 F2 84  01 03 F2 8C *01 03 F3 D2* 01 03 F4 20
> 0003F8F0  01 03 F4 24  01 03 F4 28  01 03 F4 2C  01 03 F4 30
> 0003F900  01 03 F4 34  01 03 F4 38  01 03 F4 3C  01 03 F4 40
> 
> The location we are then interested in, is the relocation value (with the
> high byte masked off) + 0x40 for the flat header size, i.e. 0x0003F3D2 +
> 0x40 = 0x0003F412
> 
> Memory block of relocation fixup:
> 0003F400  01 03 F4 00  01 04 47 64  01 04 57 64  01 04 47 64
> 0003F410  01 04 47 64  01 04*47 64  01 04*47 64  00 00 00 00
> 0003F420  00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00
> 
> (Note: This dodgy value 0x47640104 does indeed match up with the library 71,
> reference 0x640104 from the error message above)
> 
> So it looks to me like the relocation pointer is pointing to the middle of
> an address rather than the start of one.
> 
> And with some debugging in elf2flt, this matches up to these values:
> 
> Relocation details:
> Type = R_68K_32
> sym_vma = 0x01035D60
> (*(q->sym_ptr_ptr))->value = 0x00000000
> q->address = 0x00009672
> sym_addr = 0x0103DC60
> addend = 0x00007F00
> RELOC[14]: offset=0x9672 symbol=.data+0x7f00 section=.data size=4
> fixup=0x103dc60 (reloc=0x103f3d2)
> reloc[14] = 0x103f3d2
> 
> So it doesn't appear that the problem is elf2flt, because it is just using
> the q->address value (0x9672) that it retrieves from the binutils bfd
> library which is what appears to be incorrect.
> 
> I guess this means that either our binutils is broken, or that the compiler
> is generating bad relocations in the first place.


I would say the the elf2flt.ld linker script is not accounting for some
difference between the -Ur linked version and the .gdb (absolute linked
at 0) version.  If that happens the relocations get thrown out by a bit.


> In an email conversation I had with Bernardo Innocenti (thanks Bernie for
> your help so far) he said:
> > If I remember correctly, a user reported a bug with -mid-shared-library,
> > but it was in the elf2flt binary not in the compiler proper.
> >
> > Some PC-relative relocations were corrupted due to a typo in my
> > elf2flt patch to link against binutils 2.15.9x, and it's now fixed.
> 
> This appears to resemble the problem we are having, however having taken the
> latest tools from his site, I would have thought that we would have avoided
> this (as he says that he has fixed this problem now). Is the patch that he
> is describing an even later one still that we don't have?
> 
> Has anyone seen a similar problem? Better yet, does anyone have a solution
> to this problem?
> 
> We have had success building a shared uClibc with the 2.95.x compiler chain,
> but we are unable to use this version because of another bug where 2.95.x
> does not save A5 properly when using -mid-shared-library and we see this bug
> exhibit itself all the time when compiling our C++ code. However we know

Haven't seen that,  but we don't do anywhere near the work with coldfire
that we used to.

> that Bernardo Innocenti has fixed this for gcc-3.4.0 onwards (with a patch
> to mainline gcc - gcc-3.4.0-m68k_save_reg-id_shared_library.patch) which is
> why we need to use a gcc 3.4.0 (or later) compiler.

This patch may be possible to apply to fix the 2.95 issues.

> Can anyone suggest any further courses of action?
> Has anyone successfully built uClibc as a shared library on the m68k
> platform?

Not with the latest uClibc.

Using the latest uClinux-dist I could not get a uClibc shared lib to
work (previous uClibc releases worked).  I debugged it for a while but
gave up and in the Xcopilot config.arch,  shared libs are disabled for
everything but uC-libc.  XIP works,  but not shared libs.

Cheers,
Davidm

-- 
David McCullough, davidm at cyberguard.com.au, Custom Embedded Solutions + Security
Ph:+61 734352815 Fx:+61 738913630 http://www.uCdot.org http://www.cyberguard.com



More information about the uClinux-dev mailing list