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 17:45:59 -0400
- Thread-topic: dead-code stripping, pass two...
> In any case, with all the "best practices" settings in place, the
> project I referenced that was 88k under CW is still a 600k Universal
> after stripping symbols. So call it 300k adjusted for a single binary.
> That's a 3.4 times size increase under Xcode. If I look at the
> pre-stripped binary, it's very clear that stuff that is not needed is
> being linked in. In fact, using the disassembly and adding conditionals
> was how I got it down from an initial 1.6 meg to 600k.
That 3.4x data point is really interesting--as well as shocking.
> 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.
Yeah, that sums up--if I'm not mistaken, theory says that its impossible to
do full stripping w/o an iterative approach. I started a couple threads on
this topic (and how ld seems to be deficient in this area). There was
definite interest in those threads (as well as a number of people that
emailed me offline asking me if I ever found any solutions).
http://lists.apple.com/archives/xcode-users/2006/Jan/msg00953.html
http://lists.apple.com/archives/xcode-users/2006/Feb/msg00180.html
You can summarize those threads exactly as what you wrote:
> 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.
Yes, it would be great for Apple to weigh in. Someone who shall remain
nameless once joked to me that you know if you're onto a legit issue when
you don't get any Apple (official or non-official) posts on the subject.
Our best bet is for each of us to file a radar for better/smarter linking,
stripping, and GUI interaction using our own words and links to relevant
lists.apple.com posts. It's the only real channel we have for Apple's
linking and stripping tools to actually get improved.
The link and strip issues are clearly very important to all of us that have
chimed in on these threads, so we each need make a radar on it. I've just
created a new one myself (rdr://4555786).
>
> 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.
Exactly. Steve, if you can get a sample project exhibiting the problem,
that's money in a radar report.
Andy
>
> 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
>>>>
>>>>
>>>
>>>
>>
>> _______________________________________________
>> 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
>
>
_______________________________________________
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