[patch] Use "new style" stubs on ppc too

[Rafael Espíndola via llvm-commits]

Thank you so much for testting. Committed as r270205.

Cheers,
Rafael


On 19 May 2016 at 09:13, Iain Sandoe <iain at codesourcery.com> wrote:
> Hi Rafael,
>
>> On 18 May 2016, at 12:49, Rafael Espíndola <rafael.espindola at gmail.com> wrote:
>>
>> On 18 May 2016 at 06:58, Iain Sandoe <iain at codesourcery.com> wrote:
>>>
>>>> On 17 May 2016, at 17:18, Rafael Espíndola <rafael.espindola at gmail.com> wrote:
>>>>
>>>> X86 and ARM switched to using the same section for stubs of hidden and
>>>> non hidden symbols.
>>>>
>>>> This patch does the same for ppc.
>>>>
>>>> Cheers,
>>>> Rafael
>>>> <t.diff>
>>>
>>> Looks like a nice cleanup, it’s just a little hard to be certain of the consequences of the change:
>>>
>>> 1. The current behaviour does match what the last gcc-4.2 powerpc toolchain produces.
>>> 2. Did testing throw anything up? (I somehow doubt it without any runtime-tests)
>>
>> No. In fact that one test that changes was added by me to show the
>> difference. It was completely untested.
>>
>>> 3. If the symbol is visible, then it’s potentially interposed, so I guess the issue is whether the non_lazy_symbol_pointer section is writeable for that purpose, which means that dyld might be the determining factor.  (That it works with x86 [on darwin9?], suggests this is OK).  Probably, the best thing is to try some checks on older systems (will try to do that in the next few days).
>>
>> Thanks!
>
> OK; So what I think is sufficient is
>  (a) a link test with the change .. and
>  (b) that the resultant exes DTRT .. and
>  (c) other changes are agreeable.
>
> So I made a trivial testcase (attached) with:
>  an object referring to an extern and a hidden extern.
>  a mainline that calls into that object and declares the two vars.
>
> The code generated for the object is very similar to your .ll
>
> So then I hand-edited the .s file to mimic the amendment (also have to comment out the .macosx_version_min directive which the older tools can’t handle).
>
> I don’t think we need to evaluate any tools earlier than 10.5’s ld64 (because even 3.4 LLVM is unbuildable on 10.4 without updating ld64 to at least that).  TBH we’re only doing even that as a matter of principle, since the modern LLVM toolchain is really not viable with that vintage of tools (and I’ve updated my ported set to cctools-887.8 + ld64-253.9 in the last day or so).
>
> Anyway - using gcc-4.2 from 10.5 (ld64-85.2.1, cctools-698.1)  (used gcc-4.2 to assemble the modified .s as well).
> linked both :  OK - so we pass on (a)
>
> both exes run on 10.5 : OK - so we pass on (b).
>
> (c) is kinda interesting.
>   - the size of the data section reduces by 4 bytes “yay!” (-4 for the indirect in __DATA)
>   - however the on-disk exe size increases by 4 bytes “boo” (+4 in the symbol ptr section + 4 in the linkedit section)
>
> Hard to call which is the better one to optimise .. the exe size is part of the footprint, at least at startup - I suppose we’d have to see what the typical percentage growth was on sth like clang to see if there was a real impact.  That assumes that private externs are a significant part of the data usage (possibly could be the case for c++).
>
> Anyway, from my PoV, the change LG;
>
> Iain
>
>
>
>
>
>