This is the mail archive of the libc-hacker@sources.redhat.com mailing list for the glibc project.
Note that libc-hacker is a closed list. You may look at the archives of this list, but subscription and posting are not open.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
On Tue, Jun 12, 2001 at 04:38:31PM +0200, Andreas Jaeger wrote: Speaking of GLIBC and GCC 3.0, we should I think finally decide what to do, because even if GCC 3.0 compiler GLIBC passed all tests, it will still be binary incompatible (e.g. __frame_state_for symbol will be missing) and it would be bad if someone started shipping GCC 3.0 compiler GLIBC without these issues sorted out. Richard has included _Unwind_Find_FDE API in libgcc_s, so __frame_state_for can be built on top of that. Doing so requires glibc to have a copy of gcc old-style dwarf2 unwinder updated so that it copes with newly generated unwind directives. Then, I think we have the following options: - glibc will be linked without special options and appart from __frame_state_for no other unwinding symbols will be exported from glibc. Like this, glibc will have DT_NEEDED libgcc_s.so.1 which will provide the whole interface and just glibc's __frame_state_for will use _Unwind_Find_FDE to locate FDEs. The advantages of this are that libgcc_s can be simply upgraded, __frame_state_for code will have to be checked only if glibc is recompiled with newer gcc. The disadvantages include bigger memory footprint of every application and bigger startup times due to one more shared library included in each program. - like the above, but libgcc_s.so.1 is DT_FILTER of glibc (requires the current GLIBC semantics of DT_FILTER, not the one Solaris uses) - libgcc_s has to be found in this case - glibc will be linked with -static-libgcc and will export the usual __register_frame_info@@GLIBC_2.0 etc., and __register_frame_info_bases@@GCC_3.0 __deregister_frame_info_bases@@GCC_3.0 __register_frame_info_table_bases@@GCC_3.0 _Unwind_Find_FDE@@GCC_3.0 Like this, glibc does not have to be linked to libgcc_s at all, but if any library is linked against libgcc_s, it will find its FDEs just fine - like the above, but libgcc_s.so.1 is DT_AUXILIARY (in the GLIBC semantics of DT_AUXILIARY) of glibc. Jakub
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |