c++ - suppressions - undefined behavior sanitizer gcc




Допускает ли стандарт C++ неинициализированный bool для сбоя программы? (4)

Я знаю, что «неопределенное поведение» в C ++ может позволить компилятору делать все, что он захочет. Однако у меня произошел сбой, который удивил меня, так как я предположил, что код был достаточно безопасным.

В этом случае настоящая проблема возникла только на конкретной платформе, использующей определенный компилятор, и только если была включена оптимизация.

Я перепробовал несколько вещей, чтобы воспроизвести проблему и максимально упростить ее. Вот выдержка из функции под названием Serialize , которая будет принимать параметр bool и копировать строку true или false в существующий целевой буфер.

Если бы эта функция была в обзоре кода, не было бы никакого способа сказать, что она на самом деле могла бы аварийно завершиться, если бы параметр bool был неинициализированным значением?

// Zero-filled global buffer of 16 characters
char destBuffer[16];

void Serialize(bool boolValue) {
    // Determine which string to print based on boolValue
    const char* whichString = boolValue ? "true" : "false";

    // Compute the length of the string we selected
    const size_t len = strlen(whichString);

    // Copy string into destination buffer, which is zero-filled (thus already null-terminated)
    memcpy(destBuffer, whichString, len);
}

Если этот код выполняется с оптимизацией clang 5.0.0 +, он может / может дать сбой.

Ожидаемый троичный оператор boolValue ? "true" : "false" boolValue ? "true" : "false" выглядело достаточно безопасно для меня, я предполагал: «Независимо от того, boolValue значение мусора находится в boolValue не имеет значения, так как оно все равно будет иметь значение true или false».

Я настроил пример Compiler Explorer, который показывает проблему в разборке, вот полный пример. Примечание: чтобы воспроизвести проблему, я обнаружил, что сработала комбинация с использованием Clang 5.0.0 с оптимизацией -O2.

#include <iostream>
#include <cstring>

// Simple struct, with an empty constructor that doesn't initialize anything
struct FStruct {
    bool uninitializedBool;

   __attribute__ ((noinline))  // Note: the constructor must be declared noinline to trigger the problem
   FStruct() {};
};

char destBuffer[16];

// Small utility function that allocates and returns a string "true" or "false" depending on the value of the parameter
void Serialize(bool boolValue) {
    // Determine which string to print depending if 'boolValue' is evaluated as true or false
    const char* whichString = boolValue ? "true" : "false";

    // Compute the length of the string we selected
    size_t len = strlen(whichString);

    memcpy(destBuffer, whichString, len);
}

int main()
{
    // Locally construct an instance of our struct here on the stack. The bool member uninitializedBool is uninitialized.
    FStruct structInstance;

    // Output "true" or "false" to stdout
    Serialize(structInstance.uninitializedBool);
    return 0;
}

Проблема возникает из-за оптимизатора: было достаточно умно сделать вывод, что строки «истина» и «ложь» отличаются только по длине на 1. Поэтому вместо реального вычисления длины он использует значение самого bool, которое должно технически это может быть 0 или 1, и выглядит так:

const size_t len = strlen(whichString); // original code
const size_t len = 5 - boolValue;       // clang clever optimization

Хотя это, так сказать, «умно», мой вопрос таков : позволяет ли стандарт C ++ компилятору предполагать, что bool может иметь только внутреннее числовое представление «0» или «1» и использовать его таким образом?

Или это случай, определяемый реализацией, и в этом случае реализация предполагала, что все ее значения bool будут содержать только 0 или 1, а любое другое значение является неопределенной территорией поведения?


Да, ISO C ++ позволяет (но не требует) реализации сделать этот выбор.

Но также обратите внимание, что ISO C ++ позволяет компилятору генерировать код, который вылетает намеренно (например, с недопустимой инструкцией), если программа сталкивается с UB, например, как способ помочь вам найти ошибки. (Или потому, что это DeathStation 9000. Строго соответствующего соответствия недостаточно, чтобы реализация C ++ была полезна для любых реальных целей). Таким образом, ISO C ++ позволил бы компилятору создавать сбой asm (по совершенно разным причинам) даже в похожем коде, который читает неинициализированный uint32_t . Даже при том, что это должен быть тип с фиксированной компоновкой без представления ловушек.

Это интересный вопрос о том, как работают реальные реализации, но помните, что даже если бы ответ был другим, ваш код все равно был бы небезопасным, потому что современный C ++ не является переносимой версией ассемблера.

Вы компилируете для x86-64 System V ABI , который указывает, что bool как аргумент функции в регистре представлен битовыми комбинациями false=0 и true=1 в младших 8 битах регистра 1 . В памяти bool - это 1-байтовый тип, который снова должен иметь целочисленное значение 0 или 1.

(ABI - это набор вариантов реализации, с которыми согласуются компиляторы для одной и той же платформы, чтобы они могли создавать код, который вызывает функции друг друга, включая размеры типов, правила структурирования и соглашения о вызовах.)

ISO C ++ не определяет его, но это решение ABI широко распространено, потому что оно делает преобразование bool-> int дешевым (просто с нулевым расширением) . Мне не известны никакие ABI, которые не позволяют компилятору принимать 0 или 1 для bool , для любой архитектуры (не только для x86). Он позволяет оптимизировать, например !mybool с xor eax,1 чтобы перевернуть !mybool бит: любой возможный код, который может перевернуть бит / целое число / bool между 0 и 1 в одной инструкции CPU . Или компилирование a&&b для побитового И для типов bool . Некоторые компиляторы действительно используют булевские значения как 8-битные в компиляторах. Операции на них неэффективны? ,

В общем, правило «как если» позволяет компилятору использовать преимущества, которые являются истинными для целевой платформы, для которой выполняется компиляция , поскольку конечным результатом будет исполняемый код, который реализует то же внешне видимое поведение, что и исходный код C ++. (Со всеми ограничениями, которые Undefined Behavior накладывает на то, что на самом деле «внешне видно»: не с помощью отладчика, а из другого потока в правильно сформированной / легальной программе C ++.)

Компилятору определенно разрешено в полной мере использовать гарантию ABI в своем коде поколения и создавать код, подобный тому, который вы нашли, который оптимизирует strlen(whichString) для
5U - boolValue . (Кстати, эта оптимизация довольно умная, но может быть недальновидной, а не ветвящейся и встроенной в memcpy как хранилище непосредственных данных 2. )

Или компилятор мог бы создать таблицу указателей и проиндексировать ее целочисленным значением bool , снова предполагая, что это 0 или 1. ( Эта возможность - то, что предложил ответ @ Barmar .)

Ваш __attribute((noinline)) конструктор с включенной оптимизацией привел к лягушке, просто загружающей байт из стека для использования в качестве uninitializedBool . Он освободил место для объекта в main с помощью push rax (который меньше и по разным причинам примерно так же эффективен, как sub rsp, 8 ), поэтому любой мусор, который был в AL при входе в main является значением, которое он использовал для uninitializedBool . Вот почему вы на самом деле получили значения, которые не были просто 0 .

5U - random garbage может легко переноситься в большое значение без знака, что приводит к тому, что memcpy попадает в неотображенную память. Место назначения находится в статическом хранилище, а не в стеке, поэтому вы не перезаписываете адрес возврата или что-то еще.

Другие реализации могут делать разные выборы, например, false=0 и true=any non-zero value . Тогда, вероятно, clang не создаст код, который вылетает для этого конкретного экземпляра UB. (Но все равно было бы разрешено, если бы захотелось.) Я не знаю каких-либо реализаций, которые выбирали бы что-нибудь другое, что x86-64 делает для bool , но стандарт C ++ допускает многие вещи, которые никто не делает или даже не хочет делать на оборудовании это что-то вроде текущих процессоров.

ISO C ++ оставляет неуказанным, что вы найдете, когда изучите или измените объектное представление bool . (Например, memcpy bool в unsigned char , что вам разрешено делать, потому что char* может иметь псевдоним что угодно. А unsigned char гарантированно не содержит битов заполнения, поэтому стандарт C ++ формально позволяет вам hexdump-представления объектов без каких-либо UB char foo = my_bool указателей для копирования представления объекта отличается от присваивания char foo = my_bool , конечно, поэтому логическое значение 0 или 1 не произойдет, и вы получите необработанное представление объекта.)

Вы частично «спрятали» UB на этом пути выполнения от компилятора с помощью noinline . Однако, даже если он не встроен, межпроцедурная оптимизация может сделать версию функции зависимой от определения другой функции. (Во-первых, clang создает исполняемый файл, а не разделяемую библиотеку Unix, где может происходить взаимное расположение символов. Во-вторых, определение внутри определения class{} поэтому все единицы перевода должны иметь одно и то же определение. Как и с ключевым словом inline .)

