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
