2008/006: make ld(1) -z combreloc become default behavior

[Joseph Kowalski]

Rod Evans wrote:
> Glenn Skinner wrote:
>>     Date: Mon, 07 Jan 2008 11:09:56 -0800
>>     From: Rod Evans <Rod.Evans at sun.com>
>>     Subject: 2008/006: make ld(1) -z combreloc become default behavior
>>
>>     ...
>>     ld(1) should make -z combreloc the default behavior when creating a
>>     final object (ie., an executable or shared object).  The -z 
>> combreloc
>>     option will still be recognized, but effectively ignored.  A new
>>     -z nocombreloc option will be added to disable the relocation 
>> section
>>     concatenation.
>>
>> Under what circumstances might one wish to use the old behavior?
>
> I have no idea why anyone would want to use the old behavior.  The
> relocation tables within dynamic objects have always been concatenated
> together, and are read by ld.so.1 as one contiguous table.  Creating a
> single table doesn't change how ld.so.1 reads it, it just allows the
> table to be better optimized (sorted).  But, like so many historic 
> artifacts,
> there's always the possibly that someone, somewhere would like the
> old layout.  -z nocombreloc provides this back door - plus, gld provides
> the option too, so in a way we're conforming with gld use.
>
>> What is the compatibility impact of switching this default?
>
> None that we're aware of.  We've used the option ourself throughout the
> OS for years, and have advised others to do so too.  As the gld folks
> have made it their default, I suspect they've found no compatibility
> issues either.  Given this background, making the behavior default
> rather than trying to keep asking developers to use -z combreloc will
> help the startup performance of all dynamic objects (a bit).
>
So, just for completeness, please add a explicit "release binding" to the
case.  It seems that the above provides the rationale for a "Patch Binding"
while changing defaults is usually something reserved for "Minor Binding".

- thanks!

- jek3