gcc 1.38 & Roell's X11r4 server

[Thomas Roell]

>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 at lan.informatik.tu-muenchen.de
UUCP (when above fails): roell at tumult.{uucp | informatik.tu-muenchen.de}
famous last words: "diskspace - the final frontier..."