lkml.org 
[lkml]   [2017]   [Aug]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [tip:x86/asm] objtool: Track DRAP separately from callee-saved registers
On Fri, Aug 11, 2017 at 5:13 AM, tip-bot for Josh Poimboeuf
<tipbot@zytor.com> wrote:
> Commit-ID: bf4d1a83758368c842c94cab9661a75ca98bc848
> Gitweb: http://git.kernel.org/tip/bf4d1a83758368c842c94cab9661a75ca98bc848
> Author: Josh Poimboeuf <jpoimboe@redhat.com>
> AuthorDate: Thu, 10 Aug 2017 16:37:26 -0500
> Committer: Ingo Molnar <mingo@kernel.org>
> CommitDate: Fri, 11 Aug 2017 14:06:15 +0200
>
> objtool: Track DRAP separately from callee-saved registers
>
> When GCC realigns a function's stack, it sometimes uses %r13 as the DRAP
> register, like:
>
> push %r13
> lea 0x10(%rsp), %r13
> and $0xfffffffffffffff0, %rsp
> pushq -0x8(%r13)
> push %rbp
> mov %rsp, %rbp
> push %r13
> ...
> mov -0x8(%rbp),%r13
> leaveq
> lea -0x10(%r13), %rsp
> pop %r13
> retq
>

I have a couple questions, mainly to help me understand.

Question 1: What does DRAP stand for? Duplicate Return Address
Pointer? Dynamic ReAlignment Pointer? I tried searching and got
nothing.

Question 2: What's up with the resulting stack layout? It seems we have:

caller's last stack slot <-- r13 in function body points here
return address
old r13
[possible padding for alignment]
return address, duplicated (for naive unwinder's benefit?)
old rbp <-- rbp in body points here
new r13, i.e. pointer to caller's last stack slot

Now we have the function body, and r13 is free for use in here because
it's saved.

In the epilogue, we recover r13, use leaveq (hmm, shorter than pop
%rbp but does more work than needed), restore the old r13, and return.

I don't get it, though. gcc only ever uses that inner r13 with an
offset. The code would be considerably shorter if the second
instruction were just mov %rsp, %r13. That would change the push to
pushq 0x8(%rsp) and the third-to-last instruction to mov %r13, %rsp,
saving something like 8 bytes of code.

I also don't get why any of this is needed. Couldn't the compiler
just do push %rbp; mov %rsp, %rbp; and $0xfffffffffffffff0, %rsp and
be done with it?

I compiled this:

void func()
{
int var __attribute__((aligned(32)));
asm volatile ("" :: "m" (var));
}

and got:

func:
leaq 8(%rsp), %r10
andq $-32, %rsp
pushq -8(%r10)
pushq %rbp
movq %rsp, %rbp
pushq %r10
popq %r10
popq %rbp
leaq -8(%r10), %rsp
ret

Which is better than the crud you pasted, since it at least uses a
caller-saved reg (r10), but we still have the nasty addressing modes
*and* an unnecessary push and pop of r10.

I filed https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81825 and maybe
some GCC person has a clue what's going on.

\
 
 \ /
  Last update: 2017-08-11 18:22    [W:0.112 / U:1.564 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site