Re: dead-code stripping, pass two...
Re: dead-code stripping, pass two...
- Subject: Re: dead-code stripping, pass two...
- From: "Andy O'Meara" <email@hidden>
- Date: Fri, 19 May 2006 00:34:43 -0400
- Thread-topic: dead-code stripping, pass two...
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
>
>
_______________________________________________
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