Re: Software Convention Proposal

[Richard Henderson <rth at redhat dot com>]

On Tue, Aug 20, 2002 at 03:31:06PM -0700, Kirkegaard, Knud J wrote:
> This is a proposal to take advantage of the performance opportunities
> available to several applications that don't require position independent
> code and the default symbol preemption model described in the ELF ABI.

It would have been helpful if you'd included some rationale.
Since I met with yall to discuss this, I'll summarize quickly:

IA-64, by default, uses PIC data references.  This avoids the
horror of the .dynbss hack used on x86 (and others) to handle
references from the main application to data in shared libraries.
However, this does introduce unnecessary overhead when referencing
data that does in fact reside in the main application.

We do, at present, use gp-relative relocations to the small-data
area when we can show that the symbol must bind locally; this can
be extended trivially to use "movl" to load absolute addresses 
for symbols outside the small-data area, but we must still
restrict this to symbols know to be bound locally.

  [ As a quick data point, Intel prototyped something like
    this in their compiler and got (iirc) a 10-15% improvement
    for a particular application.  ]

So the object of the game here is to extend the set of symbols
that we know binds locally.

With one's own application, it's possible (though not always
trivial, given the size of some applications) to modify all
declarations to include the visibility attribute.

With some buy-in from the OS vendor, it's possible to get the
system headers marked such that if the default binding were
changed on the compiler command line, the system libraries
would continue to bind correctly.

A problem area, however, are third-party libraries.  In that
case, given that we cannot modify the headers, the best we can
do is create a list of the symbols that should be bound a
particular way and present it to the compiler through some side
channel.  E.g. a file associated with a command line switch.

>  -fprotected -fdefault <file> 

I'm not thrilled about using the same switch to mean two
different things.  Certainly you couldn't just leave the
filename unassociated like that.  So at minimum you'd need

	-fprotected -fdefault=<file>

But I'd prefer switches that differed slightly.  Perhaps

	-fvisibility=protected
	-fvisibility-default=<file>

I'd like input from others on this.

> Compiling for "main program" option
> -------------------------------------
> 
> -fminshared
> 
>  This option indicates to the compiler that the module is being compiled
>  for the main program. This allows for absolute addressing of symbols that
>  are protected or hidden.

Err, this is what the lack of -fpic implies.

>  The option implies -fprotected.

This doesn't seem like a good idea.  If you've not done the due dilligence
above, how do you know your system libraries are properly marked?



r~