ReAl

Щось останнім часом я практично лише про помилки і пишу. Але тут поруч з поганою новиною є і хороша.

Ще десь перед новим роком виявив біду — у найсвіжішому на той час OpenOCD команда stm32f1x unlock захист зчитування наче знімає, але по тому записати у мікроконтролер нічого не вдається.

На щастя, у мене десь лежала перевірена версія, зібрав її, встановив і все пішло. Вже десь у січні підключився до OpenOCD через telnet, потикався різними командами і з’ясував, що в усі option bytes (окрім readout protection) записані випадкові значення, тобто на довільні сектори flash-пам’яті було встановлено захист від запису, а також попсовано опції SW/HW WDT і інші.

І оце лише на минулому тижні розібрався. Драйвер stm32f1x використовується для роботи з stm32f10x, stm32f0xx, stm32f3xx, але біда лише з stm32f10x. З’ясувалося, що в них захист від зчитування поширюється і на область флеш-пам’яті для блоку опцій. Для двох інших згаданих лінійок цього нема, у документації в табличках окремо відзначено можливість такого зчитування (при захисті з рівнем L1). Можливо, саме тому в коді зчитування опцій з регістрів FLASH_OBR і FLASH_WRPR замінили зчитуванням безпосередньо з адрес 0x1ffff800..0x1ffff80f.

Процедура unlock перед стиранням опцій зчитує їхні значення, щоб під час запису коду дозволу зчитування відновити те, що було. Але ж доступу нема, OpenOCD доповідав, що прочитати не може і йшов далі. Тобто записував випадкові значення, які на той час були у неініціалізованій структурі.

Відповідно, ремонт простий — повернутися до зчитування з регістрів. Зараз патч лежить на узгодженні в їхньому gerrit-і, а я вже користуюся виправленим 🙂

Міняв диск, заразом поміняв і Убунту 16.04 на 18.10. Як і минулого разу на шістнадцятій, поставив «рідний» для системи пакет arm-none-eabi-. Мабуть, пора закінчувати з такою практикою, всістися на якусь іншу збірку компілятора, ту ж linaro. Бо проекти перестали збиратися. І на чому, на рівному місці! Компілятор не знаходить файл cstdint.

Короткий пошук показав, що версія компілятора 6.3.1, include-файли лежать в /usr/lib/gcc/arm-none-eabi/6.3.1/include та в /usr/lib/gcc/arm-none-eabi/6.3.1/../../../arm-none-eabi/include, який, зрештою, вказує на /usr/include/newlib.

А от заголовочні файли C++ лежать в /usr/include/newlib/с++/7.3.1. Звідки взялася сімка — важко сказати. Може це одрук, може дійсно поклали іншу версію, але жодного файлу від C++ cpp не знаходить. Назву 7.3.1 вирішив не чіпати, просто поруч додав лінк 6.3.1->7.3.1. Після цього cpp по -v показав додаткові шляхи до файлів і все стало збиратися.

Зазвичай я не поспішаю переповзати на нову версію Ubuntu і досі сиджу в Ubuntu Mate 16.04. І я не один такий, на роботі також 16.04 (тільки не Mate, а «звичайна», зі стільницею Unity).
І от на роботі ж і виловив помилку в Doxygen, який в убунті 16.04 стоїть версії 1.8.11. Заманулося отримати для перегляду дерева викликів, CALL_GRAPH і CALLER_GRAPH, щоб швидше ознайомитися зі структурою чужого коду. А отримав страшну кашу з довгими циклічними петлями викликів. Виявилося, що всі функції, прототипи яких описано в .h-файлі безпосередньо під inline-функцією, вважаються такими, що викликані з цієї inline-функції.
Мінімальний приклад, doxy-bug.{h,c}:

Doxygen 1.8.11 генерує для inline-функції foo() такий граф викликів

а для moo() взагалі отакий:

Уявляєте, що я отримав на дереві з кількох каталогів і сотень функцій, а в h-файлах під inline-функцією може бути описано декілька прототипів, всі з яких стають «викликаними» з неї? Оскільки всі ці функції викликали ще у глибину на декілька рівнів статичні функції всередині своїх файлів, а вже ті викликали ці inline-операції, утворювалося багато довгих петель.

