Sort output relocations - Implement -z combreloc

[GoogleCodeExporter]

Our linux environment needs to have relocations in rela.dyn to be sorted for 
working correctly.
This article explains the need (http://people.redhat.com/jakub/prelink.pdf)

The  option -z combreloc is the linker option that is needed.

glibc ld.so also has this as default as  behavior. 

Original issue reported on code.google.com by khem...@codeaurora.org on 9 Aug 2013 at 6:20

[GoogleCodeExporter]

Hi Hemant,

-z combreloc is important. I think we have to support it. -z combreloc is a 
kind of optimization. Diana and I is writing the proposal for pass manager. We 
will post it on the mailing list in recent days. Welcome to discuss it with us.

Original comment by LubaTang on 11 Aug 2013 at 12:40

• Changed state: Accepted

[GoogleCodeExporter]

-z combrel should be performed in between layout and emission

Original comment by LubaTang on 11 Aug 2013 at 12:46

[GoogleCodeExporter]

Yes, it should be done after layout and all sizes etc are finalized. However 
presently we create and destroy the relocations by a "Factory", this means 
nobody can move them around to sort. We will need to figure out a way to get 
around it so that we can sort them. We could also keep a scope in the API to 
accept a Functor that is passed in by backend for any customized optimization.

Original comment by khem...@codeaurora.org on 12 Aug 2013 at 3:21

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Hi Hemant,

I think the difficulty is nothing about the "Factory". About iplist and 
Factory, I have another bucket of stories to tell, but I think let us put our 
eyes back on -z combreloc.

-z combreloc is used to sort output dynamic relocation entries. In MCLinker, 
these entries is stored in RelocData. We can simply sort the iplist of 
mcld::Relocation in RelocData and perform -z combreloc.

Another topic is about transfer a Functor to backend and customize 
optimization. I agree with the direction - we should let backends to be able to 
customize optimizations. And about how to make it, I prefer to follow LLVM. 
LLVM has already illustrate a good approach to do this - mix "builder" and 
"template" design patterns.

In LLVM, backends can use PassConfig to control the timing of passes. The 
relation between PassConfig and PassManager is a kind of "builder design 
pattern". PassManager defines the step of algorithms, and PassConfig provides 
the concrete algorithms. Additionally, PassConfig itself is a template pattern. 
Backends can override PassConfig and customize optimization. I think we should 
follow the design of LLVM, ObjectLinker (or new PassManager) defines the step 
of algorithms, and let backends can customize every steps by overriding 
PassConfig.

Original comment by LubaTang on 13 Aug 2013 at 4:36

• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

Original comment by mysekki on 9 Sep 2013 at 8:36

[GoogleCodeExporter]

Original comment by pete.c...@gmail.com on 10 Sep 2013 at 7:04

• Changed state: Fixed