Как к выравниванию данных об улове дает сбой на x86 (иначе SIGBUS на Sparc)
Это так или иначе возможно к отказам выравнивания данных об улове даже на i386? Возможно, путем установки i386 определенной машины регистрируются или что-то как этот.
На Sparc Соляриса я получаю SIGBUS в этом случае, но на i386 все прекрасно.
Среда:
- 32-разрядное приложение
- Кармическая Ubuntu
- gcc/g ++ v4.4.1
Править: Вот то, почему я спрашиваю это:
- наши сбои приложения на Sparc Соль с SIGBUS. В целях отладки я попытался бы получить подобное поведение на нашей i386 платформе.
- наша машина Соль-sparc является очень медленной, так компилирует, и отладка занимает много времени там. И наша i386 машина невероятна быстрый (8 ядер, 32G память).
- Даже на i386 платформах существует стоимость производительности на отказах выравнивания данных. И поэтому я хотел бы зафиксировать отказы выравнивания данных по мере возможности.
5 ответов
Чтобы расширить ответ Вокухила-Олиба, глядя на поток « SOF Mis-alignters on x86. », кажется, что gcc может генерировать код с неправильно выровненным доступом к памяти . AFAIK у вас нет никакого контроля над этим.
Включение проверок выравнивания для скомпилированного кода gcc было бы плохой идеей. Вы рискуете получить ошибки SIGBUS для хорошего кода C.
Отредактировано: извините за это
Тем временем я нашел документ по процессору Intel, посвященный этой теме.
См. Руководство разработчика программного обеспечения для архитектур Intel® 64 и IA-32 .
Похоже, что это так. сложно собрать все это вместе. Однако это не кажется совершенно невозможным. Интересная глава - 4.10.5 Проверка выравнивания
РЕДАКТИРОВАТЬ (некоторый сжатый материал из упомянутого документа):
стр. 5-60
Interrupt 17 Alignment Check Exception (#AC)
to enable alignment checking, the following conditions must be true:
AM flag is set(bit 18 of control regisster CR0)
AC flag is set (bit 18 of the EFLAGS)
The CPL is 3 (protected mode or virtual-8086 mode).
дополнительно - в 14.8.2.6 - Память Упоминаются ошибки контроллера . Я не знаю, то же самое, только другими словами:
table 14-11, Encoding of MMM and CCCC Sub-Fields
Address/Command Error AC 011
Intel с самого начала создавала невыровненные передачи - это было одним из преимуществ, когда x86 была совершенно новой. Я понимаю ваши причины, по которым вы хотите заблокировать невыровненный доступ, но я не думаю, что это возможно.
Edit: очень рад, что ошиблись.
Intel очень хорошо поддерживает невыровненные нагрузки. Если бы мне пришлось обнаруживать такие нагрузки на платформе Intel, я думаю, мне пришлось бы изменить valgrind , чтобы обрабатывать невыровненные нагрузки как ошибки. Такая модификация нетривиальна, но valgrind был разработан с учетом того, что пользователи могут создавать новые «инструменты». Я думаю, что простая модификация инструмента memcheck обнаружит ваши невыровненные ссылки. И отчеты об ошибках действительно очень хорошие.
Я нашел очень простое решение на SOF! См .: Неверно выровненные указатели на x86 .
int main(int argc, char **argv)
{
# if defined i386
/* EDIT: enable AC check */
asm("pushf; "
"orl $(1<<18), (%esp); "
"popf;");
# endif
char d[] = "12345678"; /* yep! - causes SIGBUS even on Linux-i386 */
return 0;
}
Но я должен признаться, что не понимаю, почему присваивание
char d [] = "12345678";
считается неправильным -aligned?
РЕДАКТИРОВАТЬ:
на машине SPARC нет SIGBUS в строке назначения char d [] .