[Fwd: [omniORB] Re: Autoconf Abilities [was Installation and Configuration on RedHat 6.0]]

Stefan Seefeld seefelds@MAGELLAN.UMontreal.CA
Sat Sep 18 11:47:00 GMT 1999


Hi,

I thought this could be interesting. It seems that despite what your
installation page says, compiling with --enable-threads *does* make
a difference outside the objective-C world.

By the way, why isn't this the default setting ? Is there any
overhead introduced by this flag ?

Regards,	Stefan


To : Stefan Seefeld <seefelds at MAGELLAN dot UMontreal dot CA>
Subject : Re: [omniORB] Re: Autoconf Abilities [was Installation and Configuration  on  RedHat 6.0]
>From : Sai-Lai Lo <S dot Lo at uk dot research dot att dot com>
Date : 18 Sep 1999 15:12:26 +0100
CC : omniorb-list at uk dot research dot att dot com
References : <21D757CECBD2D211AD5D00105A2974A765EBD7@EXCHANGE> <37E158BA.32FB9311@econz.co.nz> <37E15AC5.1B26EFA0@magellan.umontreal.ca>

I've actually gone through the trouble of building two versions of
egcs-1.1.2. One version with --enable-threads and the other
without --enable-threads. I then compile the omniORB runtime libraries
with each compiler and compare the object code to see if there is any
difference between the two versions.

Here is my observation:

1. Both versions produce the same object code in the omniORB runtime. *BUT*
2. The gcc runtime libgcc.a differs significantly.
   In particular, the object file *_eh.o and frame.o are different*.
   If one look at the libgcc source, these modules deal with exception
   at runtime and the source code distingushes between threaded and
   non-threaded exception handling.

So despite of what the documentation says about --enable-threads only
affect objective-C, it is not true.

I've also done the same to gcc-2.95. The --enable-threads and the non
--enable-threads version exhibit slightly different
behaviour:

1. Some object files in the omniORB runtime *ARE DIFFERENT*.
   I look at the assembler output of one of these files, the difference is
   that the non --enable-threads version produce code that has 3 entries
   missing in its __EXCEPTION_TABLE__!!

2. Again the _eh.o and frame.o in the gcc runtime libgcc.a differs
   significantly.


To summarise, MAKE SURE THAT YOUR GCC COMPILER IS BUILD WITH --enable-threads!


-- 
Sai-Lai Lo                                   S.Lo@uk.research.att.com
AT&T Laboratories Cambridge           WWW:   http://www.uk.research.att.com 
24a Trumpington Street                Tel:   +44 1223 343000
Cambridge CB2 1QA                     Fax:   +44 1223 313542
ENGLAND



More information about the Gcc-bugs mailing list