Question on ELF relocations and GNU ld compatibility


I’m writing a ‘LLVM Integrated Assembler’ for an in-house 32bits micro controller.

As far as now, I’ve followed the instructions from Simon Cook (Embecosm) as described in Howto: Implementing LLVM Integrated Assembler

But, I don’t catch how to finalize the relocations.

In the case of my micro controller, relocation are only used for the ‘Jump’ instruction.

The ‘Jump’ instruction is composed of 32 bits opcode, followed bit a 32 bits absolute jump address.

When parsed, this jump address is saved as an expression.

Later, this expression is translated into a fixup.

Finally, the fixup is translated into a relocation type by the GetRelocType(). (I only have one relocation type.)

The generated ELF file includes the relocation records. I can dump this relocation records with standard linux ‘readelf’ command.

Relocation section ‘.rela.text’ at offset 0x470 contains 2 entries:

Offset Info Type Sym.Value Sym. Name + Addend

0000024c 00000101 unrecognized: 1 00000224 Lback + 0

00000254 00000101 unrecognized: 1 00000224 Lback + 0

So far, so good! But the relocation type are unrecognized and the standard linux ‘ld’ command reports an error.

ld: /tmp/branch.o: Relocations in generic ELF (EM: 201)

/tmp/branch.o: error adding symbols: File in wrong format

My understanding is that now I have to ‘open’ the GNU ‘ld’ sources files to add the relocation schema for my ‘jump’ instruction.

I would like to avoid modifying the GNU ‘ld’ or the LLVM linker.

My relocation schema is quite simple: at relocation record offset, I have to write the Sym. Value on 32 bits big endian.

Is there such simple relocation schema already built-in the GNU ‘ld’?

And how to activate it, by returning a relocation type in the GetRelocType()?

Thanks, in advance? Dominique Torette.

Hi Dominique,

My understanding is that now I have to ‘open’ the GNU ‘ld’ sources files to add the relocation schema for my ‘jump’ instruction.

Yep. The definition of all ELF relocation types is delegated to the
CPU architects by the top-level SystemV ABI specification.

There's not really any way around that, I'm afraid (at least, without
massive hackery like putting e_machine == EM_386 and hoping ld doesn't
actually do anything x86-specific).



Hi Dominique,

The output from readelf you have posted looks fine, so it looks like as far as generating your relocations in LLVM is concerned that is fine.

Unfortunately as GNU ld is built as a target specific linker and all that is stored in your ELF file is the relocation type (which looks like in your case to be type 1) and not the specifics (32-bit big endian value with no offset), there will need to be some changes made to GNU ld and have it built for your target, then calling it via myarch-ld. These changes don’t necessarily need to be large, but they are unavoidable I’m afraid if you want something which will work reliably.