[LLVMdev] Proposal for -filetype=obj full big endian support

[Carter, Jack]

Jim,

I see routines that are already available to do the endianizing, but the data and text section contents don't have sizing for the individual elements as far as I can see so that I can endianize them. That is the part I am trying to solve, not the bit twiddling algorithm.

Did I miss something?

Jack
________________________________________
From: Jim Grosbach [grosbach at apple.com]
Sent: Tuesday, December 20, 2011 11:58 AM
To: Carter, Jack
Cc: List
Subject: Re: [LLVMdev] Proposal for -filetype=obj full big endian support

Hi Jack,

Everything should be already using the sized Emit* routines directly rather than outputting individual bytes of larger entities piecemeal. Have you found that not to be the case?

The Emit* routines handle endianness for you, so you shouldn't have to do much beyond that. For example, here's the EmitInvValue() implementation that underlies things and does the endianness transform:

/// EmitIntValue - Special case of EmitValue that avoids the client having to
/// pass in a MCExpr for constant integers.
void MCStreamer::EmitIntValue(uint64_t Value, unsigned Size,
                              unsigned AddrSpace) {
  assert(Size <= 8 && "Invalid size");
  assert((isUIntN(8 * Size, Value) || isIntN(8 * Size, Value)) &&
         "Invalid size");
  char buf[8];
  const bool isLittleEndian = Context.getAsmInfo().isLittleEndian();
  for (unsigned i = 0; i != Size; ++i) {
    unsigned index = isLittleEndian ? i : (Size - i - 1);
    buf[i] = uint8_t(Value >> (index * 8));
  }
  EmitBytes(StringRef(buf, Size), AddrSpace);
}

-Jim

On Dec 19, 2011, at 5:17 PM, Carter, Jack wrote:

> Proposal for ELF text and data big endian support for direct object generation
>
> Unless I am mistaken, currently big endian support in the MC layer for ELF
> direct object generation is limited to ELF headers and tables like relocations.
> Text and data section contents are still generated as individual bytes.
> It looks as if the effort was started, but never completed.
>
> The proposal is to extend the MCDataFragment class to include a container
> of offset/size that one can traverse generating each element in the correct
> endianess:
>
>   // Pseudo code
> for (iterator it = begin(), ie = end(); it != ie; ++it) {
>      switch (it.getValueSize()) {
>       default:
>         assert(0 && "Invalid size!");
>       case 1: OW->Write8 (uint8_t (it.getValue())); break;
>       case 2: OW->Write16(uint16_t(it.getValue())); break;
>       case 4: OW->Write32(uint32_t(it.getValue())); break;
>       case 8: OW->Write64(uint64_t(it.getValue())); break;
>       }
>     }
>
> Note: ObjectWriter has a set of endian correcting routines as use above.
>
> The output routines like the snippet above would be in lib/MC/MCAssembler.cpp
>
> There is an MCInstFragment, but it doesn't seem to be used. All text and data
> seem to go through MCDataFragment.
>
> The offset/size container would be filled at the
> lib/Taget/<your target>/MCTargetDesc level. In <your targetMCCODEEmitter.cpp
> for at least text. Some other source file for data.
>
> It would be nice if someone could prove that the support is already there
> and I don't have to do anything to get it, but if not, is the above
> strawman reasonable? If so, I'll implement it and put it up for review.
>
> Cheers,
>
> Jack
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev