Date: Tue, 6 Feb 1996 12:51:25 PST From: "Marty Leisner" <leisner@sdsp.mc.xerox.com> To: Bruce Evans <bde@zeta.org.au> Cc: davidg@root.com, freebsd-current@freebsd.org, jdli@linux.csie.nctu.edu.tw Subject: Re: make world with -fomit-frame-pointer Message-ID: <9602062051.AA03467@gnu.mc.xerox.com> In-Reply-To: Your message of "Mon, 05 Feb 1996 18:31:23 PST." <199602060231.NAA15216@godzilla.zeta.org.au>
next in thread | previous in thread | raw e-mail | index | archive | help
> No, the debugging considerations are the same for the kernel, and the > improvement from -fomit-frame-pointer is less than for average programs > because the kernel does a lot of copying and waiting for cache misses, > and has lots of assembler routines that don't use the frame pointer > anyway. > > > We strip the symbol table from system utilities before installing them > >(making debugging impossible), so why do you think -fomit-frame-pointer will > >make things any worse in this respect? > > The utilities are easy to reconstruct (perhaps even with full debugging > symbols) by recompiling the sources (provided the sources and the compiler, > etc., haven't been changed since the binaries were installed). > I talked about size of stripped/debug/non-stripped in Sys Admin last month... Basically there's a 10x penalty for -g, and a 10% penalty not to strip. At a mimimum, libraries should not be made with -fomit-frame-pointer. It would be desirable not to -fomit-frame-pointer in general on utilties, letting people know they can save about 10% by stripping... If you strip, core dumps are useless...(at least without stripping you have a hint of the problem). I don't think regenerating the binaries is a viable option...its often too difficult where a core dump can yield useful information....for any relatively sophisticated user. -- marty leisner@sdsp.mc.xerox.com Member of the League for Programming Freedom
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9602062051.AA03467>