[LLVMdev] Question on ELF relocations and GNU ld compatibility

[Simon Cook]

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.

Thanks,
Simon


On Tue, Jun 24, 2014 at 5:01 PM, Dominique Torette <
Dominique.Torette at spacebel.be> wrote:

>  Hi,
>
>
>
> 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
> http://www.embecosm.com/appnotes/ean10/ean10-howto-llvmas-1.0.html
>
> 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.
>
>
>
>
>
>
>
>
>
>    [image:
> http://www.spacebel.be/wp-content/uploads/2011/06/image-sign-sbp.jpg]
>
> *Dominique Torette*
> System Architect
> Rue des Chasseurs Ardennais - Liège Science Park - B-4031 Angleur
> Tel: +32 (0) 4 361 81 11 - Fax: +32 (0) 4 361 81 20
> www.spacebel.be
>
>
>
>
> ------------------------------------------------------------------------------
>
> E-MAIL DISCLAIMER
>
> The present message may contain confidential and/or legally privileged
> information. If you are not the intended addressee and in case of a
> transmission error, please notify the sender immediately and destroy this
> E-mail. Disclosure, reproduction or distribution of this document and its
> possible attachments is strictly forbidden.
>
> SPACEBEL denies all liability for incomplete, improper, inaccurate,
> intercepted, (partly) destroyed, lost and/or belated transmission of the
> current information given that unencrypted electronic transmission cannot
> currently be guaranteed to be secure or error free.
> Upon request or in conformity with formal, contractual agreements, an
> originally signed hard copy will be sent to you to confirm the information
> contained in this E-mail.
>
> SPACEBEL denies all liability where E-mail is used for private use.
>
> SPACEBEL cannot be held responsible for possible viruses that might
> corrupt this message and/or your computer system.
>
> -------------------------------------------------------------------------------
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140624/9194efcf/attachment.html>