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? Thanks, Dominique T. [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<http://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. ------------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140306/02924ad3/attachment.html>
> 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?I have the same problem for big-endian Z8, I’ve postponed the assembler for the moment because of this. Cheers, Kuba
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
>> 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, it’s also exactly the information I needed. — Kuba
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.
-------------------------------------------------------------------------------