Início / coding / Perguntas / 79117624
Accepted
Netch
Asked: 2024-10-23 18:57:42 +0800 CST

Por que as convenções de chamada modernas passam argumentos variáveis ​​em registradores?

  • 772

Se olharmos para algumas convenções de chamada modernas, como o estilo SysV x86-64 ou o estilo AArch64 (documento aapcs64.pdf intitulado "Procedure Call Standard for the Arm® 64-bit Architecture"), vemos notas explícitas de que argumentos variádicos são passados ​​da mesma forma que outros argumentos. Por exemplo, uma chamada de função open(path, mode, cflags)em x86-64 obterá path em RDI, mode em RSI e (o único variádico) cflags em RDX.

Não há dúvida sobre passar conjunto de argumentos estáticos em registradores, é bom para economizar recursos. Mas se olharmos para uma função que então interpreta argumentos e então va_startos chama, veremos que va_starté convertido em colocar todos os argumentos possíveis (tipicamente, muito mais do que realmente presente) na pilha; por exemplo, a emulação completa de printfvia vfprintfcomeça com (eu compactei linhas semelhantes para evitar listagens muito longas):

my_printf:
        endbr64
; nearly unconditional saving
        subq    $216, %rsp
        movq    %rsi, 40(%rsp)
<...>
        movq    %r9, 72(%rsp)
        testb   %al, %al
        je      .L2
        movaps  %xmm0, 80(%rsp)
<...>
        movaps  %xmm7, 192(%rsp)
; repacking into registers for enclosed vfprintf
.L2:
        movq    %fs:40, %rax
        movq    %rax, 24(%rsp)
        xorl    %eax, %eax
        movl    $8, (%rsp)
        movl    $48, 4(%rsp)
        leaq    224(%rsp), %rax
        movq    %rax, 8(%rsp)
        leaq    32(%rsp), %rax
        movq    %rax, 16(%rsp)
        movq    %rsp, %rcx
        movq    %rdi, %rdx
        movl    $1, %esi
; finally, call the function
        movq    stdout(%rip), %rdi
        call    __vfprintf_chk@PLT
... skipped epilogue

Aqui 192 bytes de quadro VA. Similarmente, a versão AArch64 empurra 184 bytes (x1..x7 e q0..q7).

Se a cauda variádica de qualquer chamada de função tivesse sido sempre colocada na pilha, as coisas teriam ficado muito mais simples no código e mais baratas no tempo de execução, porque todo o empacotamento e cópia não teriam sido necessários. va_startteria sido reduzido a uma única movimentação da localização inicial da lista variádica (na pilha) para uma variável. É assim que realmente funcionava com o i386 (onde todos os argumentos eram passados ​​na pilha). Saída de assembly do mesmo wrapper trivial para Linux/i386:

my_printf:
        pushl   %ebx
        subl    $8, %esp
        call    __x86.get_pc_thunk.bx
        addl    $_GLOBAL_OFFSET_TABLE_, %ebx
        leal    20(%esp), %eax ; <--- This is va_start
        pushl   %eax ; VA pointer pushed for vfprintf
        pushl   20(%esp)
        pushl   $1
        movl    stdout@GOT(%ebx), %eax
        pushl   (%eax)
        call    __vfprintf_chk@PLT

Aqui, a questão : por que a implementação de argumentos variáveis, pelo menos para x86-64 e aarch64, é tão complicada e desperdiça recursos?

(Eu poderia imaginar que havia casos em que dois estilos, ambos com argumentos fixos e com uma lista variádica, deveriam ter sido igualmente permitidos em declarações de função da mesma função. Mas não conheço um caso para isso. O mencionado opené improvável que seja o único.)

Parece resolvido : o fator que levou a esse design é a necessidade de dar suporte ao legado C de funções "sem protótipo" (detalhes na resposta de @fuz) da maneira como elas são declaradas, em lugares diferentes, com ou sem protótipo, mas o uso é consistente com a assinatura realmente aplicada.

c

1 respostas

  1. Best Answer

    Note que nem todas as convenções de chamada fazem isso. Por exemplo, a convenção de chamada AArch64 usada no macOS passa argumentos variádicos na pilha.

    Dito isso, uma motivação chave para passar argumentos variádicos em registradores é que isso faz com que nem o chamador nem o chamado precisem saber se uma função é variádica ou não. Por exemplo, se você fosse chamar uma função sem protótipo declarada assim:

    int printf();

    você não seria capaz de saber se é uma função variádica ou não. Mas em virtude de funções variádicas e não variádicas terem a mesma convenção de chamada, o chamador pode simplesmente definir AL como se fosse uma função variádica e chamá-la, com o chamado ignorando AL se não for.

    Isso não é possível com a convenção de chamada do macOS, onde a execução de programas que não declaram consistentemente funções variádicas com protótipos falhará.

    • 6

relate perguntas