Re: egcs on AIX: native or gnu ld?

[David Edelsohn <dje@watson.ibm.com>]

>>>>> Andrey Slepuhin writes:

Andrey> Well, GLOBAL__DI/DD symbols are automatically exported by collect2. But
Andrey> what
Andrey> about __eh_<something> symbols, which are defined for each object file
Andrey> and
Andrey> are global bss symbols? Should I export them or they can be omitted?

	You do not need to know the details of XCOFF objects, that already
is implemented in collect2.  I guess that I do not understand exception
handling and how __eh_* symbols are handled well enough to know if they
need to be exported.  Someone who understand the C++ implementation needs
to examine this.  A symbol needs to be exported if it will be referenced
by name outside its module.  If one module somehow gets a pointer to a
symbol in another loaded module through its own list of transfer vectors,
for example, export is irrelevant.  Only if the linker/loader needs to
resolve named symbols across modules does export become an issue.

	If C++ applications have the names of __eh_* symbols in other
modules compiled in, then it would seem that exports are necessary.  In
that case, one needs to expand collect2.c:scan_prog_file() to add __eh_*
symbols to the export list along with constructors and destructors.

	Again, I am not an expert on C++ internals and I do not know how
the __eh_* symbols interact with the other exception handling
implementations that have evolved.  PowerOpen/XCOFF ABI functions already
have traceback tables at the end of each function and IBM's XLC uses that
to walk the stack for exceptions.  This could be used in the same way as
the DWARF 2 frame unwind information for non-sjlj exception handling.  I
do not forsee having time to work on this at any time in the near future,
but it is an open project to improve AIX support.

David