On Fri, May 13, 2016 at 7:20 PM, H.J. Lu <hjl.to...@gmail.com> wrote:
> On Fri, May 13, 2016 at 9:51 AM, Uros Bizjak <ubiz...@gmail.com> wrote:
>> On Fri, May 13, 2016 at 9:07 AM, Uros Bizjak <ubiz...@gmail.com> wrote:
>>> On Fri, May 13, 2016 at 1:20 AM, H.J. Lu <hjl.to...@gmail.com> wrote:
>>>
>>>>>> testsuite/gcc.target/i386/pr61599-{1,2}.c testcases expose a failure
>>>>>> with -mcmodel -fpic, where:
>>>>>>
>>>>>> /tmp/ccfpoxHY.o: In function `bar':
>>>>>> pr61599-2.c:(.text+0xe): relocation truncated to fit: R_X86_64_PC32
>>>>>> against symbol `a' defined in LARGE_COMMON section in /tmp/ccKTKST2.o
>>>>>> collect2: error: ld returned 1 exit status
>>>>>> compiler exited with status 1
>>>>>>
>>>>>> CM_MEDIUM_PIC code model assumes that code+got/plt fits in a 31 bit
>>>>>> region, data is unlimited. Based on these assumptions, code should be
>>>>>> accessed via R_X86_64_GOT64.
>>>>>>
>>>>>> Attached patch uses UNSPEC_GOT instead of UNSPEC_GOTPCREL also for
>>>>>> CM_MEDIUM_PIC.
>>>>>>
>>>>>> 2016-05-12 Uros Bizjak <ubiz...@gmail.com>
>>>>>>
>>>>>> PR target/61599
>>>>>> * config/i386/i386.c (legitimize_pic_address): Do not use
>>>>>> UNSPEC_GOTPCREL for CM_MEDIUM_PIC code model.
>>>>>>
>>>>>> Patch was bootstrapped on x86_64-linux-gnu and regression tested with
>>>>>> -mcmodel=medium -fpic.
>>>>>>
>>>>>> Jakub, H.J., do you have any comments on the patch?
>>>>>
>>>>>
>>>>> I prefer this patch.
>>
>>> Yes, your patch is more precise.
>>
>> OTOH, are we sure there is no linker bug here? We have:
>>
>> $ objdump -dr pr61599-1a.o
>>
>> pr61599-1a.o: file format elf64-x86-64
>>
>>
>> Disassembly of section .text:
>>
>> 0000000000000000 <main>:
>> 0: 55 push %rbp
>> 1: 48 89 e5 mov %rsp,%rbp
>> 4: 48 8d 05 00 00 00 00 lea 0x0(%rip),%rax # b <main+0xb>
>> 7: R_X86_64_GOTPC32 _GLOBAL_OFFSET_TABLE_-0x4
>> b: b8 00 00 00 00 mov $0x0,%eax
>> 10: e8 00 00 00 00 callq 15 <main+0x15>
>> 11: R_X86_64_PLT32 bar-0x4
>> 15: 89 c2 mov %eax,%edx
>> 17: 48 8b 05 00 00 00 00 mov 0x0(%rip),%rax # 1e <main+0x1e>
>> 1a: R_X86_64_GOTPCREL c-0x4
>> 1e: 0f b6 80 e1 00 00 00 movzbl 0xe1(%rax),%eax
>> 25: 0f be c0 movsbl %al,%eax
>> 28: 01 d0 add %edx,%eax
>> 2a: 5d pop %rbp
>> 2b: c3 retq
>>
>> $ objdump -dr pr61599-2a.o
>>
>> pr61599-2a.o: file format elf64-x86-64
>>
>>
>> Disassembly of section .text:
>>
>> 0000000000000000 <bar>:
>> 0: 55 push %rbp
>> 1: 48 89 e5 mov %rsp,%rbp
>> 4: 48 8d 05 00 00 00 00 lea 0x0(%rip),%rax # b <bar+0xb>
>> 7: R_X86_64_GOTPC32 _GLOBAL_OFFSET_TABLE_-0x4
>> b: 48 8b 05 00 00 00 00 mov 0x0(%rip),%rax # 12 <bar+0x12>
>> e: R_X86_64_GOTPCREL a-0x4
>> 12: 0f b6 40 02 movzbl 0x2(%rax),%eax
>> 16: 0f be d0 movsbl %al,%edx
>> 19: 48 8b 05 00 00 00 00 mov 0x0(%rip),%rax # 20 <bar+0x20>
>> 1c: R_X86_64_GOTPCREL b-0x4
>> 20: 0f b6 40 10 movzbl 0x10(%rax),%eax
>> 24: 0f be c0 movsbl %al,%eax
>> 27: 01 c2 add %eax,%edx
>> 29: 48 8b 05 00 00 00 00 mov 0x0(%rip),%rax # 30 <bar+0x30>
>> 2c: R_X86_64_GOTPCREL c-0x4
>> 30: 0f b6 80 00 01 00 00 movzbl 0x100(%rax),%eax
>> 37: 0f be c0 movsbl %al,%eax
>> 3a: 01 d0 add %edx,%eax
>> 3c: 5d pop %rbp
>> 3d: c3 retq
>>
>> $ gcc pr61599-2a.o pr61599-1a.o
>> pr61599-2a.o: In function `bar':
>> pr61599-2a.c:(.text+0xe): relocation truncated to fit: R_X86_64_PC32
>> against symbol `a' defined in LARGE_COMMON section in pr61599-1a.o
>> collect2: error: ld returned 1 exit status
>>
>> There is no R_X86_64_PC32 in pr61599-2a.o, only X86_64_GOTPCREL, which
>> according to assumptions, would reach all entries in the GOT table.
>
> I opened:
>
> https://sourceware.org/bugzilla/show_bug.cgi?id=20093
I also reported
https://sourceware.org/bugzilla/show_bug.cgi?id=20092
Thanks,
Uros.
