Maksymalny rozmiar stosu potrzebny dla programu C na MSP430

Question

W programie C, który nie korzysta z rekursji, teoretycznie powinno być możliwe obliczenie maksymalnego/najgorszego rozmiaru stosu potrzebnego do wywołania danej funkcji i wszystkiego, co jest potrzebne. to wywołuje. Czy są jakieś darmowe narzędzia open source, które mogą to zrobić, albo z kodu źródłowego, albo ze skompilowanych plików ELF?

Czy istnieje sposób na wyodrębnienie rozmiaru ramki stosu funkcji z pliku ELF, aby można było spróbować go rozwiązać ręcznie?

Kompiluję dla MSP430 używając MSPGCC 3.2.3 (wiem, że to stara wersja, ale muszę w tym przypadku użyć). Miejsce na stos do przydzielenia jest ustawione w kodzie źródłowym i powinno być tak małe, jak to tylko możliwe, aby reszta pamięci mogła być wykorzystana do innych celów. Czytałem, że musisz wziąć pod uwagę przestrzeń stosu używaną przez przerwań, ale system, którego używam, już to uwzględnia - staram się ustalić, ile dodatkowego miejsca należy dodać. Ponadto, czytałem, że wskaźniki funkcji utrudniają to. W tych kilku miejscach, w których są używane wskaźniki funkcji, wiem, które funkcje mogą wywoływać, więc można wziąć pod uwagę te przypadki ręcznie, jeśli przestrzeń stosu potrzebna dla wywoływanych funkcji i funkcji wywołujących była znana.

Analiza statyczna wydaje się bardziej niezawodną opcją niż malowanie w stosie w środowisku wykonawczym, ale praca w środowisku wykonawczym jest opcją, jeśli nie ma sposobu, aby zrobić to statycznie.

Edit:

znalazłem GCC -fstack-usage flagę, która oszczędza rozmiar ramki dla każdej funkcji, ponieważ jest skompilowany. Niestety, MSPGCC nie obsługuje tego. Ale może być przydatny dla każdego, kto próbuje zrobić coś podobnego na innej platformie.

Answer 1

Interesujące pytanie.

Oczekuję, że informacje te będą statycznie dostępne w danych debugowania zawartych w kompilacjach debugowania.

miałem krótkie spojrzenie na standardzie DWARF i robi określić dwa atrybuty funkcji zwanych DW_AT_frame_base i DW_AT_static_link które mogą być wykorzystywane do „oblicza podstawę rama odpowiedniej instancji podprogramu że natychmiast zamyka podprogram lub punkt wejścia ".

Answer 2

Myślę, że jedyne, do którego należy się udać, to analiza statyczna. Musisz obliczyć miejsce dla wszystkich niestatycznych zmiennych lokalnych, które będą głównie wskaźnikami, ale wskaźniki, które i tak będą przechowywane w stosie, musisz także zarezerwować miejsce na bieżący adres w ramach caller, ponieważ będzie przechowywany przez kompilator na stosie, więc kontrola może zostać zwrócona do wywołującego po powrocie funkcji, a także, potrzebujesz miejsca na wszystkie parametry funkcji. Na tej podstawie, jeśli dysponujesz narzędziem umożliwiającym zliczanie wszystkich parametrów, zmiennych automatycznych i obliczanie ich rozmiaru, powinieneś być w stanie obliczyć minimalny rozmiar stosu, który będziesz potrzebować. Należy pamiętać, że kompilator może również próbować wyrównać wartości na stosie dla konkretnej architektury, co może sprawić, że wymagania dotyczące przestrzeni stosu będą trochę większe, niż można oczekiwać od tego obliczenia.

Answer 3

Niektóre wbudowane IDE mogą podawać informacje na temat używania pakietu w środowisku wykonawczym Wiem, że wspierany przez IAR eembedded workbench jest obsługiwany.

Pamiętaj, że musisz wziąć pod uwagę, że przerwania występują asynchronicznie, więc weź największy scenariusz użycia stosu i dodaj do niego kontekst przerwań. Jeśli obsługiwane są przerwań zagnieżdżonych, podobnie jak w procesorach ARM, należy wziąć to również pod uwagę.

Answer 4

Podczas gdy analiza statyczna jest najlepszą metodą określania maksymalnego użycia stosu, może być konieczne zastosowanie metody eksperymentalnej. Ta metoda nie może zagwarantować ci absolutnego maksimum, ale może dostarczyć ci bardzo dobry pomysł na wykorzystanie twojego stosu.

Możesz sprawdzić swój skrypt linkera, aby uzyskać lokalizację __STACK_END i __STACK_SIZE. Możesz ich użyć, aby wypełnić przestrzeń stosu łatwo rozpoznawalnym wzorcem, takim jak 0xDEAD lub 0xAA55. Przeprowadź swój kod przez test torturowania, aby upewnić się, że wygenerowano jak najwięcej przerwań.

Po zakończeniu testu można sprawdzić przestrzeń stosu, aby sprawdzić, jaka część stosu została nadpisana.

Answer 5

TinyOS wykonał pewną pracę nad analizą wielkości stosu. Jest on opisany tutaj: http://tinyos.stanford.edu/tinyos-wiki/index.php/Stack_Analysis

Obsługują tylko AVR, ale mówią, że "MSP430 nie jest trudny do obsługi, ale nie jest to super wysoki priorytet". W każdym przypadku strona zapewnia wiele zasobów.