Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 14 Sep 1998 22:17:00 +0000 (GMT)
From:      Terry Lambert <tlambert@primenet.com>
To:        mike@smith.net.au (Mike Smith)
Cc:        tlambert@primenet.com, mike@smith.net.au, graphix@iastate.edu, freebsd-hackers@FreeBSD.ORG
Subject:   Re: Unused functions
Message-ID:  <199809142217.PAA01956@usr05.primenet.com>
In-Reply-To: <199809141819.LAA00296@dingo.cdrom.com> from "Mike Smith" at Sep 14, 98 11:19:48 am

next in thread | previous in thread | raw e-mail | index | archive | help
> > > It allows the programmer and the C scoping rules to 
> > > work together to determine what should be associated and what need not.
> > 
> > Instead of the compiler merely calculating hamiltonian cycles in
> > the dependency graph to do dead code elimination.
> 
> And if I happen to *want* all of the items in a given object (eg. I am 
> using a scripting language that supports primitive lookup via the 
> symbol table, or any other form of lazy runtime linking)?
> 
> The current rules give the best of both worlds.   Don't fix what isn't 
> really broken.

Dynamic linking requires dlopen, requires a name-to-table-offset
mapping (*not* your standard symbol table mechanism!), and will
work, even on stripped executables.

Yes, dead-code elimination would be "bad" if you were loading
objects that called otherwise dead code in the program address
space (ie: used the program symbol space as a library symbol
space).

In such cases, I suggest you don't use -O2, since the compiler
will do dead code elimination on you within modules if it thinks
it can get away with it right now.

So I think the dynmaic linking case and the static case are two
*very* different cases.


					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199809142217.PAA01956>