PSARC/2007/509 elfedit

[Rod Evans]

James Carlson wrote:

>> while following the "linker herd" is the other.
> 
> That seems like the main reason.

As a historical note, when the 64-bit port originated, ld(1)
followed the isaexec() model.  But this broke the compilers.
The compilers were 32-bit for a long time, and had facilities
that would let sub-processes be timed (using /proc).  When
these facilities came across the automagic execution of a
64-bit ld(1) trouble ensued.

We were forced to abandon isaexec() and invent our own model.
We look at the first relocatable object on the command line,
and if it is 32-bit we remain within the 32-bit ld().  If the
object is 64-bit we kick off an isaexec like function to determine
if the 64-bit ld exists, and if so run it.

There are other tricks at play, as some customers wish to force
the execution of the 64-bit ld (they exhaust the 32-bit address
space even when building their enormous objects).  Some customers
wished to force the execution of a 32-bit ld claiming it was
faster for their enormous objects.

This is all wrapped up in conv_check_native() under sgs.  And as
we like to eat our own dog food, the various other sgs utilities
we work on have adopted using the same routine.


-- 

Rod.