hard fault на stm32f103rb при работе с указателями на uint64

[auric]

программа улетает в hard fault на stm32f103rb при работе с указателями на uint64_t. Код на Си простой: берется указатель на uint64_t и загружается в переменную с таким же типом значение с произвольного адреса (ну получается нужно 2 регистра). Если смотреть по ассемблеру, то не идут команды LDMIA (или LDRD если компилить в другой версии GNU), но собственно сценарий примерно один, берется адрес, который по условиям ассемблерной команды должен быть кратен 4 (кто б подсказал зачем), а у меня он в принципе произвольный и выравнивание мне там не сделать, как быть?

[Reflector]

Невыровненный доступ поддерживают только простые инструкции LDR/STR, а LDRD уже требует выравнивания. Когда-то мне помогало в подобном случае указатель объявлять как volatile, тогда gcc вместо LDRD генерил LDR, но никаких гарантий... Если не сработает, то пиши на инлайн ассме используя инструкции не требующие выравнивания или указатель приводи к 32-х битному.

[Professor Chaos]

у меня он в принципе произвольный и выравнивание мне там не сделать, как быть?

Написать функцию типа uint64_t GetUint64(void* p) и использовать её. Внутри неё будете считывать 8 байт по указателю и формировать из них возвращаемое значение. Это распата за невыровненный доступ. Зато работать будет всегда и везде.

[astrahard]

А не пробовали написать свой обработчик hard fault, может не страшно. Win-да в такие ситуации попадает по 20 раз в секунду и, ничего, никто не журчит....

[auric]

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

[ArtDen]

А можно минимальный пример для воспроизведения? Похоже на баг в компиляторе

[astrahard]

[uquote="auric",url="/forum/viewtopic.php?p=4096658#p4096658"]Порешал, обработка теперь интом, потом склейка, как и писали дольше, зато гарантировано. Просто странно, что мешало сделать инструкции без выравнивания и что мешало сделать в компиляторе проверки и не генерить падающий на асме код.[/uquote]

Напишите обработчик HardFault, который исправляет ситуацию на лету.

Добавлено after 11 minutes 11 seconds:
[uquote="ArtDen",url="/forum/viewtopic.php?p=4096952#p4096952"]А можно минимальный пример для воспроизведения? Похоже на баг в компиляторе[/uquote]
Как-то неопределенно выразились. Это и есть БАГ компилятора. Только его исправлять никто не хочет. Сейчас модно писать на Java. Следуя этой моде как раз я и предлагаю поправить компилятор написав обработчик HardFault, исправляющий ситуацию "на лету". И вообще, нужно для всех без исключения HardFault иметь свои обработчики. Это не трудно, без них Вы делаете вывод о необходимости править исходники, а с ними этого можно не делать. Т.е. исходники не править. Компилятор считает, что это проблема процессора и не собирается под него подстраиваться. Это, своего рода традиция.

[Reflector]

[uquote="ArtDen",url="/forum/viewtopic.php?p=4096952#p4096952"]А можно минимальный пример для воспроизведения? Похоже на баг в компиляторе[/uquote]

Код: Выделить всё

uint32_t arr[10];
volatile uint32_t* p = (uint32_t*)((uint8_t*)arr + (GPIOA->IDR & 7));
*p++ = 0x55;
*p++ = 0x55;
*p++ = 0x55;
*p++ = 0x55;

В таком виде gcc 10.2 генерит четыре STR, а если убрать volatile, то получим STR+STRD+STR. Заменив чтение IDR константой компилятор будет знать во время компиляции точный адрес и даже без volatile подставит STRD только если адрес выровненный.

[ArtDen]

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

[Reflector]

А ТС изначально написал, что адреса у него произвольные и выравнивание не сделать.

[ArtDen]

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

Код: Выделить всё

char aaa[10] = {};
volatile uint64_t *ptr = (uint64_t*)(aaa+1);
*ptr = 0x1234567887654321;

Последнюю строку gcc-arm-none-eabi-10.3-2021.07 при -O3 компилирует в

Код: Выделить всё

