[PATCH] Re-enable a hook in MCELFObjectTargetWriter to allow target-specific relocationtable sorting and use this hook for Mips.

[Rafael Ávila de Espíndola]

Please check the excellent description Simon gave of what are the restrictions in the thread about  r205200.

>From that thread, my understanding of what is odd about mips objects in this case is that a a lo relocation (R_MIPS_LO16, R_MIPS16_LO16, R_MICROMIPS_LO16, R_MICROMIPS_HI0_LO16) matches *all* preceding hi/got relocations (R_MIPS_GOT16, R_MIPS16_GOT16, R_MICROMIPS_GOT16, R_MIPS_HI16, R_MIPS16_HI16, R_MICROMIPS_HI16).

Now, what is the semantic of the assembly file? From this code it looks like it is that a lo relocation would match *any* hi relocation with the same symbol if one is present. The search is done on an unordered relocation array, so which one it matches is undefined.  This would still be an issue since the mips output will now be non-deterministic, no?

It that is really the desired behavior, you could just

- Sort by symbol.
- If same symbol, sort by type to put HI before LO
- sort by whatever else to make the output deterministic.

The current implementation is also N^2.

It should handle (and test) all relevant relocations.
It should include a large comment explaining

- What are the semantics of the .o (i.e., how will the linker handle them. Something along the lines of Simon's description)
- What are the semantics of the .s files.
- What the code is doing to match one to the other.


REPOSITORY
  rL LLVM

http://reviews.llvm.org/D7414

EMAIL PREFERENCES
  http://reviews.llvm.org/settings/panel/emailpreferences/