From shmit@natasya.kublai.com  Wed Sep  2 09:18:41 1998
Received: from coleridge.kublai.com (coleridge.kublai.com [207.96.1.116])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA16572
          for <FreeBSD-gnats-submit@freebsd.org>; Wed, 2 Sep 1998 09:18:40 -0700 (PDT)
          (envelope-from shmit@natasya.kublai.com)
Received: from natasya.kublai.com (natasya.kublai.com [207.172.25.236])
	by coleridge.kublai.com (8.8.8/8.8.8) with ESMTP id MAA00306
	for <FreeBSD-gnats-submit@freebsd.org>; Wed, 2 Sep 1998 12:17:38 -0400 (EDT)
	(envelope-from shmit@natasya.kublai.com)
Received: (from shmit@localhost)
	by natasya.kublai.com (8.9.1/8.8.8) id MAA14165;
	Wed, 2 Sep 1998 12:17:38 -0400 (EDT)
Message-Id: <199809021617.MAA14165@natasya.kublai.com>
Date: Wed, 2 Sep 1998 12:17:38 -0400 (EDT)
From: shmit@kublai.com
Reply-To: shmit@kublai.com
To: FreeBSD-gnats-submit@freebsd.org
Subject: Patch to build Objective C library shared
X-Send-Pr-Version: 3.2

>Number:         7811
>Category:       gnu
>Synopsis:       Build Objective C library shared for ELF
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          change-request
>Submitter-Id:   current-users
>Arrival-Date:   Wed Sep  2 09:20:01 PDT 1998
>Closed-Date:    Wed Sep 9 13:40:13 MEST 1998
>Last-Modified:  Wed Sep  9 13:41:05 MEST 1998
>Originator:     Brian Cully
>Release:        FreeBSD 3.0-CURRENT i386
>Organization:
>Environment:

	FreeBSD 3.0 Current w/ ELF.

>Description:

	It was not possible to build the Objective C library shared with
	a.out, because the linker would generate symbol relocation warnings
	that Bruce didn't like. With ELF, I get no such warnings, so I've
	put a conditional in to building that will generate a shared lib
	for ELF, but not for a.out.

>How-To-Repeat:

	1) Apply patches
	2) cd /usr/src/gnu/lib/libobjc
	3) make OBJFORMAT=elf

>Fix:
	
===================================================================
RCS file: /usr/local/cvsroot/FreeBSD/src/gnu/lib/libobjc/Makefile,v
retrieving revision 1.3
diff -c -r1.3 Makefile
*** Makefile	1997/02/22 15:43:02	1.3
--- Makefile	1998/09/02 16:13:22
***************
*** 7,13 ****
--- 7,15 ----
  
  LIB=    objc
  NOMAN=	sorry
+ .if ${OBJFORMAT} != "elf"
  NOPIC=	does not work
+ .endif
  
  SRCS=   archive.c class.c encoding.c hash.c init.c misc.c \
  	my_objects.c sarray.c selector.c my_sendmsg.c \
>Release-Note:
>Audit-Trail:

From: Martin Cracauer <cracauer@cons.org>
To: shmit@kublai.com, FreeBSD-gnats-submit@FreeBSD.ORG
Cc:  Subject: Re: gnu/7811: Patch to build Objective C library shared
Date: Mon, 7 Sep 1998 18:00:41 +0200

 In <199809021617.MAA14165@natasya.kublai.com>, shmit@kublai.com wrote: 
 > 	It was not possible to build the Objective C library shared with
 > 	a.out, because the linker would generate symbol relocation warnings
 > 	that Bruce didn't like. With ELF, I get no such warnings, so I've
 > 	put a conditional in to building that will generate a shared lib
 > 	for ELF, but not for a.out.
 
 Do you really think that makes sense? Remember that each Objective-C
 method call calls a function from the runtime and making it shared
 means one pointer indirection more, with the usual bad cache effects.
 
 Here is a benchmark running small methods, smaller than a method
 normally is, i.e. just adding to an instance variable. I expect this
 benchmark not to show any cache trashing effects that a real
 application may encounter. 
 
 This is an aout system. Sorry for the German strings.
 
 libobjc statically linked:
 1.81 s (99.9%): `call auf id (aufwaermrunde)'
 1.80 s (99.5%): `call auf id'
 1.76 s (99.9%): `call auf id, 4. Subclasse'
 1.76 s (100.0%): `call auf id, 3. Subclasse (vererbte Message)'
 1.61 s (97.8%): `call auf id, 4. Subclasse ohne Parameter'
 1.81 s (99.9%): `call auf id'
 0.84 s (99.9%): `call auf id, 4. Subcl. ueber selector mit parameter'
 0.68 s (99.9%): `call auf id, 4. Subcl. ueber selector ohne parameter'
 1.86 s (100.0%): `call auf id, 4 Subclassen'
 1.82 s (100.0%): `call auf declared'
 3.63 s (100.0%): `call auf id mit id'
 
 libobjoc dynamically linked:
 2.20 s (100.0%): `call auf id (aufwaermrunde)'
 2.18 s (100.0%): `call auf id'
 2.18 s (100.0%): `call auf id, 4. Subclasse'
 2.20 s (98.6%): `call auf id, 3. Subclasse (vererbte Message)'
 1.97 s (99.0%): `call auf id, 4. Subclasse ohne Parameter'
 2.20 s (99.7%): `call auf id'
 0.83 s (95.3%): `call auf id, 4. Subcl. ueber selector mit parameter'
 0.63 s (99.4%): `call auf id, 4. Subcl. ueber selector ohne parameter'
 2.29 s (99.6%): `call auf id, 4 Subclassen'
 2.14 s (100.0%): `call auf declared'
 4.69 s (99.7%): `call auf id mit id'
 
 The lib is < 80 KB. That isn't worth the slowdown, IMHO.
 
 The right thing might be to pull the method lookup functions into a
 seperate library that is static only and the rest into a dynamic
 library, but I think that will break most application Makefiles
 respectivly configure scripts.
 
 Opinions? If noone objects, I would leave it disabled, but change the
 string from 
 
   NOPIC=  does not work
 to
   NOPIC=  works, but method lookup slowdown is significant
 
 Martin
 -- 
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 Martin Cracauer <cracauer@cons.org> http://www.cons.org/cracauer
 BSD User Group Hamburg, Germany     http://www.bsdhh.org/

