[LLVMdev] llvm-mc and endianess.

Dominique Torette Dominique.Torette at spacebel.be
Thu Mar 6 08:41:32 PST 2014


For what concern, the ARM architecture the endianess problem seem to be managed 'by hand' in ' ARMELFStreamer::emitInst()', not by 'EmitInstruction'.
The third argument to createELFObjectWriter() only set a boolean attribute that is retrieved in LittleEndian' local variable.
This local variable is then used, with some length information, to re-order the instruction's bytes.
Then, my understanding is that I have to define my own 'emitInst()' that perform explicitly the bytes swapping.
Could someone confirms this analysis?
 

  virtual void emitInst(uint32_t Inst, char Suffix) {
    unsigned Size;
    char Buffer[4];
    const bool LittleEndian = getContext().getAsmInfo()->isLittleEndian();

    switch (Suffix) {
    case '\0':
      Size = 4;

      assert(!IsThumb);
      EmitARMMappingSymbol();
      for (unsigned II = 0, IE = Size; II != IE; II++) {
        const unsigned I = LittleEndian ? (Size - II - 1) : II;
        Buffer[Size - II - 1] = uint8_t(Inst >> I * CHAR_BIT);
      }

      break;
    case 'n':
    case 'w':
      Size = (Suffix == 'n' ? 2 : 4);

      assert(IsThumb);
      EmitThumbMappingSymbol();
      for (unsigned II = 0, IE = Size; II != IE; II = II + 2) {
        const unsigned I0 = LittleEndian ? II + 0 : (Size - II - 1);
        const unsigned I1 = LittleEndian ? II + 1 : (Size - II - 2);
        Buffer[Size - II - 2] = uint8_t(Inst >> I0 * CHAR_BIT);
        Buffer[Size - II - 1] = uint8_t(Inst >> I1 * CHAR_BIT);
      }

      break;
    default:
      llvm_unreachable("Invalid Suffix");
    }

    MCELFStreamer::EmitBytes(StringRef(Buffer, Size));
  }

-----Original Message-----
From: Richard Sandiford [mailto:rsandifo at linux.vnet.ibm.com] 
Sent: jeudi 6 mars 2014 16:31
To: Dominique Torette
Cc: LLVMdev at cs.uiuc.edu
Subject: Re: [LLVMdev] llvm-mc and endianess.

Dominique Torette <Dominique.Torette at spacebel.be> writes:
> Hi,
>
> As a first step to port the LLVM chain on an in-house big-endian 
> processor, I'm integrating the native assembler as a new '-assemble 
> -arch=' in llvm-mc.
> All work quite well, I have a correct output ELF format except that 
> generated code is little-endian.
> I've understood that the endianess of the LLVM chain is controlled by 
> the DataLayout class, but it appear to me that llvm-mc does not make 
> use of such class.
> I've seen a backend (CPU0,
> http://jonathan2251.github.io/lbd/genobj.html) that defines two 
> different targets and performs the byte swapping as part of the 
> EmitInstruction'. Is it the right way?
> Could somebody confirm my understanding and give me some tips about 
> endianess in llvm-mc?

At the MC level you need to make your *AsmInfo constructor set:

  IsLittleEndian = false;

Also make sure you pass false to the third argument to createELFObjectWriter().

FWIW there are several in-tree targets that support big-endian, such as ARM, MIPS and PowerPC.  SystemZ is big-endian only.
It might help to compare with one of those.

Thanks,
Richard

 ------------------------------------------------------------------------------

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




More information about the llvm-dev mailing list