[llvm-commits] Resubmittal of Mips big endian changes

Carter, Jack jcarter at mips.com
Mon Jan 23 18:22:40 PST 2012


Resubmittal for Mips big endian patch with minimal 64 bit support.
The 64 bit support caused a rethink of how we constructed some
of our objects and thus the inclusion.

big_endian.patch

These changes allow us to compile big endian from the commandline for 32 bit Mips targets.
The biggest changes are to endianize the opcode and then the fixups.
This has been tested for shared, non-shared executables through execution.

They also allow for minimal Mips 64 bit object production. This
have been tested through to execution for a series of simple tests
for non-shared little endian.

Neither big-endian nor 64 bit have gotten the extensive testing of 32 bit
little endian. That will come soon.

Contributers: Jack Carter

********************************************
#   llvm/include/llvm/Support/ELF.h
********************************************

Some EF_MIPS_ARCH_ defines were missing and one was just wrong.
This affects marking the ELF object file for target architecture.
This is needed for 64 bit.

********************************************
#   llvm/lib/Target/Mips/MCTargetDesc/MipsAsmBackend.cpp
********************************************

In addition to the class vs. create issues described above this change
also has  some issues of note. In ApplyFixup the instruction (or data)
stream is already endianized. Way to early for my taste, but such is it
currently. I de-endianize the target object, usually a 32 bit instruction,
apply the fixup, and then re-endianize it.

This brings up 2 questions:

1: Why do I need to worry about the endianization here?
    I shouldn't.
    It should be handled later on right before output.

2: Why can't I use the "bits" field from:
    NumBytes = ((getFixupKindInfo(Kind).TargetSize-1)/8)+1;

    I get pointed at the whole object which has already been endianized.

    The fixup value is in platform endian which in our current case mean
    little endian.

    In order to do the fixup the value needs to be found in
    the object and converted to the target endian.

    The full object is endianized  putting the target fixup
    where we expect it and the fixup value is added
    (not inserted) to the value already in that location.

    Since we had to de-endianize the whole object, we now need to re-endianize it.

    If I suppose since I know the object size from the relocation type
    I could grab the exact number of bytes needed and de-endianize
    them, but then I would need to break the routine up into 16,32 and
    64 bit variants, probably with templates. I will have to put this into
    my todo list for later. What I have now seems to work on our testing.

********************************************
#   llvm/lib/Target/Mips/MCTargetDesc/MipsELFObjectWriter.cpp
********************************************

Put in 64 bit variant into MipsELFObjectWriter class parameters and
passed to createELFObjectWriter() so the ELF header will get the setting.

********************************************
#   llvm/lib/Target/Mips/MCTargetDesc/MipsMCCodeEmitter.cpp
********************************************

Put in big endian support.

Note: I don't think it should be done this low, but it is how llvm is
set up at this time.

I also added a FIXME for a non-related switch case that I suspect needs
to generate an assertion, but have not tested my hunch yet.

********************************************
#   llvm/lib/Target/Mips/MCTargetDesc/MipsMCTargetDesc.cpp
********************************************

I changed the TargetRegistry to invoke targets for endianess and 32/64.
The most controversial part about this is that I decided to not split
up the variants into subclasses and went instead with different "create"
routines that changed the single class parameters. It just was less
confusing to me.

This hopefully will become moot as I want to instead pass a reference
to the fully fleshed out SubtargetInfo class object so target information
is available to me no matter which of the myriad Mips target variants I
have to process and note.

********************************************
#   llvm/lib/Target/Mips/MCTargetDesc/MipsMCTargetDesc.h
********************************************

Declarations for .cpp changes above and some endian macros.

Note: these macros should go away for the appropriate llvm variants.
I didn't find ones that matched exactly what I wanted. I have a FIXME
in the code for this.

********************************************
#    modified:   test/MC/Mips/elf-bigendian.ll  <-- new file
********************************************

This is .ll instead of .s because Mips doesn't have its assembler llvm-mc port done yet.

Check that the ELF header marks this as big endian
Check that the text section header is present, readable and the type,flags and alignment is correct. The sh_entsize is NOT correct and I have marked that on my todo list.
Check that the first words of the text section, GP prolog are correct. If the endianess is done wrong this test will fail.

********************************************
#    modified:   test/MC/Mips/test/MC/Mips/elf-64bitEL.ll  <-- new file
********************************************

This is .ll instead of .s because Mips doesn't have its assembler llvm-mc port done yet.

Check for ELF header marking this 64 bit
Check that it is little endian
Check that the text section header is present and the type,flags and alignment is correct. The sh_entsize is NOT correct and I have marked that on my todo list.
Check that the first words of the text section, GP prolog are correct.
Check that one of the sections/tables that will be affected by 64 bit is correct. I picked the symbol table since each of its' entries will be twice as big as the 32 bit flavor.

#
###############################################################


Jack


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20120124/1f52f455/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: big_endian.patch
Type: text/x-patch
Size: 19745 bytes
Desc: big_endian.patch
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20120124/1f52f455/attachment.bin>


More information about the llvm-commits mailing list