This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: A Linux/libc 5 patch for egcs 1.1.2



  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
  IO_getline_info


  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.

filedoalloc.o:
  IO_file_doallocate

  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.

fileops.o:
  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.

strops.o:
  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:

	IO_get_column
	IO_least_marker
	IO_nobackup_pbackfail
	IO_set_column
	IO_sync
	IO_unbuffer_all

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?



jeff
	








Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]