Enable EBX for x86 in 32bits PIC code

Jeff Law law@redhat.com
Wed Sep 24 15:27:00 GMT 2014

On 09/24/14 00:56, Ilya Enkovich wrote:
> 2014-09-23 20:10 GMT+04:00 Jeff Law <law@redhat.com>:
>> On 09/23/14 10:03, Jakub Jelinek wrote:
>>> On Tue, Sep 23, 2014 at 10:00:00AM -0600, Jeff Law wrote:
>>>> On 09/23/14 08:34, Jakub Jelinek wrote:
>>>>> On Tue, Sep 23, 2014 at 05:54:37PM +0400, Ilya Enkovich wrote:
>>>>>> use fixed EBX at least until we make sure pseudo PIC doesn't harm debug
>>>>>> info generation.  If we have such option then gcc.target/i386/pic-1.c
>>>>>> and
>>>>> For debug info, it seems you are already handling this in
>>>>> delegitimize_address target hook, I'd suggest just building some very
>>>>> large
>>>>> shared library at -O2 -g -fpic on i?86 and either look at the
>>>>> sizes of .debug_info/.debug_loc sections with/without the patch,
>>>>> or use the locstat utility from elfutils (talk to Petr Machata if
>>>>> needed).
>>>> Can't hurt, but I really don't see how changing from a fixed to an
>>>> allocatable register is going to muck up debug info in any significant
>>>> way.
>>> What matters is if the delegitimize_address target hook is as efficient in
>>> delegitimization as before.  E.g. if it previously matched only when
>>> seeing
>>> %ebx + gotoff or similar, and wouldn't match anything now, some vars could
>>> have debug locations including UNSPEC and be dropped on the floor.
>> Ah, yea, that makes sense.
>> jeff
> After register allocation we have no idea where GOT address is and
> therefore delegitimize_address target hook becomes less efficient and
> cannot remove UNSPECs. That's what I see now when build GCC with patch
> applied:
In theory this shouldn't be too hard to fix.

I haven't looked at the code, but it might be something looking 
explicitly for ebx by register #, or something similar.  Which case 
within delegitimize_address isn't firing as it should after your changes?


More information about the Gcc-patches mailing list