MIPS executables linking support

[GoogleCodeExporter]

Branch name: mips-plt

Purpose of code changes on this branch:
The mips-plt branch contains MIPS executables linking support implementation. 
Some parts of ABI (like consistent function's address, .MIPS.stubs section etc) 
have not been implemented yet. But now MCLinker is able to produce worked MIPS 
executable files. For example, I successfully link make, vim and some other 
tools.

When reviewing my code changes, please focus on:
The only MCLinker core code change is in the GNUInfo.h file. The 
GNUInfo::ABIVersion() function is virtual now.

After the review, I'll merge this branch into:
master

Original issue reported on code.google.com by si...@atanasyan.com on 30 May 2013 at 11:38

[GoogleCodeExporter]

Hi, Simon,

I review the branch. Everything looks good to me. I think you can merge them 
into the `master` branch.

I have a question. I saw Mips relocation type use all 255 numbers.

{ &pc32,       248, "R_MIPS_PC32",                  0},
{ &unsupport,  249, "",                             0},
{ &unsupport,  250, "R_MIPS_GNU_REL16_S2",          0}, 
{ &unsupport,  251, "",                             0}, 
{ &unsupport,  252, "",                             0}, 
{ &unsupport,  253, "R_MIPS_GNU_VTINHERIT",         0}, 
{ &unsupport,  254, "R_MIPS_GNU_VTENTRY",           0} 

I'm defining a new ELF format for heterogeneous system architecture (HSA). At 
the beginning, I want to use > 163 number as the new HSA relocation type. Now I 
see Mips has already used some relocation whose type >163, therefore I will try 
the other way to define HSA relocation type. I just want to know why Mips 
architecture leave so many `holes`? Does Mips use all 255 types? Is there some 
ranges of relocation types reserved by Mips architecture?

Best regards,
Luba

Original comment by LubaTang on 31 May 2013 at 10:05

[GoogleCodeExporter]

Thanks for your review. I have pushed my changes to the master branch at 
revision f003d0c85ad6.

As you can see MIPS relocations are joined into a few groups. As far as I 
understand, when somebody invent/implement MIPS16 relocations, he just skipped 
some entries (52-99) and created MIPS16 relocations starting from 101. The same 
thing was repeated by somebody else for microMIPS relocations. So the holes are 
result of lack of coordination between different MIPS developers.

Sure MIPS does not use all 255 relocations. The full list are in the 
MipsRelocationFunctions.h file now.

Original comment by si...@atanasyan.com on 31 May 2013 at 1:11

• Changed state: Fixed