Re: [Dri-devel] Re: OpenGL and the LinuxThreads pthread_descr structure

[Jakub Jelinek <jakub at redhat dot com>]

On Fri, May 17, 2002 at 12:30:56AM +0100, Keith Whitwell wrote:
> > BTW: Last time I looked at libGL (in March), these were things which I
> > came over:
> > 1) libGL should IMHO use a version script (at least an anonymous one
> >    if you want to avoid assigning a specific GL_x.y symbol version to it),
> >    that way you get rid of thousands of expensive run-time relocations
> 
> Where can I get info on this?

info ld, study glibc sources.

Just checked the latest libGL.so, it has:
 0x00000016 (TEXTREL)                    0x0
 0x6ffffffa (RELCOUNT)                   3615
 0x00000000 (NULL)                       0x0

Relocation section '.rel.dyn' at offset 0x14074 contains 12341 entries:

This effectively means libGL.so is not a shared library at all and takes
awfully lot of time to load during program startup.

What you can and should do:

create either linker script like:
{ global: gl*; DRI*; XF86DRI*; local: *; }
or
GL_1.0 { global: gl*; DRI*; XF86DRI*; local: *; }
then pass this file to linker at libGL.so link time, like
gcc -shared ... -Wl,--version-script,libGL.map ...

This way you get rid of most R_386_PC32 relocations, etc.
If libGL.so is compiled with -fpic, you should also in headers prototyping
the internal functions add __attribute__((visibility("hidden")))
to the prototypes, so that gcc can avoid setting up pic pointers
when calling the internal functions. I think most of the functions are
prototyped using macros, so it wouldn't be much work.

When you are calling the exported functions internally and there is no
reason why applications should be able to interpose those symbols, create
internal aliases for them (like __gl* or __internal_gl* or whatever) and
use them instead (again, can be seen a lot
in glibc sources and helps a lot).

> How do you detect threading without making these calls to libpthreads.so?

Weak symbols.

extern pthread_t pthread_self (void) __attribute__ ((weak));

(resp. #pragma weak pthread_self).
Then if (&pthread_self) { application was linked against -lpthread } else { not threaded }
Note all calls to pthread library has to be weak.

> > 3) I don't think building without -fpic is a good idea, 1) together with
> >    other tricks might speed things up while avoiding DT_TEXTREL
> >    overhead
> 
> The thing that really bites with -fpic is the bs you have to go through to get
> access to static symbols (forgive my loose terminology) like static variables
> or other functions you want to call.  Gareth's trick means that two very
> important variables avoid this, but it's still going to be necessary to call
> other functions often enough...

Well, if you use the above things, then calls to other functions local
to libGL.so (something like static functions, though they can be
used accross different .o files in the whole library) will be simple
call instructions, no need to setup pic pointer or anything.
For static data variables I'd have to check libGL assembly,
surely something can be done for the functions where this matters.
Note that libGL is typical library using tons of macros where by
changing the macros you can easily tweak most of the functions which matter
for performance (so it is very good to study closely the resulting
assembly).

> 
> > There were some other things, but I don't remember it very well. If I find
> > time I'll build libGL again and check the disassembly.
> 
> As someone who 1) is concerned about libGL performance and 2) doesn't know
> much about relocation/fpic/pthreads/etc, I'd love to hear anything you've got
> on this.

If you don't use -fpic, libGL.so is basically not shared, takes way much
time to load and eats moer unshareable memory. There are
ways how you can combine the advantages of -fpic without
taking the performance hit.

	Jakub