bleeding-edge-toolchain - kolejny toolchain dla ARM

Ponieważ kilka dni temu wypuszczona została nowa wersja paczki na której BET bazuje - GCC ARM Embedded 4.8-2013-q4-major - to i ja postanowiłem szybko zabrać się do rzeczy i skompilować nową wersję. Pliki właśnie ładują się na stronkę sourceforge, muszę jeszcze dodać odnośnik na mojej stronce...

Jak można zauważyć z nazwy jest to pierwsze wydanie tych toolchainów bazujące na GCC 4.8 (dokładnie jest to 4.8.3, zapewne jako "prerelease"). Dodatkowo dla newlib dodałem kolejną opcję - --enable-newlib-global-atexit - która zmniejsza strukturę _reent o około 130 bajtów (do dokładnie 96 bajtów).

4\/3!!

Freddie, dziękuje ponownie za wspaniałą robotę.
Lecz BET umożliwia podgląd bibliotek w czasie debugowania, lecz przy jakiejś okazji zdaje się dzielenia double, oraz ostatnio, nie było możliwe odnalezienie czegoś.
W eclipse dostaje nowe okno z info ze nie można odnaleźć pliku i odsyła do "home/freddie/....."

Tadzik, ale podgląd nie oznacza że masz całość kodu, a tylko tyle, że możesz wejść do funkcji bibliotecznej i popatrzeć na wartości zmiennych. Chyba, że się mylę

Właśnie nie wiem stad pytanie...

No jakieś zmienne mogę pooglądać, wstawiłem szybko memcmp, zmienne widzę, szkoda ze nie kod.

Zapewne trzeba by ściągnąć źródełka i ścieżki jakoś dołączyć do projektu?

Właśnie sprawdziłem nowego BETa wersje win x64. wywala się już przy 1 pliku kompilowanym.

Aby faktycznie debuggować funkcje biblioteczne (zrobić coś więcej niż zabawy z assemblerem czy podgląd zmiennych) należy sobie ściągnąć odpowiedni kod (zwykle więc będzie to newlib, czasem gcc - zależy o jakiej funkcji mowa) i gdy w Eclipse wyskoczy to okienko, że "nie znaleziono źródeł", to jest tam opcja z pytaniem o inną ścieżkę w której można je znaleźć. Po wskazaniu folderu w którym faktycznie znajduje się dany plik wszystko będzie śmigać jak trzeba.

Instrukcja "krok po kroku" - poniżej.

1. "Dochodzimy" do jakiejś funkcji którą chcielibyśmy zdebuggować, w moim przypadku niech będzie to malloc(). Albo więc należy do tej funkcji "do-step-ować", albo postawić na niej breakpointa.

2. Klikam w "Step Into" (lub F5) - Eclipse wyświetli coś takiego:

Quote:

Can't find a source file at "/home/freddie/bleeding-edge-toolchain/src/newlib/newlib/libc/stdlib/malloc.c"
Locate the file or edit the source lookup path to include its location.

3. Poniżej tego komunikatu wybieramy "Edit Source Lookup Path..."

4. W nowym okienku klikamy "Add..." i następnie wybieramy opcję "Path Mapping", zatwierdzamy klikając "OK".

5. W nowym okienku nowemu mapowaniu nadajemy jakąś nazwę (np. "newlib"). Następnie klikamy w "Add" i do kolumny "Compilation path" wpisujemy to co chcemy zastąpić - tutaj będzie to "/home/freddie/bleeding-edge-toolchain/src/newlib" - a w kolumnie "Local system file path" przy użyciu przycisku "..." wyklikujemy ścieżkę której chcemy użyć - u mnie np. jest to "d:\newlib".

4. Zatwierdzamy wszystko klikając kilka razy w "OK".

