Retpolines and CFI

[Jeff Law]

On 01/25/2018 06:38 AM, H.J. Lu wrote:
> On Mon, Jan 22, 2018 at 4:21 AM, Florian Weimer <fweimer@redhat.com> wrote:
>> I tried this:
>>
>> struct C {
>>   virtual ~C();
>>   virtual void f();
>> };
>>
>> void
>> f (C *p)
>> {
>>   p->f();
>>   p->f();
>> }
>>
>> with r256939 and -mindirect-branch=thunk -O2 on x86-64 GNU/Linux, and got
>> this:
>>
>> _Z1fP1C:
>> .LFB0:
>>         .cfi_startproc
>>         pushq   %rbx
>>         .cfi_def_cfa_offset 16
>>         .cfi_offset 3, -16
>>         movq    (%rdi), %rax
>>         movq    %rdi, %rbx
>>         jmp     .LIND1
>> .LIND0:
>>         pushq   16(%rax)
>>         jmp     __x86_indirect_thunk
>> .LIND1:
>>         call    .LIND0
>>         movq    (%rbx), %rax
>>         movq    %rbx, %rdi
>>         popq    %rbx
>>         .cfi_def_cfa_offset 8
>>         movq    16(%rax), %rax
>>         jmp     __x86_indirect_thunk_rax
>>         .cfi_endproc
>>
>> This doesn't look quite right.  x86-64 is supposed to have asynchronous
>> unwind tables by default, but there is nothing that reflects the change in
>> the (relative) frame address after .LIND0.  I think that region really has
>> to be moved outside of the .cfi_startproc/.cfi_endproc bracket.
> 
> I'd like to remove __x86_indirect_thunk since it can't be made compatible
> with CET:
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83970
User code should be built with CET, not retpolines.   So I don't see
that removing x86_indirect_thunk is that important because we won't be
using them together.

jeff