From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrey Slepuhin To: David Edelsohn Cc: egcs@cygnus.com Subject: Re: egcs on AIX: native or gnu ld? Date: Sat, 18 Oct 1997 13:24:00 -0000 Message-id: <34492834.BA7DDDC4@msu.ru> References: <9710172147.AA20954@rios1.watson.ibm.com> X-SW-Source: 1997-10/msg00828.html David Edelsohn wrote: > > Most of your questions deal with G++ implementation issues which I > cannot address. I really do not know how -frepo works or about additional > files it creates and how linkers other than GNU ld are suppose to handle > them. It sounds like at least some of the features of G++ are relying > upon GNU ld or SVR4/ELF-like linkers. -frepo option applies also -fno-implicit-templates option and cause g++ to generate for each source file .rpo file with a list of needed templates. The linker (or linker driver in the case of native linker) looks at this list and at the result of link stage, marks what templates really must be instantiated in each module, then recompiles source modules and repeat the process until success (i.e. until there will be no undefined symbols). Well, I discover that passing -bnoquiet option to AIX linker I'll get better results. The only problem is that I receive messages like the following: ld: 0711-319 WARNING: Exported symbol not defined: _GLOBAL_.I.f__Fv ld: 0711-318 ERROR: Undefined symbols were found. The following symbols are in error: Symbol Inpndx TY CL Source-File(Object-File) OR Import-File{Shared-object} RLD: Address Section Rld-type Referencing Symbol -------------------------------------------------------------------------------- _GLOBAL_.I.f__Fv [2] ER DS ccMav3Ma.c(/tmp/ccMav3Ma.o) 00000004 .data R_POS [16] __CTOR_LIST__ ER: The return code is 8. Manually relinking files once more I obtain correct exexutable (If extra pass is needed why not to do it automatically?). Unfortunately, -frepo option is bad documented :-( > The _GLOBAL__DI/_GLOBAL_DD symbols invoke the global constructors > and destructors for a shared object and are exported for AIX. Because > each shared object will contain those same entry points, they will be > duplicated and the AIX linker will warn about them. In AIX 4, the linker > now announced a lot more warnings about these type of issues which always > were produced by GCC. Well, I undestand this, but if I link my program with several shared objects, can I be sure that global constructors/destructors code will be called for each object? > | 5) What about including support of shared libraries with native ld to the > | future snapshots of egcs? Now I am using hacked version of system script > | makeC++SharedLib, but it only needed for generating correct exports > | list. At least, I have no problems yet with shared libraries built with > | native ld. > > To what type of support of shared libraries are you refering? > Specifically creating an export list? Because AIX's XCOFF object file > format has finer granularity about the visibility of symbols than ELF, it > takes more work to make it behave like other Unix systems where all global > symbols are visible outside the module. > > I am not sure that the FSF would be allowed to include a modified > version of AIX XLC's makeC++SharedLib script, but if you were to > reimplement the functionality for G++ as makeG++SharedLib, it probably > could be included in the egcs distributions and installed automatically. As I understand, the main goal of makeC++SharedLib script is to provide correct calling of global constructors/destructors. In egcs this task is done by linker driver, which generates extra code to do this. So, the only problem is to generate correct export list, and makeC++SharedLib do this simply by piping nm output to awk. This can be easy included in egcs linker driver. Moreover, we do not need to omit some special symbol names (but may be we must omit others? linker driver for AIX automatically exports some symbols, but I don't know what rules it uses to do this). But I am seriously worried about strange segmentation faults of omniORB linked with shared libs built with gnu ld. For example, while debugging, I find the following strange situation: in the statement pd_rx_begin = (void*)((omni::ptr_arith_t )pd_rx_begin + total ); // omni::ptr_arith_t=int, total is int, pd_rx_begin is void* (It doesn't look like as a good C++ code, but I'm not author of it :-)) after a number of normal executions once the high byte of pd_rx_begin become zero (all the time total=0) - so later this cause segmentation fault. This may be caused by another thread, but effect is stable, and all works fine with static libraries and also with shared libraries built with native linker. Any ideas? And what about mixing shared libraries built with native ld (always libc, for example) and shared libraries built with gnu ld? Andrey.