caxapa.ru :: За обращение к невыровненным данным методом отличным от memcpy нужно сжигать.

fk0, легенда (04.02.2015 12:20, просмотров: 243) ответил Petrovich на Подскажите, коллеги, для Кортексов, умеющих обращаться по невыровняным данным в RAM, существует проблема неатомарности обращений к 2-3-4-байтовому данному, используемому и в теле и в прерывании? То есть лучше запрещать прерывания на время доступа

За обращение к невыровненным данным методом отличным от memcpy нужно сжигать. PS: при обращении к структурам тоже не атомарно. И к float с double. И ещё фиг знает куда. Не для того ли существует sig_atomic_t (в новых C/C++ стандартах есть более другой похожий тип).

[ZX]

Ответить

- memcpy использует ldrd иногда, что так же приводит к hardfault - Mikla(04.02.2015 12:35)
  - А расскажите пожалуйста поподробнее для малознакомого с CortexM3, как оно пришло к hardfault. Сам принцип и путь к ошибке. Очень интересно, но непонятно что там творится) - Олдфаг(04.02.2015 21:18, )
    - в memcpy использовались указатели на long, компилятор считает что они всегда выравнены на границу 4 байт и заюзал команды LDRD STRD которые не умеют обращаться по невыровненному адресу. указатель был невыровненный, что и привело к hardfault. Mikla(212 знак., 05.02.2015 11:09)
      - Спасибо за разъяснения. - Олдфаг(05.02.2015 15:46, )
    - о! Это очень увлекательная история, у меня после АВРок и ПИКов было чувство глубокого когнитивного диссонанса :) - Nikolay801_(05.02.2015 10:02)
  - ААА! Теперь не использовать memcpy??? Или может просто не подсовывать неправильные аргументы в memcpy. Вообще её компилятор инлайнит и код может нагенерить какой больше подходит в данной ситуации. - fk0(04.02.2015 12:39)
    - пример неправильных аргументов приведите, может быть указатели должны быть выравнены только на границу 8байт или на 4 в худшем случае по вашему? а если не так, то это неправильные аргументы? - Mikla(04.02.2015 15:41)
      - Просто не надо извращаться с приведением типов указателя. Тады компайлер и memcpy сделают все правильно. - LightElf(04.02.2015 18:51)
        
        не знаю какие там были указатели, не у меня было когда memcpy вывалился в hardfault. знаю что длина строки была 8 и компилер подставил ldrd. при изменении длины строки на любое другое число все было нормально. а если бы другой тип указателя был, Mikla(247 знак., 04.02.2015 19:26)
        
        Надо смотреть что в конкретном случае сгенерил кейл. Я с кейлом не знаком. В общем случае компилятор выберет интринсик, основываясь в том числе и на типах указателей. И ежели указатели имеют тип int *, то компилер разумно предположит что они LightElf(55 знак., 04.02.2015 19:52)
        
        да, счас экспериментировал, вы правы. реализация memcpy зависит от типа указателей. Mikla(463 знак., 04.02.2015 20:44)
        
        А вот не надо в указателях на long хранить неровные адреса. Стандарт языка так и говорит: undefined behavior. - SciFi(05.02.2015 00:56)
        
        А вот не надо в функции ожидать, что указатель void* куда-то выровнен. - LightElf(08.02.2015 17:13)
        
        Это он зря, конечно, но закон на его стороне. - SciFi(08.02.2015 17:15, ссылка)
        
        Компиляторная магия, фуле! Из-за подобных непоняток выкинул стандартные либы и использую свой велосипед, ~~с квадратными колесами~~ LightElf(153 знак., 04.02.2015 22:27)
        
        а я наоборот, использую мемкопи только библиотечную. это с тех пор, как меня кроссворк на тесте скорости этой самой мемкопи уделал в раза три по скорости. в общем я перестал считать себя умнее компилятора. Mahagam(138 знак., 04.02.2015 23:03)
        
        В описываемом случае двусмысленность. memcpy объявлена, как принимающая указатели void*. Логично предположить, что параметры должны рассматриваться как нетипизированные и выравнивание должно проверяться/фикситься в рантайме. Но компиляторная LightElf(24 знак., 05.02.2015 14:37)
        
        Логично предположить, что если неровный адрес приведён к типу (long*), то возможны неприятности. Что и произошло. Стандарт не нарушен: SciFi(217 знак., 05.02.2015 15:11)
        
        не компиляторная! библиотечная. насколько я понял из либы, там сначала копировались байты чтобы выровнять адреса приёмника и источника (если это было возможно), а потом запускался цикл с LDM/STM на все регистры. ну и под конец копировался Mahagam(186 знак., 05.02.2015 14:52)
        
        Кофейная гуща не есть кошерная пища :-) - SciFi(04.02.2015 19:54, ссылка)
        
        Код - в студию. Гадание на кофейной гуще кого-то увлекает, но нуевонафик. - SciFi(04.02.2015 19:35)
        
        завтра кодер придет, может вспомнит этот код. счас попробую воспризвести, правда у меня keil поновее чем у него - Mikla(04.02.2015 19:39)
        
        Там нужно разбираться. Не тот МК, не та библиотека, кривой тулчейн, кривые руки. Тысяча возможных причин. - SciFi(04.02.2015 19:23)
- Процессоростроители из арма дурачки, зачем-то сделали невыровненный доступ :-))) - SciFi(04.02.2015 12:30)
  - Таки дурачки. Автор треда прекрасно показал пример, к чему оно ведёт. Оно провоцирует говнокод с трудноуловимыми глюками. Лучше бы сразу валилось. И little endian из той же серии: int a=5; int b=*(char*)&a -- на нормальной (big endian) архитектуре fk0(291 знак., 04.02.2015 12:42)

ARM, RISC-V контроллеры