5. Cieszymy się, że wszystko działa (;

Opcje takie - niestety - są osobne dla każdej konfiguracji debuggera, tzn. że jeśli skonfigurowane są dwie (np. jedna z ładowaniem firmware'u, druga bez - ja zwykle tak właśnie mam skonfigurowane), to będzie trzeba te kroki powtórzyć też dla innych konfiguracji. Wszystkie ustawienia są tak naprawdę dostępne w opcjach konfiguracji debuggowania, zakładka Source.

Inną opcją jest skonfigurowanie globalnego mapowania - Window > Preferences > C/C++ > Debug > Source Lookup Path i robimy dokładnie to samo co wyżej.

Ważne jest, aby ten kod który "zmapujemy" był faktycznie tym kodem który jest w toolchainie. Warto więc zajrzeć do pliku "info.txt" i zobaczyć jaka dokładnie wersja (commit hash lub rewizja) została użyta i dokładnie tą sobie pobrać na dysk.

Dodano po 1 [minuty]:

tadzik85 wrote:

Właśnie sprawdziłem nowego BETa wersje win x64. wywala się już przy 1 pliku kompilowanym.

"Wywala" to się co najwyżej make. Przy zmianie toolchaina należy zrobić "make clean"... Co więcej - 32-bitowy Eclipse wymaga zapewne 32-bitowego toolchaina. Do 64-bitowego potrzebny jest więc zapewne 64-bitowy Eclipse i 64-bitowa Java. Osobiście - ze względu na takie właśnie problemy - używam wersji 32-bitowej. Różnica szybkości pomiędzy 32- a 64-bity jest praktycznie zerowa (margines błędu).

4\/3!!

nie martw się zrobiłem to...
poprzednia wersja clean
zamykam eclipse
zmieniam kompilator, kopiuje katalog zmieniam mu nazwę
uruchamiam eclipse
kompiluj
i ciągle ten bląd.

Wszystko mam w wersji 64-bity, eclipse BET jedynie msysa nie jestem pewien.
A nie 1 raz zmieniam wersje BETa

No cóż, faktycznie wersja 64-bitowa coś nie chce działać... Użyj wersji 32-bitowej i po sprawie. Wersję 64-bity usuwam. Zapewne ma to coś wspólnego ze zmianą kompilatora mingw-w64 na nowszy.

4\/3!!

Będę wdzięczny za wersje x64

Dobra, wydaje mi się, że problem z wersją 64-bitową jest rozwiązany, choć trochę ciężko mi wszystko sprawdzić... tadzik85 - jeśli masz jeszcze tą wersję 64-bitową, to rozpakuj ją sobie i do folderu gcc-arm-none-eabi-4_8-131226\bin\ (tam gdzie są wszystkie główne pliki arm-none-eabi-*.exe) wrzuć poniższy plik dll (po rozpakowaniu go oczywiście) - u mnie to pomogło...

http://www.freddiechopin.info/libwinpthread-1.7z

Daj znać - jeśli będzie OK, to przepakuję paczkę i wrzucę ponownie.

4\/3!!

w trakcie sprawdzania....

Działa, debugowanie względnie też

wydaje mi się, że może być jeszcze jakiś problem z debuggowaniem, choć tutaj może też być inna przyczyna...

Dodano po 9 [minuty]:

tadzik85 wrote:

w trakcie sprawdzania....

Działa, debugowanie względnie też

"Względnie" czyli? (;

4\/3!!

względnie czyli włączyłem debug coś poklikałem krokowo nie krokowo, popatrzyłem na zmienne i wydaje się być w porządku.....
Czyli nie zauważyłem problemu

No to spoko, wrzucam pliki spakowane ponownie - bibliotekę libwinpthread-1.dll dorzuciłem do wersji 32- i 64-bitowej.

4\/3!!

A co to za biblioteka w ogole?

pthread (wątki POSIX) dla windowsa - teraz najwidoczniej gcc wymaga tej biblioteki. Inna opcja jest taka, że poprzednio używałem kompilatora który miał inny tryb wątków (;

Wersja 64-bitowa u Ciebie nie działała, bo na kompie miałeś tą bibliotekę w wersji 32-bitowej (dlatego nie wyrzucało info, że "brak biblioteki") - ona wchodzi w skład np. mingw, wiec ze względu na konflikt architektur to nie chciało chodzić.

4\/3!!

Swoją drogą - jakby to kogoś ciekawiło - wydaje mi się, że jeden z powodów powstania bleeding-edge-toolchain, czyli szybkość oryginalnych paczek od ARM, jest już co najmniej częściowo nieaktualny. Oczywiście nie przeprowadziłem tak dużego porównania jak poprzednim razem, jednak obecnie różnice są dużo mniejsze:
- 22s vs 27s
- 20s vs 23s

Powyższe dane są oczywiście z nieco innych projektów, nieco inaczej skonfigurowanych (brak generacji plików .lst dla każdego .o), co wydaje się być główną przyczyną zmiany, ponieważ dla "starych" projektów - tych samych co poprzednio - nic się nie zmieniło w zasadzie - różnice sięgają nadal 300-400%. Ciekawe czy jakbym te projekty skonfigurowane "po nowemu" skompilował w starym linaro to by nadal była różnica (; Zobaczymy kiedyś może.

4\/3!!

Ta ale Freddie dałeś nam wersje 4.8 a linaro to widzę nadal wersję 4.7

PS. czy kwestia bugów itp itd, w przypadku BETa i Linaro jest podobna?
Skoro używasz tych samych źródeł?

tadzik85 wrote:

Ta ale Freddie dałeś nam wersje 4.8 a linaro to widzę nadal wersję 4.7

Najnowsze "linaro" to też 4.8. W końcu to te same źródła

tadzik85 wrote:

k85"]PS. czy kwestia bugów itp itd, w przypadku BETa i Linaro jest podobna?

Dla kompilatora są te same źródła, ale dla innych rzeczy już niekoniecznie. Jak już mówiłem - używać na własną odpowiedzialność (;

4\/3!!

Freddie Chopin wrote:

tadzik85 wrote:

Ta ale Freddie dałeś nam wersje 4.8 a linaro to widzę nadal wersję 4.7

Najnowsze "linaro" to też 4.8. W końcu to te same źródła

tadzik85 wrote:

k85"]PS. czy kwestia bugów itp itd, w przypadku BETa i Linaro jest podobna?

Dla kompilatora są te same źródła, ale dla innych rzeczy już niekoniecznie. Jak już mówiłem - używać na własną odpowiedzialność (;

4\/3!!

To dlaczego bare metal nadal w wersji 4.7?

Nie wiem gdzie patrzysz, ale najnowsze wydanie "linaro" jest definitywnie 4.8. W pliku info.txt z bleeding-edge-toolchain nawet jest link do wersji na której bazuję.

https://launchpad.net/gcc-arm-embedded/4.8/4.8-2013-q4-major

Jeśli mówimy o linkach ze strony linaro.org, to one mają spore opóźnienie wzgledem wersji z launchpada.

4\/3!!

By ci więcej nie truć ostatnie pytanie bo jesteś zorientowany.
Widzę ze wersja 4.7 ma być jeszcze długo rozwijana, jest jakiś konkretny powód, zamiast po prostu przerzucić się na wersje 4.8?

Zamiast "rozwijana" bardziej skłaniałbym się do słowa "utrzymywana". Taka praktyka po prostu - zauważ, że tak samo jest z samym GCC - aktualną wersją jest 4.8, ale 4.7 jest nadal utrzymywane. To jest po prostu profesjonalny software, wbrew temu co się niektórym wydaje (;

4\/3!!

Freddie Chopin wrote:

32-bitowy Eclipse wymaga zapewne 32-bitowego toolchaina. Do 64-bitowego potrzebny jest więc zapewne 64-bitowy Eclipse i 64-bitowa Java. Osobiście - ze względu na takie właśnie problemy - używam wersji 32-bitowej. Różnica szybkości pomiędzy 32- a 64-bity jest praktycznie zerowa (margines błędu).

4\/3!!

Właśnie sprawdziłem, nie jest wymagana kompatybilność kompilatora z eclipsem pod tym względem.
Moje testy szybkości:
BET 32bit 3.3s
BET 64bit 3.2s (brak istotnych rozbieżności )
linaro 5.8s (czasem nawet 8s) (tu wyraźnie przestój po kompilacji a przed linkowaniem).

Wrzucam właśnie nową kompilację (; Z tą poprzednią jednak było coś nie tak w kwestii GDB (być może też binutils) - mam tu jeden projekt który jest w stanie wysypać GDB podczas sesji debuggowania, choć na innych projektach (dosyć podobnych nawet) działało OK...

Tak czy siak - nowa kompilacja działa u mnie w każdym przypadku. Zastanawiam się czy poprzednie wydanie (131226) usunąć, ale chyba raczej je zostawię.

4\/3!!

Lepiej usuń skoro coś z nią nie tak.
win32bit działa

Ja coś dziwnego zauważyłem, kompilacja tego samego projektu w Eclipse zajmuje ok 2x więcej czasu niż w konsoli Specjalne dodałem do projektu dużo plików (ARM_Dsp, FatFS, STLIB). make -j6 w konsoli ok. 2 minuty ctr+b w Eclipse 32bit ok 4 minuty, Eclipse oczywiście też kompiluje w 6 procesach. Eclipse 64bit 3,5 minuty. Coś nie tak z Eclipse mam ?

Eclipse parsuje wszystko co pojawia się w konsoli w poszukiwaniu błędów, ostrzeżeń kompilatora itd., wiec zwykle idzie to ciutkę wolniej. U mnie jednak jest to różnica może 10%, max. No chyba że Twój projekt ma z 1000 ostrzeżeń, albo w konsoli pojawia się okrutnie dużo informacji, to wtedy bym się nie dziwił (;

Zwykle też za pierwszym razem - gdy wszystko nie jest jeszcze w cache - całość działa trochę wolniej. Za drugim razem chodzi lepiej.

Swoją drogą - jeśli 6 wątkowa kompilacja zajmuje 2 minuty, to ile ty masz tych plików? Projekt z nuttx około 600 plików w 1 wątku na oryginalnych Makefile kompiluje się u mnie może ze 3 minuty (1 wątek!), za to w tup, przy 2 wątkach ze 40s...

4\/3!!

To dla testów, dodałem źródła CMSIS DSP ok 300 plików, ostrzeżeń nie ma.
Procesor ma cztery rdzenie, ale już wiekowy jest (AMD Phenom II) . Normalnie nie piszę takich programów

Jakby to kogoś ciekawiło, to wrzuciłem właśnie najnowszą kompilację.

Quote:

GNU Tools for ARM Embedded Processors / bleeding-edge-toolchain
version: 140405
build date: 05.04.2014
package date: 05.04.2014
build system: Linux 3.13.8-1-ARCH #1 SMP PREEMPT Tue Apr 1 12:19:51 CEST 2014 x86_64 GNU/Linux
host systems:
- 32-bit Windows (i686-w64-mingw32)
- 64-bit Windows (x86_64-w64-mingw32)
- 64-bit Linux (x86_64-unknown-linux-gnu)
target system: bare-metal ARM (arm-none-eabi)
compiler: GCC 4.8.2 for Windows (mingw32-w64), GCC 4.8.2 for Linux

Based on "GCC ARM Embedded 4.8-2014-q1-update" release
https://launchpad.net/gcc-arm-embedded/4.8/4.8-2014-q1-update

Components used:
- gcc, ARM/embedded-4_8-branch, r208234 (28.02.2014 22:24:02), svn://gcc.gnu.org/svn/gcc/branches/ARM/embedded-4_8-branch
- binutils & gdb, commit e128e761d22a6916fd3fdec702cbedb37b754ae6 (04.04.2014 23:00:58), git://sourceware.org/git/binutils-gdb.git
- newlib, commit e128e761d22a6916fd3fdec702cbedb37b754ae6 (04.04.2014 21:52:07), git://sourceware.org/git/newlib.git
- cloog 0.18.0, ftp://gcc.gnu.org/pub/gcc/infrastructure/cloog-0.18.0.tar.gz
- expat 2.0.1, http://space.dl.sourceforge.net/project/expat/expat/2.0.1/expat-2.0.1.tar.gz
- gmp 6.0.0a, https://ftp.gnu.org/gnu/gmp/gmp-6.0.0a.tar.bz2
- isl 0.11.1, ftp://gcc.gnu.org/pub/gcc/infrastructure/isl-0.11.1.tar.bz2
- libelf 0.8.13, http://www.mr511.de/software/libelf-0.8.13.tar.gz
- libiconv 1.14, http://ftp.gnu.org/pub/gnu/libiconv/libiconv-1.14.tar.gz
- mpc 1.0.2, ftp://ftp.gnu.org/gnu/mpc/mpc-1.0.2.tar.gz
- mpfr 3.1.2, http://www.mpfr.org/mpfr-current/mpfr-3.1.2.tar.xz
- zlib 1.2.8, http://zlib.net/zlib-1.2.8.tar.gz

Differences from original release:
- the most recent components used where possible, core components directly from HEADs of repositories
- compiled with recent toolchain, which results in much better performance on host system
- libstdc++ with disabled exceptions (as in size-optimized libraries that come in "nano" set)
- newlib with different configure options (--enable-newlib-register-fini removed, --enable-newlib-io-c99-formats,
--disable-newlib-atexit-dynamic-alloc, --enable-newlib-reent-small, --disable-newlib-fvwrite-in-streamio,
--disable-newlib-fseek-optimization, --disable-newlib-wide-orient, --disable-newlib-unbuf-stream-opt,
--enable-newlib-global-atexit)
- all libraries are not stripped - debugging them is possible
- lack of some text files and documents
- merged compilation steps of binutils and gdb

Build commands used:
./build-prerequisites.sh
./build-toolchain.sh

This package and info about it can be found on Freddie Chopin's website:
http://www.freddiechopin.info/

https://sourceforge.net/projects/bleeding-edge/files/140405/

4\/3!!

Dzięki Freddie za dobrą robotę

Zapuściłem sobie Twoją wersję linuksową i z 42kB (dla starej wersji 4.6) rozmiar kodu spadł do 37kB - przy tych samych ustawieniach kompilacji
Jak widać jest postęp