Таким образом, компилятор может ud2 только ret или ud2 (недопустимая инструкция) в качестве определения для main , потому что путь выполнения, начинающийся с вершины main неизбежно встречает Undefined Behavior. (Что может видеть компилятор во время компиляции, если он решил следовать по пути через не встроенный конструктор.)

Любая программа, которая сталкивается с UB, полностью не определена в течение всего ее существования. Но UB внутри функции или ветви if() которая никогда не запускается, не повреждает остальную часть программы. На практике это означает, что компиляторы могут решить выдать недопустимую инструкцию, или ret , или не выдать что-либо и попасть в следующий блок / функцию, для всего базового блока, который может быть доказан во время компиляции, чтобы содержать или привести к UB.

GCC и Clang на практике иногда ud2 на UB вместо того, чтобы даже пытаться сгенерировать код для путей выполнения, которые не имеют смысла. Или для случаев, таких как выпадение конца не void функции, gcc иногда пропускает команду ret . Если вы думали, что «моя функция просто вернется с мусором в RAX», вы сильно ошибаетесь. Современные компиляторы C ++ больше не рассматривают язык как переносимый язык ассемблера. Ваша программа действительно должна быть верной C ++, не делая предположений о том, как автономная не встроенная версия вашей функции может выглядеть в asm.

Еще один забавный пример: почему невыравниваемый доступ к памяти mmap иногда вызывает ошибку на AMD64? , x86 не ошибается на невыровненных целых числах, верно? Так почему же возникла проблема со смещением uint16_t* ? Потому что alignof(uint16_t) == 2 , и нарушение этого предположения привело к segfault при автоматической векторизации с SSE2.

Смотрите также, что должен знать каждый программист на C о неопределенном поведении # 1/3 , статья разработчика Clang.

Ключевой момент: если компилятор заметил UB во время компиляции, он мог бы «прервать» (испустить удивительный asm) путь через ваш код, который вызывает UB, даже если он нацелен на ABI, где любой битовый шаблон является допустимым представлением объекта для bool .

Ожидайте полной враждебности ко многим ошибкам со стороны программиста, особенно о том, о чем предупреждают современные компиляторы. Вот почему вы должны использовать -Wall и исправить предупреждения. C ++ не является дружественным к пользователю языком, и что-то в C ++ может быть небезопасным, даже если это будет безопасно в asm для цели, для которой вы компилируете. (Например, переполнение со знаком - это UB в C ++, и компиляторы предполагают, что этого не произойдет, даже при компиляции для дополнения x86 к 2, если вы не используете clang/gcc -fwrapv .)

UB, видимый во время компиляции, всегда опасен, и очень трудно быть уверенным (с оптимизацией во время компоновки), что вы действительно скрыли UB от компилятора и, таким образом, можете решить, какой тип asm он сгенерирует.

Не быть чрезмерно драматичным; часто компиляторы позволяют вам сойтись с некоторыми вещами и генерировать код, как вы ожидаете, даже когда что-то не так. Но, возможно, это будет проблемой в будущем, если разработчики компиляторов реализуют некоторую оптимизацию, которая получает больше информации о диапазонах значений (например, переменная неотрицательна, возможно, позволяя оптимизировать расширение знака для свободного расширения нуля на x86- 64). Например, в текущих gcc и clang выполнение tmp = a+INT_MIN не оптимизирует a<0 как всегда ложное, только то, что tmp всегда отрицателен. (Потому что INT_MIN + a=INT_MAX отрицателен для цели этого дополнения 2, и a не может быть выше этого.)

Таким образом, gcc / clang в настоящее время не возвращается для получения информации о диапазоне для входных данных вычисления, а только на основе результатов, основанных на предположении об отсутствии переполнения со знаком : пример на Godbolt . Я не знаю, намеренно ли "пропущена" эта оптимизация во имя удобства для пользователя или как.

Также обратите внимание, что реализации (или компиляторы) могут определять поведение, которое ISO C ++ оставляет неопределенным . Например, все компиляторы, которые поддерживают встроенные функции Intel (например, _mm_add_ps(__m128, __m128) для ручной векторизации SIMD), должны разрешать формирование неправильно выровненных указателей, что является UB в C ++, даже если вы не разыменовываете их. __m128i _mm_loadu_si128(const __m128i *) выполняет невыровненные нагрузки, принимая __m128i* arg, а не void* или char* . Является ли `reinterpret_cast`ing между аппаратным указателем вектора и соответствующим типом неопределенным поведением?