From: Brian Cully <shmit@kublai.com>
To: Martin Cracauer <cracauer@cons.org>, FreeBSD-gnats-submit@FreeBSD.ORG
Cc:  Subject: Re: gnu/7811: Patch to build Objective C library shared
Date: Wed, 9 Sep 1998 00:34:52 -0400

 On Mon, Sep 07, 1998 at 06:00:41PM +0200, Martin Cracauer wrote:
 > The lib is < 80 KB. That isn't worth the slowdown, IMHO.
 
 You are probably correct. I hadn't done any timings to gauge the
 effects of the slowdown. I'm not sure whether or not it's a good
 idea anymore. Without the shared bits, you lose when changing base
 objects between revisions, which is one of Objective C's strong
 points (due to it's run-time indirection of methods). I don't think
 you run into the FBC that C++ does. Unfortunately, you lose on
 method call overhead.
 
 > The right thing might be to pull the method lookup functions into a
 > seperate library that is static only and the rest into a dynamic
 > library, but I think that will break most application Makefiles
 > respectivly configure scripts.
 
 This is the right thing to do. But:
 	1) This is GNU stuff, and I'm not particularly willing to
 	   maintain libobjc seperately from GNU (nor do I think the
 	   FreeBSD project is willing). So I'd have to write my
 	   own, or find another implementation (preferably with a
 	   nice BSD copyright).
 	2) Even if I were willing, the only way I can see it being
 	   done without breaking everybody's stuff (as you've noted)
 	   would be to make libobjc contain the method lookup function
 	   and link it statically, but have it call dlopen() to find
 	   the object definitions. This would require that all ObjC
 	   apps be compiled shared, which wouldn't be horrific, but
 	   smacks to much of Solaris facism for my taste.
 
 -bjc

From: Martin Cracauer <cracauer@cons.org>
To: Martin Cracauer <cracauer@cons.org>, FreeBSD-gnats-submit@FreeBSD.ORG
Cc:  Subject: Re: gnu/7811: Patch to build Objective C library shared
Date: Wed, 9 Sep 1998 11:09:02 +0200

 In <19980909003452.42389@kublai.com>, Brian Cully wrote: 
 > On Mon, Sep 07, 1998 at 06:00:41PM +0200, Martin Cracauer wrote:
 > > The lib is < 80 KB. That isn't worth the slowdown, IMHO.
 > 
 > You are probably correct. I hadn't done any timings to gauge the
 > effects of the slowdown. I'm not sure whether or not it's a good
 > idea anymore. Without the shared bits, you lose when changing base
 > objects between revisions, which is one of Objective C's strong
 > points (due to it's run-time indirection of methods). 
 
 Hm, I think I would prefer to link statically exactly for that reason:
 The compiler generates code that depends on one specific method lookup
 implementation. You might loose all your working binaries compiled
 with an older compiler when you upgrade to a newer compiler+runtime
 system if libobjc is statically linked. 
 
 Martin
 -- 
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 Martin Cracauer <cracauer@cons.org> http://www.cons.org/cracauer
   Tel.: (private) +4940 5221829 Fax.: (private) +4940 5228536
   Paper: (private) Waldstrasse 200, 22846 Norderstedt, Germany
State-Changed-From-To: open->closed 
State-Changed-By: cracauer 
State-Changed-When: Wed Sep 9 13:40:13 MEST 1998 
State-Changed-Why:  
Shared lib is too costly for ObjC message calls. 
Comment in Makefiles changed to reflect reality. 
>Unformatted:
