[PATCH] Correct re-applying relocations on MIPS platforms

[Kaylor, Andrew]

Hi Petar,

Thanks for the explanation.  It all makes sense now.

Please add comments in the code explaining how and why this work and then feel free to commit.

Thanks,
Andy

-----Original Message-----
From: Petar Jovanovic [mailto:Petar.Jovanovic at imgtec.com] 
Sent: Wednesday, July 24, 2013 2:38 PM
To: Kaylor, Andrew; llvm-commits at cs.uiuc.edu
Cc: David Tweed
Subject: RE: [PATCH] Correct re-applying relocations on MIPS platforms


________________________________________
From: Kaylor, Andrew [andrew.kaylor at intel.com]
Sent: Wednesday, July 24, 2013 10:56 PM
To: Petar Jovanovic; llvm-commits at cs.uiuc.edu
Cc: David Tweed
Subject: RE: [PATCH] Correct re-applying relocations on MIPS platforms

> I have some concern about your introduction of R_MIPS_UNUSED1 and R_MIPS_UNUSED2.  Are those values really not used in the ABI definition?
> Are they specifically defined as reserved for implementation-specific use?

Hi Andy,

yes, these values are really not used, and they are not in the MIPS ELF ABI.
The values were previously defined and used on Irix.

The names of the relocations might not seem correct, but these are the real names. See MIPS elf.h in Linux kernel:

http://lxr.free-electrons.com/source/arch/mips/include/asm/elf.h#L78


> It's not clear to me why you are reading from '*TargetPtr' instead of '*Placeholder'.
> Do these relocations operate on the same location or otherwise depend on something written by a prior relocation.
> If so, please say so in a comment where the relocation is handled.

This patch is much based on r182800 and change for ARM in which they also experienced issues with stubs. See Tim's comment at:

http://llvm.org/bugs/show_bug.cgi?id=16013#c1


> Also, it's not entirely clear to me how this handles the situation where the generated code (and the stub along with it) gets moved to a new address.
> I think, after puzzling over the code, that it works because the relocation is based on a relative address of two items that will always be moved together, but as I said it isn't entirely clear to me.
> Some additional comments explaining how this works would be helpful.

R_MIPS_UNUSED1 and R_MIPS_UNUSED2 are very much similar to R_MIPS_HI16 and R_MIPS_LO16, with the difference that they do not take any addend into account.
This means that they do not need to read any data encoded in the instruction, and the Value they get in resolveMIPSRelocation is the location of the address they need to load into.

Generated stub uses two instructions to read this value, thus we have two relocations (previously, without relocations being applied multiple times, we used R_MIPS_HI16 and R_MIPS_LO16).

Regards,
Petar