Wpis z mikrobloga

Oglądam sobie jakieś filmiki w tle na temat "BIOS Corruption" z #ps1. I naszło mnie pytanie - jak się zachowuje program uruchomiony na bardzo niskim poziomie, gdy trafi na jakiś niezłapany błąd? W sensie mając np maszynę, i na niej uruchomiony program - jedyny sam w sobie - co się dzieje gdy "nie potrafi" on dalej działać? Zwiesza się, wyłącza czy jak? #pytanie #programowanie #embedded (może wy coś będziecie wiedzieć)
  • 17
Nie wiwm czy dobrze Cie rozumiem, ale chyba zalezy od bledu, ale moze sie zapetlic, moze zjarac, a moze wyłączyc jak ma jakies zabezpieczenia - chyba.
@NewEpisode: jaką sytuację masz dokładnie na myśli? W jakim sensie "nie potrafi"? Program może po prostu nie sprawdzić czy wystąpił błąd. Np. przy zapisie do pliku skończyło się miejsce na dysku. Dane, które miały trafić do pliku zostaną utracone, ale program będzie działać dalej, może nawet poprawnie. Może być też tak, że np. program czeka na jakieś dane, połączenie zostało zerwane, a program tego nie zauważył. Utknie więc na zawsze.
Program
Dajmy dla przykładu wywołanie funkcji z nieprawidłową ilością argumentów.


@NewEpisode: będzie mieć bałagan na stosie i zacznie się zachowywać nieprzewidywalnie, np. nie będzie mógł wrócić z tej funkcji i skoczy w jakieś losowe miejsce. Będzie sobie skakał i wykonywał przypadkowe instrukcje aż nie wykona jakiejś nieprawidłowe operacji, którą wychwyci rdzeń procesora lub OS (jeśli istnieje).
@NewEpisode: dobre pytanie :) Adresy handlerów są w określonych miejscach pamięci. W pamięci zawsze coś jest, jeśli nie adres handlera, to jakieś przypadkowe dane. Więc pewnie procesor tam skoczy i będzie wykonywać przypadkowe instrukcje aż znów nie trafi na jakiś wyjątek.
@zarowka12: Masz jakąś wiedzę żeby poczytać na ten temat? Bardzo to ciekawe. Plus ostatnie pytanie - czy filmiki w stylu "bios corruptions" są spowodowane tym że brakuje takiego handlera i wykonuje się śmieciowy kod (skakanie po pamięci) za wszelką cenę?
@NewEpisode: tak na szybko:
https://www.embien.com/blog/interrupt-handling-in-arm-cortex-m/
https://www.youtube.com/watch?v=mNUH0O_4Zn8
https://interrupt.memfault.com/blog/arm-cortex-m-exceptions-and-nvic
Działanie tych handlerów znam z ARM Cortex-M. Nie wiem jak jest z wyjątkami na x86. Pytanie też w jakich okolicznościach procesor może się zatrzymać. Na pewno może tak się zdarzyć pod debuggerem, ale nie wiem jak z wyjątkami. Trzeba by się dobrze wczytać w dokumentację danego rdzenia.
@NewEpisode: Możesz sobie w takim handlerze ustawić wykonanie resetu poprzedzone na przykład zapisaniem wartości rejestrów i ewentualnie stosu w celu późniejszego debugowania w jakiej funkcji i okolicznościach wystąpił błąd. Jeśli ustawisz sobie watchdog to program się i tak zresetuje na domyślnym handlerze z while(true) w środku.
via Wykop Mobilny (Android)
  • 0
@Agent_Dijkstra: dzięki za odpowiedź, jeszcze kilka godzin temu nie wiedziałem nic o tych handlerach :D Świetna sprawa, szkoda tylko że świat embedded jest tak skomplikowany ( ͡° ʖ̯ ͡°) człowiek by chciał całą wiedzę na świecie przyswoić a na to życia braknie.
@NewEpisode: te "handlery" nazywają sie exception handlers (wyjątki). Na praktycznie każdym CPU jest ich co najmniej kilka, wśród nich wektor nierozpoznanej operacji czy dzielenia przez zero. Sa tez od innych bloków sprzętowych np MMU od nie zmapowanego adresu. Za ustawienie tych wektorów odpowiada program na najwyzszym poziomie uprzywilejowania, zazwyczaj OS. Przed OS ustawia je bootloader. Ustawianie wektorów wyjątków jest pierwsza rzeczą jaką sie wykonuje po włączeniu zasilania nawet przed rozpędzenie PLL
@Rosly: Podziwiam za taką wiedzę! ( ͡° ͜ʖ ͡°) Dzięki za konkretne wytłumaczenie, będę grzebał dalej bo działka jest naprawdę ciekawa, a pisząc w pythonie omija mnie sporo z tego co widzę ( ͡º ͜ʖ͡º)