Требования к выравниванию и упаковке элементов структуры C++ для ARM

Question

Я хочу, чтобы структура или макет структуры были более «определены/исправлены» и меньше «до усмотрения компилятора». Макет структуры будет использоваться совместно с архитектурой x86_64 и ARMv7-A. Да, это не переносимо в целом, но для этого более ограниченного случая, континент один и тот же (и может быть преобразован, если его решили использовать на другой платформе).

Существуют ли требования к выравниванию для разных типов данных/размеров на ARMv7-A? (т. Е. Неправильное использование их является неопределенным поведением)

Или он может упаковать их в любое выравнивание? (т. Е. Все определено)

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

Я читал о требованиях к упаковке/выравниванию для ARM, но, к сожалению, я заметил, что он немного устарел относительно моей архитектуры. http://www.aleph1.co.uk/chapter-10-arm-structured-alignment-faq

Я использую заголовки, как это, на обеих архитектурах:

#pragma pack(4) 
struct foo 
{ 
    uint8_t bar1;  // 1 byte, the 3 padding bytes 
    std::array<double,1> bar2; // 8 bytes 
}; 
#pragma pack() 

Я использую перекрестное GCC компилятор для ARM: gcc -Wall -Wextra -Wcast-align -march=armv7-a -mfloat-abi=softfp -mfpu=neon -mtune=cortex-a9

Когда я звоню foo abc; abc.bar2.data(); и компилировать с -fsanitize=undefined -fsanitize=address производит ошибка времени выполнения:

runtime error: member call on misaligned address 0xbeeb0c44 for type 'struct array', which requires 8 byte alignment 
0xbeeb0c44: note: pointer points here 
    01 00 00 00 03 00 00 00 03 00 00 00 01 00 00 00 f4 0d eb be fc 0d eb be c0 a5 00 00 00 00 db 4b 
      ^
/sysroot.../usr/include/c++/5.2.0/array:230:32: runtime error: reference binding to misaligned address 0xbeeb0c44 for type 'const double', which requires 8 byte alignment 
0xbeeb0c44: note: pointer points here 
    01 00 00 00 03 00 00 00 03 00 00 00 01 00 00 00 f4 0d eb be fc 0d eb be c0 a5 00 00 00 00 db 4b 
      ^

Мне нравится доверять саниту ser, и это заставляет меня думать, что это плохо. Однако, если я выключу санитарии и оптимизирую вверх до -O3, это будет хорошо. Однако я мог бы просто (un) повезло, и этот случай неопределенного поведения просто работает нормально. Я помню, что раньше у меня было предупреждение об отключении -Wcast-align, когда я упаковал (1) вместо пакета (4), но я не помню, как я обращался к нему, чтобы получить его. Я предполагаю, что это также указывает на то, что это, вероятно, неопределенное поведение. Правда ли, что адрес sanitiser и -Wcast-align указывали на неопределенное поведение для этой архитектуры, хотя он, похоже, работал?

Было ли рекомендовано увеличить пакет (8) для устранения неопределенного поведения? Это, к сожалению, увеличивает использование памяти.

И, наконец, является pragma pack(n) или __attribute__((packed)) для каждого объекта структуры предпочтительным способом для этого? (__attribute__((packed)) является расширением GCC и, к сожалению, не может указывать размер упаковки.)

Answer 1

Всегда будет штраф за производительность для неуправляемых доступов, потому что для одного доступа вам может понадобиться коснуться двух строк кэша.

Я полагаю, что точная реакция на неприсоединившиеся обращения (замедление или неисправность) не определяется описанием архитектуры, но может быть оставлена ​​для реализации.

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