[uClinux-dev] Porting elf2flt to a new ARCH

John Williams jwilliams at itee.uq.edu.au
Thu Sep 14 21:35:20 EDT 2006

John Z. Bohach wrote:

> Is there any documentation, hints, pointers, etc. that would help in adding
> a new ARCH to elf2flt?  I have the libbfd, libiberty, etc. (in essence, the
> standard cross-toolchain for a with-MMU version of the new h/w to which I
> aim to port uClinux apps.)

In addition to David's comments, the objdump -r (show relocs) option is very

If you look at the ld-elft2flt wrapper script, you can see that it creates 3
different outputs:

app.elf   - this is the fully linked, but unrelocated elf image
app.gdb   - linked and relocated to address zero
app       - flat binary

Normally the script deletes the .elf file as it's an intermediate product, but
it can actually be quite useful when hacking on elf2flt, because if you run

{$ARCH}-objdump -r app.elf

on it, you'll get to see all of the lovely reloc types you'll have to handle,
and the addresses where they occur.

This, in conjunction with "objdump -S" (full disassemble, with C-code
interleaved if app was compiled with -g) will give you clues on what sort of
relocations they are, and how they need to be handled.

The CPU documents will tell you about the various addressing modes. Most of the
relocs are pretty straight foward, and there are plenty of clues from other
arch's to follow.  But, it seems each arch has at least one nasty mode, that
will take a mix of hard work and guess work!

For handling relative addressing, remember that in elf2flt the variable "dot"
holds the address of the current instruction.  So you often see constructs where
you get the address of some branch target, and work out "dot - target" - this is
working out the relative address offset.

Hope this helps


More information about the uClinux-dev mailing list