From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Edelsohn To: Andrey Slepuhin Cc: egcs@cygnus.com Subject: Re: egcs on AIX: native or gnu ld? Date: Mon, 20 Oct 1997 10:49:00 -0000 Message-id: <9710201736.AA35534@rios1.watson.ibm.com> References: <344B2747.579D24EF@msu.ru> X-SW-Source: 1997-10/msg00877.html >>>>> Andrey Slepuhin writes: Andrey> Well, GLOBAL__DI/DD symbols are automatically exported by collect2. But Andrey> what Andrey> about __eh_ 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