ldrb.w	r3, [sp, #13]         
movs	r3, #33	; 0x21        
strb.w	r3, [sp, #13]         
ldrb.w	r3, [sp, #14]         
movs	r3, #67	; 0x43        
strb.w	r3, [sp, #14]         
ldrb.w	r3, [sp, #15]         
movs	r3, #101	; 0x65
strb.w	r3, [sp, #15]         
ldrb.w	r3, [sp, #16]         
mvn.w	r3, #120	; 0x78
strb.w	r3, [sp, #16]         
ldrb.w	r3, [sp, #17]         
movs	r3, #120	; 0x78
strb.w	r3, [sp, #17]         
ldrb.w	r3, [sp, #18]         
movs	r3, #86	; 0x56        
strb.w	r3, [sp, #18]         
ldrb.w	r3, [sp, #19]         
movs	r3, #52	; 0x34        
strb.w	r3, [sp, #19]         
ldrb.w	r3, [sp, #20]         
movs	r3, #18               
strb.w	r3, [sp, #20]         

А если компилятор не знает, но программист допускает такое обращение - то повторюсь, он ССЗБ

[Professor Chaos]

Если компилятор заранее знает, что будет идти доступ по невыровненному адресу

А если неизвестно? Т.е. адрес может быть произвольным: как выровненным, так и нет. Что ДОЛЖЕН сделать компилятор?
Например:

Код: Выделить всё

uint64_t getUint64(void* buf_p) {
    return *((uint64_t*)buf_p));
}

Будет ли выровнен указатель buf_p заранее неизвестно. Может да, а может нет. И тот и другой случаи возможны и равновероятны.

[ArtDen]

Если заранее неизвестно, то компилятор генерирует максимально быстрый код, не допускающий невыровненные адреса Это достаточно разумный подход, но приводящий к хардфаулту у программистов, которые ещё не знают от такой особенности ))

[jcxz]

[uquote="auric",url="/forum/viewtopic.php?p=4096658#p4096658"]что мешало сделать в компиляторе проверки и не генерить падающий на асме код.[/uquote]
А что мешало вам прочитать доку на компилятор и узнать, что всё уже давно имеется?: если объявить указатель на пакованный тип, то компилятор вместо LDRD/STRD генерит пару LDR/STR.
IAR:
typedef __packed unsigned long long u64p;
и все обращения к u64p будут только инструкциями, умеющими невыровненный доступ.

Добавлено after 7 minutes 38 seconds:
[uquote="ArtDen",url="/forum/viewtopic.php?p=4097143#p4097143"]Последнюю строку gcc-arm-none-eabi-10.3-2021.07 при -O3 компилирует в[/uquote]
А какое это имеет отношение к теме? Такое сгенерилось видимо для какого-то младшего ядра (M0, etc.). А у ТС - Cortex-M3. Для него вменяемый компилятор, в случае невыровненного доступа, должен генерить пару LDR/STR, а не ворох LDRB/STRB.

[ArtDen]

[uquote="jcxz",url="/forum/viewtopic.php?p=4097296#p4097296"]А какое это имеет отношение к теме? Такое сгенерилось видимо для какого-то младшего ядра (M0, etc.)[/uquote]

Забыл указать. Компилировалось это с флагом -mcpu=cortex-m4 для STM32F401

Сейчас проверил. Для cortex-m3 генерируется точно такой-же код.

[jcxz]

[uquote="ArtDen",url="/forum/viewtopic.php?p=4097387#p4097387"]Забыл указать. Компилировалось это с флагом -mcpu=cortex-m4 для STM32F401

Сейчас проверил. Для cortex-m3 генерируется точно такой-же код.[/uquote]
Странно это... Так как не нужно там по-байтно.
IAR, например, код:

Код: Выделить всё

__packed unsigned long long volatile z = 0;
z++;
printf("%llu", z);

компилит в:

Код: Выделить всё

LDR.N    R5,??DataTable12_1
LDR      R0,[R5, #+72]
LDR      R1,[R5, #+76]
ADDS     R0,R0,#+1
SBC      R1,R1,#-1
STR      R0,[R5, #+72]
STR      R1,[R5, #+76]
LDR      R2,[R5, #+72]
LDR      R3,[R5, #+76]
ADR.W    R0,?_2
BL       _printf

т.е. - по паре LDR/STR на обращение.
Полная оптимизация вкл.
Убираем __packed и получаем:

Код: Выделить всё

LDR.N    R5,??DataTable12_1
LDRD     R0,R1,[R5, #+24]
ADDS     R0,R0,#+1
SBC      R1,R1,#-1
STRD     R0,R1,[R5, #+24]
LDRD     R2,R3,[R5, #+24]
ADR.W    R0,?_2
BL       _printf

что и ожидалось....

Может у вас там для компилятора какая-то опция выставлена, говорящая, что на CPU принудительно запрещён невыровненный доступ? Ведь и на >=Cortex-M3 можно запретить невыровненный доступ установкой бита UNALIGN_TRP в CCR.

[astrahard]

Так "всё уже давно имеется" говорил или все-же "странно"?

Так обработчик HardFault писать будем?

[jcxz]

[uquote="astrahard",url="/forum/viewtopic.php?p=4097458#p4097458"]Так "всё уже давно имеется" говорил или все-же "странно"?[/uquote]Может сначала научимся читать сообщения?
Я это говорил про пакованные данные.
Где пример для GCC с пакованными 64-битными данными? Не вижу - никто не попробовал видимо. Для IAR я привёл.

[ArtDen]

jcxz, если не веришь, можешь просто поиграться онлайн:
https://gcc.godbolt.org/z/ex1e5dcah
Там налету и компилируется и дизасемблер отображается. Опции компиляции тоже можно менять

[jcxz]

[uquote="ArtDen",url="/forum/viewtopic.php?p=4097468#p4097468"]jcxz, если не веришь, можешь просто поиграться онлайн:
https://gcc.godbolt.org/z/ex1e5dcah
Там налету и компилируется и дизасемблер отображается[/uquote]
Понял. Компилит он так, потому что пример ваш некорректный. Вы объявили байтовый массив, а не 64-битную переменную (о чём вообще-то эта тема).
Видимо, так как GCC видит, что это именно массив байт, потому его оптимизатор и генерит такой код.
Достаточно ему написать корректный пример:

Код: Выделить всё

    extern volatile uint64_t aaa;
    volatile uint64_t *ptr = (uint64_t*)(&aaa+1);
    *ptr = 0x1234567887654321;

Как будут вполне ожидаемые LDRD/STRD.

Т.е. - volatile в случае GCC никак не спасает от исключения невыровненного доступа. Не поможет оно.