<html dir="ltr">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style id="owaParaStyle" type="text/css">P {margin-top:0;margin-bottom:0;}</style>
</head>
<body ocsi="0" fpstyle="1">
<div style="direction: ltr;font-family: Tahoma;color: #000000;font-size: 10pt;">Resubmittal for Mips big endian patch with minimal 64 bit support.<br>
The 64 bit support caused a rethink of how we constructed some<br>
of our objects and thus the inclusion.<br>
<br>
big_endian.patch<br>
<br>
These changes allow us to compile big endian from the commandline for 32 bit Mips targets.<br>
The biggest changes are to endianize the opcode and then the fixups. <br>
This has been tested for shared, non-shared executables through execution.<br>
<br>
They also allow for minimal Mips 64 bit object production. This<br>
have been tested through to execution for a series of simple tests<br>
for non-shared little endian.<br>
<br>
Neither big-endian nor 64 bit have gotten the extensive testing of 32 bit<br>
little endian. That will come soon.<br>
<br>
Contributers: Jack Carter<br>
<br>
********************************************<br>
# llvm/include/llvm/Support/ELF.h<br>
********************************************<br>
<br>
Some EF_MIPS_ARCH_ defines were missing and one was just wrong.<br>
This affects marking the ELF object file for target architecture.<br>
This is needed for 64 bit.<br>
<br>
********************************************<br>
# llvm/lib/Target/Mips/MCTargetDesc/MipsAsmBackend.cpp<br>
********************************************<br>
<br>
In addition to the class vs. create issues described above this change <br>
also has some issues of note. In ApplyFixup the instruction (or data) <br>
stream is already endianized. Way to early for my taste, but such is it <br>
currently. I de-endianize the target object, usually a 32 bit instruction, <br>
apply the fixup, and then re-endianize it.<br>
<br>
This brings up 2 questions:<br>
<br>
1: Why do I need to worry about the endianization here?<br>
I shouldn't.<br>
It should be handled later on right before output.<br>
<br>
2: Why can't I use the "bits" field from:<br>
NumBytes = ((getFixupKindInfo(Kind).TargetSize-1)/8)+1;<br>
<br>
I get pointed at the whole object which has already been endianized.<br>
<br>
The fixup value is in platform endian which in our current case mean<br>
little endian.<br>
<br>
In order to do the fixup the value needs to be found in<br>
the object and converted to the target endian.<br>
<br>
The full object is endianized putting the target fixup<br>
where we expect it and the fixup value is added<br>
(not inserted) to the value already in that location.<br>
<br>
Since we had to de-endianize the whole object, we now need to re-endianize it.<br>
<br>
If I suppose since I know the object size from the relocation type<br>
I could grab the exact number of bytes needed and de-endianize<br>
them, but then I would need to break the routine up into 16,32 and<br>
64 bit variants, probably with templates. I will have to put this into<br>
my todo list for later. What I have now seems to work on our testing.<br>
<br>
********************************************<br>
# llvm/lib/Target/Mips/MCTargetDesc/MipsELFObjectWriter.cpp<br>
********************************************<br>
<br>
Put in 64 bit variant into MipsELFObjectWriter class parameters and <br>
passed to createELFObjectWriter() so the ELF header will get the setting.<br>
<br>
********************************************<br>
# llvm/lib/Target/Mips/MCTargetDesc/MipsMCCodeEmitter.cpp<br>
********************************************<br>
<br>
Put in big endian support.<br>
<br>
Note: I don't think it should be done this low, but it is how llvm is <br>
set up at this time.<br>
<br>
I also added a FIXME for a non-related switch case that I suspect needs <br>
to generate an assertion, but have not tested my hunch yet.<br>
<br>
********************************************<br>
# llvm/lib/Target/Mips/MCTargetDesc/MipsMCTargetDesc.cpp<br>
********************************************<br>
<br>
I changed the TargetRegistry to invoke targets for endianess and 32/64.<br>
The most controversial part about this is that I decided to not split <br>
up the variants into subclasses and went instead with different "create" <br>
routines that changed the single class parameters. It just was less <br>
confusing to me.<br>
<br>
This hopefully will become moot as I want to instead pass a reference <br>
to the fully fleshed out SubtargetInfo class object so target information <br>
is available to me no matter which of the myriad Mips target variants I <br>
have to process and note.<br>
<br>
********************************************<br>
# llvm/lib/Target/Mips/MCTargetDesc/MipsMCTargetDesc.h<br>
********************************************<br>
<br>
Declarations for .cpp changes above and some endian macros.<br>
<br>
Note: these macros should go away for the appropriate llvm variants. <br>
I didn't find ones that matched exactly what I wanted. I have a FIXME <br>
in the code for this.<br>
<br>
********************************************<br>
# modified: test/MC/Mips/elf-bigendian.ll <-- new file<br>
********************************************<br>
<br>
This is .ll instead of .s because Mips doesn't have its assembler llvm-mc port done yet.<br>
<br>
Check that the ELF header marks this as big endian<br>
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.<br>
Check that the first words of the text section, GP prolog are correct. If the endianess is done wrong this test will fail.<br>
<br>
********************************************<br>
# modified: test/MC/Mips/test/MC/Mips/elf-64bitEL.ll <-- new file<br>
********************************************<br>
<br>
This is .ll instead of .s because Mips doesn't have its assembler llvm-mc port done yet.<br>
<br>
Check for ELF header marking this 64 bit<br>
Check that it is little endian<br>
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.<br>
Check that the first words of the text section, GP prolog are correct.<br>
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.<br>
<br>
# <br>
###############################################################<br>
<br>
<br>
Jack<br>
<br>
<br>
</div>
</body>
</html>