On Thu, Oct 09, 2003 at 04:55:25PM +0200, Jakub Jelinek wrote:
>On Thu, Oct 09, 2003 at 12:08:55PM -0400, David Dawes wrote:
>> On Thu, Oct 09, 2003 at 02:05:47PM +0200, Jakub Jelinek wrote:
>>
>> >Looking at various /usr/X11R6/lib/lib*.so* shared libraries,
>> >I'm seeing lots of exported symbols which look like they are exported
>> >just because they cannot be static (as they are used by some other .o files
>> >in the same shared library, but never by anything outside).
>>
>> That is correct.
>>
>> >If these could be classified (e.g. some _X* symbols in libX11.so.6,
>> >some _Ice* symbols in libICE.so.6 etc. might fall into this category),
>> >XFree86 could have smaller and faster shared libraries with less dynamic
>> >relocations, which would not need to set up PIC pointer so often and use
>> >less instructions to access shared library local variables (by bypassing
>> >GOT on some arches).
>>
>> ... and it would discourage applications from using symbols that aren't
>> part of the published interfaces.
>>
>> I'd suggest starting with the library interface specs, exporting
>> only those symbols that are documented as part of the interfaces,
>> and seeing what applications break. If a signficant number of
>> applications do break, that might suggest adjusting the specs to
>> agree with common usage. I had plans of doing this with a linker
>> version script, but it's still fairly low down on my todo list.
>> >From an API point of view, I think it would be better to specify
>> the symbols that should be public, rather than identifying all
>> non-statics that shouldn't be. It'd also be good if this could be
>> implemented for as many of the platforms we support as possible.
>
>Well, both version script and __attribute__((visibility ("hidden")))
>can be used at the same time.
>Anonymous version script works in 2001-12-18 and later binutils
>and AFAIK in Solaris linker. No idea about other arches.
>If you think we should list all exported symbols, then maybe we
>could introduce .sym (or .api) files for each library which would list
>exported symbols one per line and Imakefile hacks to generate version
>scripts/whatever else on the fly and use it during linking.
That sounds like a good approach.
There are two ways that this is already done for some platforms. OS/2
and Cygwin use files like X11-def.cpp to list the exported symbols.
Those lists might be a good starting point, but I suspect that more
symbols are exported than are documented in the API specs.
Also, X11R6.3 added export description files (like libX11.elist), together
with scripts for a few platforms like Solaris, HPUX and AIX to process
them. The .elist files are only provided for libX11 and libXt, and they
simply export all globals. I don't know if the basic mechanism is worth
reusing -- you should look at it and see what you think. They don't
provide any useful information about what symbols should be exported
for each library though.
>In addition to that, at least non-static but not exported variables
>should be marked with X11_LIBRARY_LOCAL (or whatever other macro you prefer;
>__HIDDEN__ is IMHO bad since it is OS implementation namespace),
>for functions unless their address is taken it is much less important.
>
>Now, is there some easy way how can the initial .api/.sym files be created
>from the specs (exported headers or doc/specs or something else)?
>When that's done, I can surely first see what other symbols other
>XFree86 libraries need and then harvest some Everything install distribution
>for other symbols.
The *-def.cpp files are probably as good a starting place as any, since
these are actually used for the OS/2 and Cygwin ports.
>Second thing is how to define Imakefile macros which will enable
>__attribute__((visibility ("hidden"))) and/or version scripts.
>Should they be just user settable, defaulting to no, or should
>imake do the autodetection (for that it needs an autoconf like
>test, since e.g. even when you have GCC 3.3 and later, still
>visibility attribute doesn't have to be supported if that GCC
>was compiled against old binutils, etc.)?
What happens if you use the visibility attribute with a gcc 3.3 that
doesn't have it enabled? If it's simply ignored, then it shouldn't be
an issue. Otherwise, is there no pre-defined macro so that you can test
for it in the source?
If a gcc version check plus gcc feature macro check isn't an option,
then I'd suggest adding an imake switch for now, and default it to off.
Autodetection could be added to imake too.
It'd be nicer if we had a mechanism for caching that information so that
imake could do these tests once rather than hundreds of times per build.
But nobody seems interested in the incremental approaches for achieving
auto-config'd XFree86 builds :-(. But I digress.
David
--
David Dawes X-Oz Technologies
www.XFree86.org/~dawes www.x-oz.com
_______________________________________________
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
