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 06:01:20PM +0200, Jakub Jelinek wrote: > 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. I have once concern. If glibc has libgcc_s.so.1 in DT_NEEDED, that means the glibc binary will depend on something outside of glibc, which can be changed without the knowledge of glibc. > - 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. If we have to choose between DT_FILTER and DT_AUXILIARY, I prefer DT_AUXILIARY since libgcc_s.so.1 doesn't have to exist. What I'd like to see as an option is 1. gcc 3.0 can be configured not to build its own libgcc_s, but use the system one if it exists. 2. glibc builds/uses/installs libgcc_s out of libgcc.a in gcc 3.0. In this way, libgcc_s becomes the part of glibc. H.J.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |