From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Kirkegaard, Knud J" To: "'Richard Henderson'" , "Kirkegaard, Knud J" Cc: "'gcc@gcc.gnu.org'" , "Sehr, David C" , "Saxena, Sunil" , "'cary@cup.hp.com'" Subject: RE: Software Convention Proposal Date: Wed, 21 Aug 2002 14:26:00 -0000 Message-id: <9795DB627281D941B9E608445730DFC804656DA0@fmsmsx106.fm.intel.com> X-SW-Source: 2002-08/msg01272.html Thanks to Richard for the clarification of the rationale. We should also have acknowledged Richard Henderson (Redhat), Cary Coutant (HP) for valuable input and inspiration to the proposal. Once we review the feedback we will send out a response and the proposal updated as appropriate. Knud -----Original Message----- From: Richard Henderson [ mailto:rth@redhat.com ] Sent: Wednesday, August 21, 2002 12:04 PM To: Kirkegaard, Knud J Cc: 'gcc@gcc.gnu.org'; Sehr, David C; Saxena, Sunil Subject: Re: Software Convention Proposal 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 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= But I'd prefer switches that differed slightly. Perhaps -fvisibility=protected -fvisibility-default= 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~