Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!clyde.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!ira.uka.de!fauern!lan!roell
From: roell@informatik.tu-muenchen.dbp.de (Thomas Roell)
Newsgroups: comp.unix.sysv386
Subject: Re: gcc 1.38 & Roell's X11r4 server
Message-ID: <6393@tuminfo1.lan.informatik.tu-muenchen.dbp.de>
Date: 7 Jan 91 09:29:56 GMT
References: <52314@bigtex.cactus.org>
Sender: news@lan.informatik.tu-muenchen.dbp.de
Organization: Inst. fuer Informatik, Technische Univ. Muenchen, West Germany
Lines: 81
In-reply-to: james@bigtex.cactus.org's message of 6 Jan 91 00:17:30 GMT

>The first patch fixes a bug in gcc wherein static uninitialized local
>variables are put in .bss instead of .data.  The difference is moot
>unless you're trying to build a shared library.

Hmm... I got also to this problem soon after gcc 1.38 was released. But I found
some different solutions:

a) Adding a flag to gcc (-mnobss) so that gcc generates no code for the .bss
   segment. Is is not good, cause it's only a partial fix, and may no apply to
   other c-compilers.

b) Letting ld(1) change the .bss contents into initialized date. This looks
   like this:

	ld -rx ifile file.o -o shared/file.o    

   with ifile:

	SECTIONS {
		.text : { *(.text) }
		.data : { *(.data .bss) }
		.bss  : {}
		}

   But for a reason I don't know the mkshlib(1) utility the fails when
   creating lib???_s.a with the message:

	cannot take OVERLAY section as input (or something like this)

   I assume this is a bug in ld(1).

 
c) Adding explecitely a section .bss to the shared lib. This fails with a
   coredump, when trying to execute a client. This may also be caused by
   uninitialized pointers mentioned below. Besides this would take to much
   run-time space...

d) (My favourite) Writing an utility that takes a coff-files as input that
   adds the .bss section to the .data section (like b)). I'm working on this,
   cause this would be the general solution.


>The next set of patches fix some indirect calls through uninitialized
>variables in the X libraries.  There might be more of these: they are
>hard to find via regular expression searches.

I cannot believe this. Because I'm working on the problem above I had no time
to look at this problem. But let me here say what really *should* happen:

   o In import.h there is an indirection define, which redirects every call
     to functions that can not be referd as absolute to a pointer.

   o Also in import.h the are some declarations like:

	extern int uname();

     This is neccessary, cause a common c-praxis is to omit the exern declation
     of of funtion that returns int, or is type-casted when called. The bad
     thing is that this fails, if we redirected the function-call via a
     pointer. Thus we make here some explicitely declarations.

   o Any further REDECLARTION in the main c-file (that's what is mentioned in
     the original article) should have NO effect, except that there might be
     warnings. The c-compiler should generate either a unresolved reference to
     this pointer, or a  reference to a common symbol. Both cases lead to the
     same effect, the pointer is referenced as the one that's really in
     globals.c.

   o Any further REDECLARTION WITHOUT extern will be a problem, cause then a
     local symbol is generated. That will be the reason for jumps over non-
     initialized pointers.

My question is now, does gcc 1-38 anything other ????

- Thomas

--
_______________________________________________________________________________
E-Mail (domain):	 roell@lan.informatik.tu-muenchen.de
UUCP (when above fails): roell@tumult.{uucp | informatik.tu-muenchen.de}
famous last words: "diskspace - the final frontier..."