[llvm] r226503 - Add r224985 back with fixes.

[Nick Kledzik]

On Feb 12, 2015, at 7:46 AM, Rafael Espíndola <rafael.espindola at gmail.com> wrote:

> On 10 February 2015 at 22:23, Steven Wu <stevenwu at apple.com> wrote:
>> Hi Rafael
>> 
>> It seems this patch breaks Objc completely (again). You will want to add  __DATA,__objc_classrefs to your list.
>> __objc_classrefs section stores pointers to Objc class and it requires a label for every pointer in the section.
>> For example, assembly code from objc contains multiple sections of code looks like:
>>   .section  __DATA,__objc_classrefs,regular,no_dead_strip
>>   .align  3                       ; @"OBJC_CLASSLIST_REFERENCES_$_"
>> L_OBJC_CLASSLIST_REFERENCES_$_:
>>   .quad _OBJC_CLASS_$_A
>> 
>> After this patch, all the pointer gets merged under one temp label. Linker might fix up that label and objc class cannot be correctly indexed anymore.
>> “L_OBJC_CLASSLIST_REFERENCES_*” doesn’t have to be kept but every pointer in that section needs a ‘l’ or ‘L’ label.
>> Let me know if you want a PR for this issue as well.
>> 
> 
> Nick, why are linker visible labels required in this case? Only on
> AArch64? The section is marked no_dead_strip, so what is the linker
> doing (or failing to do) that breaks?
The section contains just pointers (to classes) (like a GOT). The linker coalesces duplicate pointers across translation units.  The linker knows to break up the section into pointer sized atoms, regardless of labels.

The problem is that the assembler is adding a ltmpNNN label at the start of the section, then using extern relocations to reference any pointer.  For instance an ADRP to the third pointer in the section looks to the linker like:  
     ADRP x8, ltmp123 + 16

The symbol ltmp123 gets associated with the first pointer, after coalescing  ltmp123 + 16 can wind up pointing to the wrong pointer.

It might work to have zero labels in that section (although that has not been tested), or to have labels on each pointer (for use by the ADRP references).

-Nick

> 
> Steven, can you try the attached patch?
> 
> Cheers,
> Rafael
> <t.patch>