This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PARCH 1/2, x86, PR63534] Fix darwin bootstrap


On Tue, Nov 4, 2014 at 1:40 AM, Jeff Law <law@redhat.com> wrote:
> On 11/01/14 06:39, Evgeny Stupachenko wrote:
>>
>> When PIC register is pseudo there is nothing special about it's value
>> that setjmp can hurt. So if the pseudo register lives across
>> setjmp_receiver RA should care about correct allocation (in case it is
>> not saved/restored, it should go on stack). gcc.dg tests and specs
>> I've tested behave like this.
>
> If the allocator picked a call-clobbered register for the PIC register, then
> we're obviously OK since the setjmp has to be expected to clobber the PIC
> register.
>
> But if the PIC register is in a call-saved register, then it's going to be
> assumed to not be clobbered across calls and I don't believe that is
> guaranteed for builtin setjmp/longjmp.  Those restore SP, FP and an ARGP,
> but not anything else by default.

I still don't see what is special for PIC register here. PIC pseudo
now behave as every other pseudo register.
If we assume that setjmp can change a pseudo register value we need
IRA/LRA "magic" for each pseudo register.

I believe that when we had EBX fixed, IRA/LRA don't save/restore it anywhere.
Therefore we had to care about EBX value in special cases like
setjmp/non-local goto.
Now RA cares about PIC pseudo as well as about correct allocation for
any pseudo register.

>
> So the callee might have clobbered the call saved hard register, expecting
> to restore its value in its epilogue.  But due to the longjmp, that epilogue
> never gets called and thus the call-saved register won't have the right
> value in the receiver.
>
> Now if your argument is that IRA/LRA handle this, that's fine, a pointer to
> that code would be appreciated so that it can be quickly audited. Certainly
> the old local-alloc/global-alloc had magic for setjmp/longjmp and maybe
> IRA/LRA does too, but it's better to be sure than just assume.
>
>>
>> The initial problem comes from non-local goto as it tries to emit
>> pseudo PIC register after reload.
>
> ?  You mean it emits a reference to the pseudo into RTL?  That would
> indicate that the allocators never put the pseudo into a hard register?!?
> RTL dumps with a few pointers to key insns would help here.

Correct, that is why Darwin crashes with ICE on non-local goto.
We still have:

(define_insn_and_split "nonlocal_goto_receiver"
  [(unspec_volatile [(const_int 0)] UNSPECV_NLGR)]
  "TARGET_MACHO && !TARGET_64BIT && flag_pic"
  "#"
  "&& reload_completed"
  [(const_int 0)]
{
  if (crtl->uses_pic_offset_table)
    {
      rtx xops[3];
      rtx label_rtx = gen_label_rtx ();
      rtx tmp;

      /* Get a new pic base.  */
      emit_insn (gen_set_got_labelled (pic_offset_table_rtx, label_rtx));
.....
Here for MAC only we are trying to use pseudo PIC:
pic_offset_table_rtx when reload_completed.

>
> jeff
>
>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]