Re: dead-code stripping, pass two...
Re: dead-code stripping, pass two...
- Subject: Re: dead-code stripping, pass two...
- From: Steve Christensen <email@hidden>
- Date: Fri, 19 May 2006 16:00:47 -0700
On May 19, 2006, at 8:03 AM, Allen Cronce wrote:
I'd be interested to know is whether or not making any of Andy's
changes
made a difference in your executable size.
I didn't actually use Andy's stripping script. I referenced another
thread that suggested turning on "Symbols hidden by default." When I
did that, my executable sizes (multiple plug-ins) did shrink a bit
more, but not that close to the 2x compared to my old CW build. Also
nm still shows a bunch of unused Carbon API symbols, which I assume
is tied back to unused C++ class methods that reference them, so it
still looks like a lot of leftovers.
My current (relevant) build settings look like this:
Dead Code Stripping YES
Deployment Postprocessing YES
Use Separate Strip NO*
Strip Style Non-Global Symbols
Generate Debug Symbols YES
Level of Debug Symbols All Symbols [full, gfull]
Hidden Local Variables YES
Symbols Hidden by Default YES
Inline Functions Hidden YES
* I've tried this both ways and it doesn't seem to make a difference.
So I still believe that the linker is at fault here. Because if it's
single pass, and if it operates on an object file level instead of the
function/method level, then no amount of project fiddling is going to
help with certain code situations.
I would not be surprised, especially if the linker's been around for
a long time. Perhaps someone who's followed its evolution could
provide more insight.
But honestly I have no visibility into what these tools are really
doing. I really wish that Apple would comment on this issue. Because
either we're missing something with all these complex, interrelated
project options, or something is not working with the tools.
I agree. With all the feedback on other topics, this one has been
amazingly quiet, at least on the Apple side of things.
Steve, have you thought about making a simple sample that proves that
dead code stripping either works or doesn't? I suspect that if you
make
a new project following Andy's recommendations that has an object foo
with an unused method that instances object bar, that the resulting
binary will contain object bar. If dead code stripping *really*
worked,
object bar would not be in the binary.
Yeah, I'd done that awhile back when I first posted to ask about why
dead-code stripping wasn't working so that there could be a sample
for somebody to look at. No takers...
steve
Steve Christensen wrote:
I guess what I'm finding most frustrating is that there doesn't seem
to be a simple way of doing dead-code stripping. And what I mean by
that is -all- unused code and data is removed from the output binary.
Not some of them, a lot of them or most of them.
There seem to be all these magic (for want of a better word)
combinations of settings that have to be just right or the stripping
doesn't work correctly. Developers shouldn't have to burden every
target with a custom script to do what should be either the default
deployment behavior, or at least one that can be turned -fully- on or
off with a simple switch.
I guess my question would be, at this point, do you know what the
compiler and/or linker settings need to be to get the same
behavior as
your script? Or, more correctly, the same thing as a single checkbox
does in CW?
steve
On May 18, 2006, at 9:34 PM, Andy O'Meara wrote:
Well, that script I referenced ensures that symbol stripping
*and* dead
stripping are performed. Point being, there's a number of build
settings
that you need to have set a certain way in order to max out the dead
stripping that 'strip' can perform (and many of those settings don't
jump
out as being directly related to dead-stripping, such as don't make
symbols
public by default).
For example, if you have the flag set that causes unreferenced C++
static
objects code to not get stripped, lots of stuff can (rightfully) get
dragged
in as a result. In general, you have to be one with you code to
have
a feel
for what's getting pulled in. If you use 3rd party libraries,
it's a
lot
more risky to enable aggressive stripping (or else stuff will
start to
break--some devs use unreferenced object and template stuff to do
setup
stuff). But, I do admit, CW had some very aggressive, yet very
smart, dead
code stripping that always just worked -- I miss CW like heck.
Also, if you're comparing gcc's raw binary size to codewarrior's
binary suze
as an indicator of how "good" the stripping is, that may not be
the best
idea. Your best bet may be to disable symbol stripping and then use
atos
(or search the binary manually using a hex editor) to see if a
particular
symbol has been stripped or not.
Once you get the right linker and compiler flags (depending if
you're
doing
external stripping or not), your gcc binaries won't be much larger
than your
CW binaries (swag disclaimer: divide the size of a UB by 2). Mine
are only
about 10-15% larger (my flagship binary under CW was 650k and under
Xcode
the UB is 1450k).
Andy
On 5/18/06 12:30 AM, "Steve Christensen" <email@hidden> wrote:
Yes, I'd seen that thread previously. Unless I am mistaken, the
script is used to strip out all the non-public symbols from a
binary.
It doesn't appear to actually dead-code strip unused code and data,
which is what the linker is supposed to do.
On May 17, 2006, at 8:38 PM, Andy O'Meara wrote:
If you search this list archive, you'll find the below thread
-- it
should
address your questions/problems:
http://lists.apple.com/archives/xcode-users/2006/Mar/msg00552.html
On 5/17/06 10:44 PM, "Steve Christensen" <email@hidden> wrote:
Following another other dead-code stripping thread, I turned on
"Symbols hidden by default" (aka [GCC_SYMBOLS_PRIVATE_EXTERN, -
fvisibility=hidden]) and noticed a reduction in executable size.
However nm is still reporting a lot of API symbols that are only
referenced from unused C++ class methods, so I don't know
where the
reduction actually came from. Thus I'm still kinda in the same
boat
is before.
Any more guesses? :-)
On May 17, 2006, at 2:16 PM, Steve Christensen wrote:
On May 17, 2006, at 2:03 PM, Ladd Van Tol wrote:
On May 17, 2006, at 11:27 AM, Steve Christensen wrote:
I'd asked about this last month and didn't really receive any
responses, so I figure I should try again just in case.
I have a number of plug-in projects I imported from
CodeWarrior
to Xcode as part of making them Universal and all that. They
build and run correctly, but I've noticed that the binary size
has grown considerably more than 2x (in one case going from
around 48K in CodeWarrior to 197K as a UB built by Xcode).
After doing a little more poking around, I found that the
problem
appears to be that unused class methods are not being stripped
out, which means that the method code as well as any that they
reference, etc., etc., gets left in the binary. These are not
virtual methods, BTW.
I have dead-code stripping and symbol stripping turned on, as
well as doing an extra post-link strip pass and specifying an
exported symbols file just to see if that would make a
difference. It doesn't.
Is there some magical incantation that I've missed
someplace? A
known linker bug? A bug in the CodeWarrior project import
process?
This is fairly obvious, but do you have -gfull set?
Yep, or at least that's what the project settings say.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden