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

Paul McGougan paul.mcgougan at braintree.com.au
Mon Oct 31 22:56:55 EST 2005


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.

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
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.

Can anyone suggest any further courses of action?
Has anyone successfully built uClibc as a shared library on the m68k
platform?
Using the tools we are using or others?

Best regards,

Paul McGougan
Braintree Communications Pty Ltd
--
This information together with any attachments is for the use of the
intended recipient(s) only and may contain confidential and/or privileged
information and is subject to copyright. If you have received this email in
error please inform the sender as quickly as possible and delete this email
and any copies of this information from your computer system network. If you
are not the intended recipient of this email, you must not copy, distribute
or take any action(s) that relies on this information. Any form of
disclosure, modification, distribution and/or publication of this email is
strictly prohibited.




More information about the uClinux-dev mailing list