Elektroda.pl
Elektroda.pl
X

Search our partners

Find the latest content on electronic components. Datasheets.com
Elektroda.pl
Please add exception to AdBlock for elektroda.pl.
If you watch the ads, you support portal and users.

bleeding-edge-toolchain - kolejny toolchain dla ARM

Freddie Chopin 26 Dec 2013 16:58 37728 222
Texa Poland
  • #31
    Freddie Chopin
    MCUs specialist
    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!!
  • Texa Poland
  • #32
    tadzik85
    Level 38  
    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/....."
  • #33
    alagner
    Level 26  
    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ę ;)
  • #34
    tadzik85
    Level 38  
    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.

    Code: bash
    Log in, to see the code
  • #35
    Freddie Chopin
    MCUs specialist
    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!!
  • #36
    tadzik85
    Level 38  
    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
  • #38
    tadzik85
    Level 38  
    Będę wdzięczny za wersje x64
  • Texa Poland
  • #39
    Freddie Chopin
    MCUs specialist
    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!!
  • #40
    tadzik85
    Level 38  
    w trakcie sprawdzania....

    Działa, debugowanie względnie też
  • #41
    Freddie Chopin
    MCUs specialist
    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!!
  • #42
    tadzik85
    Level 38  
    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
  • #44
    tadzik85
    Level 38  
    A co to za biblioteka w ogole?
  • #45
    Freddie Chopin
    MCUs specialist
    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!!
  • #46
    Freddie Chopin
    MCUs specialist
    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!!
  • #47
    tadzik85
    Level 38  
    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ł?
  • #48
    Freddie Chopin
    MCUs specialist
    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!!
  • #49
    tadzik85
    Level 38  
    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?
  • #50
    Freddie Chopin
    MCUs specialist
    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!!
  • #51
    tadzik85
    Level 38  
    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?
  • #52
    Freddie Chopin
    MCUs specialist
    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!!
  • #53
    tadzik85
    Level 38  
    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).
  • #54
    Freddie Chopin
    MCUs specialist
    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!!
  • #55
    tadzik85
    Level 38  
    Lepiej usuń skoro coś z nią nie tak.
    win32bit działa
  • #56
    imarszi
    Level 14  
    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 ?
  • #57
    Freddie Chopin
    MCUs specialist
    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!!
  • #58
    imarszi
    Level 14  
    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 :)
  • #59
    Freddie Chopin
    MCUs specialist
    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!!
  • #60
    Jado_one
    Level 22  
    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 :-)