__cxa_atexit prototype

[Jim Dehnert]

> Date: Thu, 16 Dec 1999 21:03:48 +0100
> From: Martin von Loewis <loewis at informatik.hu-berlin.de>
> To: mark at codesourcery.com
> 
> >   The type of __cxa_atexit involves a type `dso_handle'.  This type is
> >   undefined.  
> > 
> > Suggested Resolution:
> > 
> >   Replace all occurrences of this type with `void *'.
> 
> There is another issue here. I tried implementing this approach in
> gcc, for x86 ELF32 (Linux in particular), and found it
> unimplementable; maybe I was just stupid.
> 
> The problem was to get at the dso_handle, inside the object file for a
> translation unit. Say, crtsomething.o exports a symbol __dso_handle,
> whose address is passed to __cxa_atexit. One copy of crtsomething.o
> gets linked into each DSO. Inside each translation unit, you want to
> get at the address of the __dso_handle defined *in your own DSO*.  I
> understand that -Bsymbolic does that, but requiring -Bsymbolic was
> inacceptable. Does the base ABI offer a better mechanism?

The generic ABI has been modified (by the IA-64 ABI group) to add an
"export class" to symbols.  One of the possible settings of the export
class is "protected," which means that references from within the
executable being linked are linked to the copy defined in that
executable, and not subject to preemption by a symbol from another DSO.
That is, it is the -Bsymbolic effect on a per-symbol basis, and can be
set by the compiler.

The solution, then, is that the __dso_handle symbol generated by the
linker (or some runtime module) is made protected.  Obviously, this
requires implementation of the new symbol export class feature.

(The other new export classes are "hidden," which are symbols visible
only from within the same executable object and are converted to LOCAL
or removed by the linker, and "internal," which are at least as
restricted as hidden, with the psABI allowed to apply further
restrictions.  The MIPS psABI requires that objects named by internal
symbols not be referenced from outside the linked object, either by
name or via pointers passed out.  In fact, therefore, __dso_handle
could be made either protected or hidden, and hidden might be cleaner.)

Jim

-	    Jim Dehnert		dehnert at sgi.com
				(650)933-4272