This is the mail archive of the
mailing list for the GCC project.
Re: A Linux/libc 5 patch for egcs 1.1.2
- To: "H.J. Lu" <hjl at varesearch dot com>
- Subject: Re: A Linux/libc 5 patch for egcs 1.1.2
- From: Jeffrey A Law <law at hurl dot cygnus dot com>
- Date: Fri, 05 Mar 1999 01:06:51 -0700
- cc: Ulrich Drepper <drepper at cygnus dot com>, egcs-patches at egcs dot cygnus dot com
- Reply-To: law at cygnus dot com
In message <36DED6BD.62BCEE28@varesearch.com>you write:
> That is ok as long as the one file in libio from egcs has more symbols
> than the same file in libc 5.4.46.
Huh? The number of symbols has nothing to do with the problem. It is the
scoping of symbols that drives the linking process.
For this particular bug to expose itself the following must occur:
The user's code must reference a function that is not in libstdc++, but
which is in libc (putc in the testcase).
The file containing that definition in libc must also define a non-weak
symbol that is found in libstdc++ (_IO_putc in the testcase)
That non-weak symbol must have already been defined by some file in
libstdc++ that was included before the inclusion of its definition in
libc (ioputc.o in this case).
So, if we return our attention to the files which do not have any weak
symbols, but which define functions also found in libc.
First let's look at iogetline.o. It defines:
IO_getline is also defined by libc.a(iogetline.o). However IO_getline is
the only function that is defined by libc.a(iogetline.o). As long as
the ordering of libraries always has libstdc++ before libc, we are safe.
If libc appears first and the user's code references both _IO_getline and
IO_getline_info, then we would lose.
are safe for that symbol too.
IO_file_doallocate is defined in libc.a by filedoalloc.o, but that is the
only symbol filedoalloc.o in libc defines, so we are safe.
defines lots of IO_file_* functions as well as IO_do_write.
Each of the IO_file_ functions as well as IO_do_write is defined by
fileops.o in libc. However the file that defines those functions does
not define any other global symbols, so we are safe.
Similar to fileops.o -- all functions defined by libstdc++::strops.o
are also defined by libc::strops.o. And libc::strops.o does not
define any functions not found in libstdc++::strops.o So we are safe.
I also checked genops.o and we have a potential problem.
Specifically, the following symbols are global in libc's genops.o, but not
defined by libstdc++'s genops.o:
So, if a user's code referenced a symbol defined by both genops.o files
(say IO_setb for the sake of argument) and a symbol defined only by libc'a
genops.o file (let's say IO_sync for the sake of argument), then we've got
a problem since both copies of genops.o would be linked into the program, and
they both have a lot of global symbols in common.
What is the proper way to handle this?