From owner-freebsd-current  Mon Dec 18 21:03:56 1995
Return-Path: owner-current
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id VAA22127
          for current-outgoing; Mon, 18 Dec 1995 21:03:56 -0800 (PST)
Received: from rocky.sri.MT.net (rocky.sri.MT.net [204.182.243.10])
          by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id VAA22113
          for <current@FreeBSD.org>; Mon, 18 Dec 1995 21:03:52 -0800 (PST)
Received: (from nate@localhost) by rocky.sri.MT.net (8.6.12/8.6.12) id WAA25662; Mon, 18 Dec 1995 22:06:19 -0700
Date: Mon, 18 Dec 1995 22:06:19 -0700
From: Nate Williams <nate@rocky.sri.MT.net>
Message-Id: <199512190506.WAA25662@rocky.sri.MT.net>
To: current@FreeBSD.org
Subject: Mis-feature in -current
Sender: owner-current@FreeBSD.org
Precedence: bulk

This one was a strange one, but I finally figured it out.  I'm trying to
build kernels which contain all of the necessary 'debug' symbols in
them, so I'm not compiling the code with '-O'.

However, I've noticed that if you don't compile the code with '-O', gcc
no longer optimizes out the calls to strlen.  What this means is that
the kernel will no longer link if you compile any modules which uses
strlen().

I'd like to add back the strlen() routine to libkern.  Basically, the
linker won't pull it in if the kernel is compiled with optimization
since it won't be needed, but it's available if any routines aren't
optimized.

The reason I think this should be brought in is that the current
behavior of in-lining strlen() is extremely non-intuitive and very GCC
specific.  At least if we add back the strlen() code we aren't depending
on gcc optimizing away the calls.

Any disagreements before I add back strlen to libkern?


Nate