GNU C / C ++ также определяет поведение сдвига влево отрицательного числа со -fwrapv (даже без -fwrapv ) отдельно от обычных правил UB со -fwrapv переполнения. ( Это UB в ISO C ++ , в то время как правое смещение чисел со знаком определяется реализацией (логическое или арифметическое); реализации хорошего качества выбирают арифметику на HW, которая имеет арифметическое правое смещение, но ISO C ++ не определяет). Это задокументировано в разделе Integer руководства GCC , а также определено поведение, определяемое реализацией, которое стандарты C требуют, чтобы реализации определяли так или иначе.

Определенно есть проблемы с качеством реализации, о которых заботятся разработчики компиляторов; они обычно не пытаются сделать компиляторы преднамеренно враждебными, но использование всех пробелов UB в C ++ (кроме тех, которые они выбирают для оптимизации) иногда может быть почти неразличимым.

Сноска 1 : старшие 56 битов могут быть мусором, который вызывающий должен игнорировать, как обычно для типов, более узких, чем регистр.

( Другие ABI здесь делают другой выбор . Некоторые требуют, чтобы узкие целочисленные типы были расширены нулями или знаками для заполнения регистра при передаче или возвращении из функций, таких как MIPS64 и PowerPC64. См. Последний раздел этого ответа x86-64. который сравнивается с теми более ранними МСА .)

Например, вызывающая a & 0x01010101 могла вычислить a & 0x01010101 в RDI и использовать его для чего-то еще, прежде чем вызывать bool_func(a&1) . Вызывающий может оптимизировать &1 потому что он уже сделал это с and edi, 0x01010101 байтом как часть and edi, 0x01010101 , and edi, 0x01010101 , и он знает, что вызываемый and edi, 0x01010101 должен игнорировать старшие байты.

Или, если bool передается как 3-й аргумент, возможно, вызывающая программа, оптимизирующая по размеру кода, загружает его с помощью mov dl, [mem] вместо movzx edx, [mem] , сохраняя 1 байт за счет ложной зависимости от старого значение RDX (или другой эффект частичного регистра, в зависимости от модели процессора). Или для первого аргумента: mov dil, byte [r10] вместо movzx edi, byte [r10] , потому что оба так или иначе требуют префикс REX.

Вот почему clang испускает movzx eax, dil в Serialize , а не sub eax, edi . (Для целочисленных аргументов clang нарушает это правило ABI, вместо этого в зависимости от недокументированного поведения gcc и clang до нуля или знака расширяет узкие целые числа до 32 бит. Требуется ли расширение знака или нуля при добавлении 32-битного смещения к указателю для ABI x86-64? Так что мне было интересно увидеть, что он не делает то же самое для bool .)

Сноска 2: После ветвления у вас будет только 4-байтовое mov -immediate или 4-байтовое + 1-байтовое хранилище. Длина указана в значениях ширины магазина + смещения.

OTOH, glibc memcpy сделает две 4-байтовые загрузки / хранилища с перекрытием, зависящим от длины, так что это действительно в конечном итоге делает все это свободным от условных ветвей в логическом значении. См. L(between_4_7): в memcpy / memmove glibc. Или, по крайней мере, используйте тот же способ для логического значения в ветвлении memcpy, чтобы выбрать размер куска.

При вставке вы можете использовать 2x mov -immediate + cmov и условное смещение, или вы можете оставить строковые данные в памяти.

Или, если вы настраиваете Intel Ice Lake ( с функцией Fast Short REP MOV ), реальный rep movsb может быть оптимальным. glibc memcpy может начать использовать rep movsb для небольших размеров на процессорах с этой функцией, сохраняя большое количество ветвлений.

Инструменты для обнаружения UB и использования неинициализированных значений

В gcc и clang вы можете скомпилировать с -fsanitize=undefined чтобы добавить инструментарий времени выполнения, который будет предупреждать или выдавать ошибку в UB, которая происходит во время выполнения. Это не поймает унифицированные переменные, хотя. (Потому что он не увеличивает размеры шрифта, чтобы освободить место для «неинициализированного» бита).

См. https://developers.redhat.com/blog/2014/10/16/gcc-undefined-behavior-sanitizer-ubsan/

