On 01/25/2018 06:38 AM, H.J. Lu wrote:
> On Mon, Jan 22, 2018 at 4:21 AM, Florian Weimer <fwei...@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
