Summary: | gcc на armh сообщает о поддержке невыравненного доступа к памяти, использование которого приводит к SIGBUS | ||
---|---|---|---|
Product: | Sisyphus | Reporter: | Aleksei Nikiforov <darktemplaralt> |
Component: | gcc9 | Assignee: | Gleb F-Malinovskiy <glebfm> |
Status: | CLOSED NOTABUG | QA Contact: | qa-sisyphus |
Severity: | normal | ||
Priority: | P5 | CC: | asheplyakov, darktemplaralt, glebfm, iv, sbolshakov |
Version: | unstable | ||
Hardware: | arm | ||
OS: | Linux |
Description
Aleksei Nikiforov
2020-09-25 17:04:59 MSK
Начиная с armv6 unaligned access поддерживается (с известными ограничениями), см. https://www.keil.com/support/man/docs/armasm/armasm_dom1359731171041.htm У нас поддерживается armv7a и новее. А поэтому > gcc -dM -E - < /dev/null | grep __ARM_FEATURE_UNALIGNED > Результат: > #define __ARM_FEATURE_UNALIGNED 1 результат ожидаемый и правильный. Я не думаю, что получаемый при этом SIGBUS - результат ожидаемый и правильный. (In reply to Aleksei Nikiforov from comment #2) > Я не думаю, что получаемый при этом SIGBUS - результат ожидаемый и > правильный. Из приведенных Вами данных никак не следует, что ошибка вызвана именно компилятором, а не кодом, который Вы собираете. > gcc не должен по-умолчанию выставлять макрос __ARM_FEATURE_UNALIGNED То есть все процессоры будут притворяться armv5, чтобы libfoo нормально собралась. Нет, спасибо. (Ответ для Alexey Sheplyakov на комментарий #4) > https://github.com/erthink/t1ha/issues/45 https://git.altlinux.org/gears/l/libt1ha.git?p=libt1ha.git;a=commitdiff;h=b59561ef13ff75caf38d6ab16315f8a3c8e93513 Предложенное исправление делает примерно то же самое, что сделал уже я при сборке t1ha: отключает unaligned access на armh. Раз уж и апстрим предлагает подобное решение, предлагаю баг закрыть. Автор t1ha предположил, что 1) из __ARM_FEATURE_UNALIGNED следует, что возможно чтение 64-битного значения по адресу, не кратному 8 байт. 2) что такое чтение эффективно. На самом же деле оба предположения НЕВЕРНЫ. __ARM_FEATURE_UNALIGNED_ACCESS означает, что можно читать/писать 32-х (16-ти) битные значения по адресу, не кратному 4-м (2-с) байтам. По поводу эффективности ничего не гарантируется (гарантируется только, что такое чтение/запись не вызовут исключения). |