Вход Наше всё Теги codebook 无线电组件 Поиск Опросы Закон Вторник
26 ноября

О смысле всего сущего 0xFF Средства и методы разработки Мобильная и беспроводная связь Блошиный рынок Объявления

Микроконтроллеры PLD, FPGA, DSP AVR PIC ARM, RISC-V Технологии Кибернетика, автоматика, протоколы Схемы, платы, компоненты

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

577479 Топик полностью

Mikla (04.02.2015 12:35, просмотров: 212) ответил fk0 на За обращение к невыровненным данным методом отличным от memcpy нужно сжигать.

memcpy использует ldrd иногда, что так же приводит к hardfault

Ответить

- А расскажите пожалуйста поподробнее для малознакомого с 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)