На щастя, у свіжій версії Doxygen 1.8.15 цю помилку виправлено. Все красиво:

Переставлю тепер doxygen і на роботі, буде легше.

або помилка повертається.

Лінкер від gcc-linaro-7.2.1-2017.11-x86_64_arm-eabi (binutils 2.28), має ту ж саму біду, що й avr-ld.
А саме *** buffer overflow detected ***, переповнення буфера sprintf (і знову лаюся — чому використано не snprintf ?!)

p.s. «родич» gcc-linaro-7.2.1-2017.11-x86_64_arm-linux-gnueabihf — the same, тобто те саме.
p.p.s. Arduino навіть для лінукса тягне всі компілятори з собою. Там не увімкнуто локалізацію, тому цієї проблеми нема. У старенького «рідного» в убунті-16.04 arm-none-eabi- теж. Все залежить від того, як збирався лінкер.

Оскільки я вже згадав у попередньому дописові про третє видання книжки Кормена і компанії «Вступ до алгоритмів» (так звану CLRS), то напишу і тут про ненароком помічену помилку в російському перекладі книжки.

Працюючи з текстом задачі 8-7 («Лема сортування 0-1 і сортування стовпцями», сторінка 208 оригіналу) вирішив зазирнути в російський переклад, як там цю лему назвали, і тут же око вихопило дуже некоректний текст.

У перекладі російською (сторінка 238) є такі слова: «докажем 0-1-лемму сортировки путём доказательства обратной к ней». Але так не буває. Ніколи-ніколи-ніколи доведення оберненого твердження не доводить пряме. Якщо істинне як пряме твердження, так і обернене, то частини тверджень еквівалентні, тобто (А⇒Б ∧ Б⇒А) ⇒ (А⇔Б). Але шляхом доведення Б⇒А неможливо довести А⇒Б.

І в оригіналі було: «prove the 0-1 sorting lemma by proving its contrapositive»

Контрапозитивне твердження (протиставлення) це протилежне оберненому (або обернене протилежному, що те ж саме), тобто (А⇒Б) ⇔ (¬Б⇒¬А) і саме ¬Б⇒¬А можна довести для доведення А⇒Б (що і зроблено далі по тексту).

Цікаво, скільки ще таких неточностей у цьому перекладі з англійської на російську? І зрозуміло, чому я проти таких подвійних перекладів навіть у «технічних» текстах.

Дійсно прикра помилка в avr-ld (binutils-avr 2.25) — та, що спонукала мене до перевірки використання Raspberry Pi як комп’ютера для роботи, — виявилася доволі цікавою.

Почала вивалюватися вона у мене доволі давно, але я помилково вважав, що вона притаманна 64-бітній версії Ubuntu 16.04, бо на роботі в 32-бітній все працювало. Думав, що це якісь проблеми невраховування розмірів чи співвідношення розмірів змінних на зразок «подаруночка від FTDI». Чесно кажучи, у повідомлення не особливо і вчитувався — «та хай, це по роботі, то на роботі й зберу» і вдома більше не запускав аж до того, як нещодавно перезібрати знадобилося негайно, бо це зупиняло термінову роботу. Тоді ж ото зібрав на Raspberry й написав про все це.

Ну й на ключову фразу *** buffer overflow detected *** Іван у коментарях пояснив, як із цим можна боротися.
Докладніше читайте » » »

Подаруночок від FTDI виявився дуже цікавим.

У повній відповідності до принципу «дивись рисунок 1» вони взяли і замінили типи даних при переході від бібліотек libftd2xx.so версій 0.4.x до libftd2xx.so.1.0.0. Подаруночок впливає лише на роботу з 64-бітними варіантами бібліотек, з 32-бітними проблем нема.

Бібліотека ftd2xx народжувалася в Windows та ще й містить в собі функції FT_W32_ххх() для роботи з мікросхемами FTDI в стилі функцій роботи з COM-портом у WinAPI. Тому в ній використовуются стандартні для WinAPI типи даних DWORD, BYTE тощо. Щоб при написанні Linux-версії бібліотеки не міняти файл ftd2xx.h та всі тексти, в проект було додано файл WinTypes.h з означеннями потрібних типів. Загалом, крок логічний, але…

Continue reading ‘Подаруночок від FTDI’ »