[PATCH] Handle crazy mips 64 little endian case.

[Jack Carter]

I believe that this is the format for both n64 and n32 for Mips. We haven't ported n32 to LLVM yet. 

I implemented this as a generic abi because I didn't know if any of the other targets took advantage of the packing of relocations this does. It's actually a nice element. If it is just Mips, then by all means call it the Mips NABI.

Jack
On 04/27/2013 08:15 AM, Rafael Espíndola wrote:> On 22 April 2013 09:28, Richard Sandiford <rsandifo at linux.vnet.ibm.com> wrote:
>> Rafael Ávila de Espíndola <rafael.espindola at gmail.com> writes:
>>> +    // Mip64 little endian has a "special" encoding of r_info. Instead of one
>>> +    // 64 bit little endian number, it is a little ending 32 bit number followed
>>> +    // by a 32 bit big endian number.
>>
>> A bit pedantic, sorry, but it's more accurate to say that, on both big
>> and little endian n64, what generic ELF64 calls r_info is instead a
>> 32-bit symbol index (r_sym) followed by 4 byte fields (r_ssym, r_type3,
>> r_type2, r_type).  It's just that the code is choosing to represent all
>> 5 fields as a single 64-bit integer.
> 
> Well, calling this a "mips endian" has the big advantaged that we can
> patch it in exactly one place in the llvm codebase. If we were to
> instead have the notion of "mips ELF" with other fields instead of
> r_info, many more places would have to be updated.
> 
>> Richard
>>
> 
> Cheers,
> Rafael
> 
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>