Чтобы найти использование неинициализированных данных, есть Address Sanitizer и Memory Sanitizer в clang / LLVM. https://github.com/google/sanitizers/wiki/MemorySanitizer показывает примеры clang -fsanitize=memory -fPIE -pie обнаружения неинициализированных чтений из памяти. Это может работать лучше, если вы компилируете без оптимизации, поэтому все чтения переменных в конечном итоге фактически загружаются из памяти в asm. Они показывают, что он используется при -O2 в случае, когда нагрузка не оптимизируется. Я сам не пробовал. (В некоторых случаях, например, не инициализируя аккумулятор перед суммированием массива, clang -O3 будет выдавать код, который суммируется в векторный регистр, который он никогда не инициализировал. Так что с оптимизацией вы можете иметь случай, когда нет чтения памяти, связанной с UB Но -fsanitize=memory изменяет сгенерированный asm и может привести к проверке этого.)

Это допустит копирование неинициализированной памяти, а также простые логические и арифметические операции с ней. В общем, MemorySanitizer молча отслеживает распространение неинициализированных данных в памяти и выдает предупреждение, когда ветвь кода берется (или не берется) в зависимости от неинициализированного значения.

MemorySanitizer реализует подмножество функций, найденных в Valgrind (инструмент Memcheck).

Это должно работать для этого случая, потому что вызов glibc memcpy с length вычисленной из неинициализированной памяти, приведет (внутри библиотеки) к ответвлению на основе length . Если бы в нем была встроенная версия без cmov , в которой использовались только cmov , indexing и два хранилища, это могло бы не cmov .

Memcheck от Valgrind также будет искать такую ​​проблему, опять же, не жалуясь, если программа просто копирует неинициализированные данные. Но он говорит, что обнаружит, когда «условный переход или перемещение зависит от неинициализированных значений», чтобы попытаться отследить любое внешне видимое поведение, которое зависит от неинициализированных данных.

Возможно, идея не отмечать только загрузку состоит в том, что структуры могут иметь заполнение, и копирование всей структуры (включая заполнение) с широкой векторной загрузкой / сохранением не является ошибкой, даже если отдельные элементы были записаны только по одному за раз. На уровне asm информация о том, что было дополнением и что на самом деле является частью значения, была потеряна.


В bool разрешено хранить только значения 0 или 1 , а сгенерированный код может предполагать, что он будет содержать только одно из этих двух значений. Код, сгенерированный для троичной переменной в присваивании, может использовать значение в качестве индекса в массиве указателей на две строки, то есть его можно преобразовать во что-то вроде:

     // the compile could make asm that "looks" like this, from your source
const static char *strings[] = {"false", "true"};
const char *whichString = strings[boolValue];

Если boolValue неинициализирован, он может содержать любое целочисленное значение, что приведет к доступу за пределы массива strings .


Резюмируя ваш вопрос, вы спрашиваете: позволяет ли стандарт C ++ компилятору предполагать, что bool может иметь только внутреннее числовое представление «0» или «1» и использовать его таким образом?

Стандарт ничего не говорит о внутреннем представлении bool . Он определяет только то, что происходит при приведении bool к int (или наоборот). Главным образом, из-за этих интегральных преобразований (и того факта, что люди полагаются на них довольно сильно), компилятор будет использовать 0 и 1, но это не обязательно (хотя он должен учитывать ограничения любого ABI более низкого уровня, который он использует ).

Таким образом, компилятор, когда он видит bool имеет право считать, что указанный bool содержит либо « true », либо « false » битовый паттерн, и делать все, что ему нравится. Поэтому, если значения true и false равны 1 и 0 соответственно, компилятору действительно разрешено оптимизировать strlen до 5 - <boolean value> . Другие забавные поведения возможны!

Как неоднократно указывается здесь, неопределенное поведение имеет неопределенные результаты. В том числе, но не ограничивается

  • Ваш код работает так, как вы ожидали
  • Ваш код не работает в случайное время
  • Ваш код вообще не запускается.

Посмотрите, что каждый программист должен знать о неопределенном поведении


Сама функция корректна, но в вашей тестовой программе оператор, вызывающий функцию, вызывает неопределенное поведение, используя значение неинициализированной переменной.

Ошибка заключается в вызывающей функции, и она может быть обнаружена путем проверки кода или статического анализа вызывающей функции. Используя ссылку на проводник компилятора, компилятор gcc 8.2 обнаруживает ошибку. (Может быть, вы могли бы подать отчет об ошибке в Clang, что он не находит проблему).

Неопределенное поведение означает, что может произойти все что угодно , включая сбой программы через несколько строк после события, которое вызвало неопределенное поведение.

NB. Ответ на вопрос «Может ли неопределенное поведение вызвать _____?» всегда "да". Это буквально определение неопределенного поведения.






abi