Início / coding / Perguntas / 78834826
Accepted
Konstantin W
Asked: 2024-08-05 22:03:59 +0800 CST

A otimização do GCC com -Os assume incorretamente que o ponteiro é NULL

  • 772

Recentemente, mudamos para um GCC mais recente e ele otimizou uma função inteira e a substituiu pelo código de armadilha "acesso ao ponteiro nulo" ao otimizar o tamanho. Olhando para godbolt, o problema apareceu com o GCC 11.1 ao otimizar com -Os. Otimizar com -O2e -O3funciona bem, mesmo com -fstrict-aliasing.

Simplificado, o código fica assim ( link godbolt ):

#include <inttypes.h>
#include <stddef.h>
#include <string.h>

typedef struct bounds_s {
  uint8_t *start;
  uint8_t *end;
} bounds_s_t;

static void reserve_space(bounds_s_t *bounds, size_t len, uint8_t **element)
{
  if (bounds->start + len > bounds->end) {
    return;
  }
  
  *element = bounds->start;
  bounds->start += len;
}

void bug(uint8_t *buffer, size_t size)
{
  bounds_s_t bounds;
  uint32_t *initialize_this;
  
  initialize_this = NULL;
  bounds.start = buffer;
  bounds.end = buffer + size;

  reserve_space(&bounds, sizeof(*initialize_this), (uint8_t **)&initialize_this);

  uint32_t value = 1234;
  memcpy(initialize_this, &value, sizeof(*initialize_this));
}

E leva à seguinte montagem:

bug:
        xor     eax, eax
        mov     DWORD PTR ds:0, eax
        ud2

Que otimização faz o GCC pensar que a initialize_thisvariável é NULL? A única coisa que me vem à mente é quebrar regras rígidas de alias. Mas será que a tipificação de ponteiros duplos pode uint32_t **realmente uint8_t **ser o problema aqui e levar a consequências tão pesadas?

c

1 respostas

  1. Best Answer

    *element = bounds->start;viola o alias estrito:

    • Como elementtem type uint8_t **, *elementtem type uint8_t *, então isso é armazenado *elementcom type uint8_t *.
    • Neste ponto, elementtem o endereço de initialize_this, que tem o tipo declarado e, portanto, o tipo efetivo, uint32_t *.
    • Acessar a uint32_t *com um tipo de uint8_t *não está em conformidade com nenhuma das regras de alias em C 2018 6.5 7.
    • No GCC, -fstrict-aliasingé habilitado por -Os.
    • Portanto, o compilador pode concluir, uma vez que não vê nenhuma gravação em um tipo que pode ser alias uint32_t *depois de initialize_this = NULL;, que initialize_thispermanece inalterado em relação a um ponteiro nulo.

    Além disso, não há controle no código para garantir que o valor de bounds->startseja um endereço alinhado corretamente para a uint32_t.

    Esses problemas podem ser corrigidos:

    • O chamador reserve_spacetambém deve passar por um requisito de alinhamento, que pode ser calculado pela chamada usando _Alignof (uint32_t *)(e, com o futuro padrão C esperado, _Alignof (typeof (initialize_this))). reserve_spacedeve adicionar bytes de preenchimento conforme necessário para tornar o endereço inicial um múltiplo deste requisito.
    • Ao invés de ter um parâmetro do tipo uint8_t **, reserve_spacedeveria retornar um void *apontando para o espaço reservado. A rotina de chamada pode então atribuir isso a initialize_this, e a conversão implícita da atribuição irá convertê-la automaticamente para o tipo correto.

    O código também não mostra as origens do buffer. Se for um espaço alocado dinamicamente, então, uma vez initialize_thisconfigurado corretamente conforme descrito acima, *initialize_thispode ser usado como um arquivo uint32_t. Em particular, não há necessidade de memcpycopiar um valor nele; pode ser definido com *initialize_this = 1234;. No entanto, se bufferfor criado de alguma outra forma, como uma matriz declarada de uint8_t, poderão permanecer problemas de alias.

    • 6

relate perguntas