13.05.2020 21:33
[#1]
GCC 6.5.0 cross-kompilator
Chciałem sobie zrobić dobrze i skonfigurowałem najświeższe gcc (z: github.com/bebbo/amiga-gcc) jakie znalazłem, aby w np. netbeansie sobie dziubać.
No i fajnie, helloworld działa, nawet jakieś starsze źródła znalazłem i jest niby ok.
Problem się zaczął, jak nie spodobało mi się, że goły helloworld ma kilkanaście KB, to zacząłem kompilować z -nostdlib i tu nagle programy zaczęły zawieszać system.
Przyjrzałem się co spłodził linker (pewnie do spółki z kompilatorem) i widzę, że hunk code rozpoczyna się np. od stałej tekstowej! Np. dla:
char* txt="hello world"
int main(int argc, char** argv) {
return(0);
}
po skompilowaniu:
m68k-amigaos-gcc -nostdlib test.c -o test
program wiesza system, a jak np. załaduję w AsmOne jako Object, to początek kodu przypada na "hello"
To samo widać jak się załaduje plik jako binarkę i odnajde hunk typu CODE. Tym samym ta wersja gcc okazała się trefna.
Ale może coś z tym da się zrobić? Czy pozostaje zmienić wersję gcc/cross-kompilatora? Jeśli zmienić - jaka najnowsza jest pewna (namiar na download mile widziany)?
No i fajnie, helloworld działa, nawet jakieś starsze źródła znalazłem i jest niby ok.
Problem się zaczął, jak nie spodobało mi się, że goły helloworld ma kilkanaście KB, to zacząłem kompilować z -nostdlib i tu nagle programy zaczęły zawieszać system.
Przyjrzałem się co spłodził linker (pewnie do spółki z kompilatorem) i widzę, że hunk code rozpoczyna się np. od stałej tekstowej! Np. dla:
char* txt="hello world"
int main(int argc, char** argv) {
return(0);
}
po skompilowaniu:
m68k-amigaos-gcc -nostdlib test.c -o test
program wiesza system, a jak np. załaduję w AsmOne jako Object, to początek kodu przypada na "hello"
To samo widać jak się załaduje plik jako binarkę i odnajde hunk typu CODE. Tym samym ta wersja gcc okazała się trefna.
Ale może coś z tym da się zrobić? Czy pozostaje zmienić wersję gcc/cross-kompilatora? Jeśli zmienić - jaka najnowsza jest pewna (namiar na download mile widziany)?
13.05.2020 21:43
[#2]
Re: GCC 6.5.0 cross-kompilator
@BigBang, post #1
po pierwsze - brak średnika za "hello world". ;)
po drugie - niekoniecznie musisz od razu używać nostdlib. Spróbuj z -mcrt=nix20 albo -mcrt=nix13 (jak potrzebujesz to uruchomić pod ks1.3). Domyślnie bebbokompilator linkuje z newlib, który jest dość spory. Jak Ci będzie mało to spróbuj dodać -Os by optymalizować pod rozmiar. Możesz też dodać -msmall-code -mregparm=2 -fbaserel -ffast-math -s aby uszczknąć jeszcze trochę.
Jak faktycznie potrzebujesz pozbyć się biblioteki standardowej bo piszesz z użyciem tylko systemowych / własnych funkcji, to sprawie trzeba się przyjrzeć bliżej. Zgłoś to autorowi na githubie, dość regularnie odpowiada na issues i żwawo poprawia bugi.
EDYT: Teraz patrzę na dokumentację GCC i dochodzę do wniosku że to może jednak nie być bug. Wygląda to że ta flaga wywalała cały kod startowy. W tym przypadku kompilator bierze pierwszy symbol z kodu jako punkt wejścia.
Ostatnia aktualizacja: 13.05.2020 21:48:15 przez teh_KaiN
po drugie - niekoniecznie musisz od razu używać nostdlib. Spróbuj z -mcrt=nix20 albo -mcrt=nix13 (jak potrzebujesz to uruchomić pod ks1.3). Domyślnie bebbokompilator linkuje z newlib, który jest dość spory. Jak Ci będzie mało to spróbuj dodać -Os by optymalizować pod rozmiar. Możesz też dodać -msmall-code -mregparm=2 -fbaserel -ffast-math -s aby uszczknąć jeszcze trochę.
Jak faktycznie potrzebujesz pozbyć się biblioteki standardowej bo piszesz z użyciem tylko systemowych / własnych funkcji, to sprawie trzeba się przyjrzeć bliżej. Zgłoś to autorowi na githubie, dość regularnie odpowiada na issues i żwawo poprawia bugi.
EDYT: Teraz patrzę na dokumentację GCC i dochodzę do wniosku że to może jednak nie być bug. Wygląda to że ta flaga wywalała cały kod startowy. W tym przypadku kompilator bierze pierwszy symbol z kodu jako punkt wejścia.
Ostatnia aktualizacja: 13.05.2020 21:48:15 przez teh_KaiN
13.05.2020 22:04
[#3]
Re: GCC 6.5.0 cross-kompilator
@teh_KaiN, post #2
EDYT: Teraz patrzę na dokumentację GCC i dochodzę do wniosku że to może jednak nie być bug. Wygląda to że ta flaga wywalała cały kod startowy. W tym przypadku kompilator bierze pierwszy symbol z kodu jako punkt wejścia.
Tak, z opisu kolegi wynika, że nie został załączony kod startowy. Fizycznie program zaczyna się nie od kodu startowego, tylko pierwszych zadeklarowanych symboli.
Trzeba dostarczyć swój własny kod startowy i najpewniej podać jego adres dla parametru -e (entry).
Ja sam nie używałem własnego kodu startowego. Kolega Krashan myślę, że coś wie na ten temat z praktyki.
13.05.2020 22:14
[#4]
Re: GCC 6.5.0 cross-kompilator
@teh_KaiN, post #2
Przykładu nie kopiowałem z edytora, tylko walnąłem z palca, poglądowo, ale fakt - przeoczenie.
Znalazłem jeszcze opcję: --entry, która powinna działać tak, że wskazuje adres startowy, np. na funkcję main:
--entry main
Na ale bez jaj, to jest C, funkcja main jest specjalna i najprostszy nawet kompilator powinien ją zauważać i start kodu ustawiać odpowiednio, chyba że jawnie chciałbym inaczej - niestandardowo.
Jednak skompilowałem to samo w gcc (też z nostdlib - 14 KB kodu wyszło - masakra jakaś) jaki akurat mam w debianie (czyli 9.3) i po uruchomieniu dostaje segmentation fault - co daje do myślenia. Czas dokładnie zapoznać się z dokumentacją... W sumie to mogę olać tego nostdliba, byle działało, w tunowanie można się później bawić.
Dodam że z vbcc działa.
Znalazłem jeszcze opcję: --entry, która powinna działać tak, że wskazuje adres startowy, np. na funkcję main:
--entry main
Na ale bez jaj, to jest C, funkcja main jest specjalna i najprostszy nawet kompilator powinien ją zauważać i start kodu ustawiać odpowiednio, chyba że jawnie chciałbym inaczej - niestandardowo.
Jednak skompilowałem to samo w gcc (też z nostdlib - 14 KB kodu wyszło - masakra jakaś) jaki akurat mam w debianie (czyli 9.3) i po uruchomieniu dostaje segmentation fault - co daje do myślenia. Czas dokładnie zapoznać się z dokumentacją... W sumie to mogę olać tego nostdliba, byle działało, w tunowanie można się później bawić.
Dodam że z vbcc działa.
13.05.2020 22:14
[#5]
Re: GCC 6.5.0 cross-kompilator
@Hexmage960, post #3
Trzeba dostarczyć swój własny kod startowy i najpewniej podać jego adres dla parametru -e (entry).
Nie trzeba. Kompilator od bebbo ignoruje -e bo amigowy format HUNK czegoś takiego nie przewiduje. Kod jest wykonywany od pierwszego słowa pierwszego załadowanego HUNK-a.
Ja sam nie używałem własnego kodu startowego. Kolega Krashan myślę, że coś wie na ten temat z praktyki.
Oto przykładowy minimalistyczny kod startowy: link
Ostatnia aktualizacja: 13.05.2020 22:15:19 przez mschulz
13.05.2020 22:17
[#6]
Re: GCC 6.5.0 cross-kompilator
@BigBang, post #4
Na ale bez jaj, to jest C, funkcja main jest specjalna i najprostszy nawet kompilator powinien ją zauważać i start kodu ustawiać odpowiednio
Start programu nigdy nie zaczyna sie od main(). Do tej funkcji skok następuje właśnie z kodu startowego a nie z systemu. Poza tym, format HUNK nie przewiduje czegoś takiego jak entry point w pliku wykonywalnym. Biblioteka dos.library laduje segmenty do pamięci a potem skacze do pierwszego załadowanego segmentu, czymkolwiek by nie byl.
13.05.2020 22:19
[#7]
Re: GCC 6.5.0 cross-kompilator
@mschulz, post #5
Nie trzeba. Kompilator od bebbo ignoruje -e bo amigowy format HUNK czegoś takiego nie przewiduje. Kod jest wykonywany od pierwszego słowa pierwszego załadowanego HUNK-a.
Rozumiem. Myślałem, że kompilator powinien wiedzieć od jakiego symbolu rozpocząć program (tutaj _startup).
Czy chodzi o to, że powinno to być na początku programu i w pierwszym obiekcie podawanym linkerowi?
@BigBang
Twój program nie ma kodu startowego, który wywołuje funkcję main. To sprawia ta opcja -nostdlib.
Kod startowy inicjuje bazę biblioteki exec, ładuje parametry programu i opcjonalnie pobiera wiadomość od Workbencha. I dopiero wywołuje main.
Ostatnia aktualizacja: 13.05.2020 22:24:22 przez Hexmage960
13.05.2020 22:26
[#9]
Re: GCC 6.5.0 cross-kompilator
@Hexmage960, post #7
Ok, rozumiem, dziękuje za wyjaśnienie.
Czyli jakbym nie zrobił żadnej zmiennej globalnej, to program by się uruchomił, bo na początku hunka byłaby prawidłowa instrukcja. W sumie w AmigaOS nie zawsze potrzebuję kodu startowego, tym bardziej uniwersalnego. Pokombinuję z tym jeszcze, bo mnie to zaciekawiło. A vbcc najwyraźniej inaczej interpretuje opcje kompilacji/linkowania.
A co do hunków - to przecież jest hunkt typu code, i system startuje od pierwszego w załadowanym pliku. Kompilator powinien być na tyle "mądry", żeby tam umieścić kod, a nie np. zmienną.
Bo jak sobie rozebrałem ten prościutki, 120 bajtowy obiekt wynikowy, to nie rozumiem po cholerę wygenerował kilka hunków, w tym jeden code a reszta dla danych/metadanych, tylko że akurat tych zmiennych globalnych przed main() nie wywalił z hunka code.
Ostatnia aktualizacja: 13.05.2020 22:31:37 przez BigBang
Czyli jakbym nie zrobił żadnej zmiennej globalnej, to program by się uruchomił, bo na początku hunka byłaby prawidłowa instrukcja. W sumie w AmigaOS nie zawsze potrzebuję kodu startowego, tym bardziej uniwersalnego. Pokombinuję z tym jeszcze, bo mnie to zaciekawiło. A vbcc najwyraźniej inaczej interpretuje opcje kompilacji/linkowania.
A co do hunków - to przecież jest hunkt typu code, i system startuje od pierwszego w załadowanym pliku. Kompilator powinien być na tyle "mądry", żeby tam umieścić kod, a nie np. zmienną.
Bo jak sobie rozebrałem ten prościutki, 120 bajtowy obiekt wynikowy, to nie rozumiem po cholerę wygenerował kilka hunków, w tym jeden code a reszta dla danych/metadanych, tylko że akurat tych zmiennych globalnych przed main() nie wywalił z hunka code.
Ostatnia aktualizacja: 13.05.2020 22:31:37 przez BigBang
13.05.2020 22:29
[#10]
Re: GCC 6.5.0 cross-kompilator
@BigBang, post #9
Czyli jakbym nie zrobił żadnej zmiennej globalnej, to program by się uruchomił, bo na początku hunka byłaby prawidłowa instrukcja.
Dokładnie tak. Obejrzyj ten programik do którego linka podrzucilem. Kompiluje sie poprawie z -nostdlib i z -nostartfiles. Plik wykonywalny ma niewiele ponad 700 bajtów i działa, nawet sie uruchamia z workbencha. Tam tez masz minimalny kod startowy potrzebny do tego, żeby program dało sie uruchomić z ikony.
14.05.2020 18:08
[#12]
Re: GCC 6.5.0 cross-kompilator
@mschulz, post #10
No dobra, sprawdziłem ten Twój kod i tak naprawdę to wnosi on tylko taki "myk", że funkcja _start() z której wołasz main() jest po prostu na początku źródeł, zaraz za deklaracją main(). Zmienne globalne są za nią.
Naprawdę jestem teraz zniesmaczony gcc... żeby takiej prostej sprawy nie potrafił ogarnąć? Jest jeszcze szansa że któryś z zyliona przełączników może to poprawić.
VBCC z -nostdlib nie ma żadnego problemu, zmienną daje za kod i tyle.
Jak widać - da się to obejść, ale niby nowoczesne narzędzie powinno pozwalać na unikanie konieczności obchodzenia takich pierdół...
Naprawdę jestem teraz zniesmaczony gcc... żeby takiej prostej sprawy nie potrafił ogarnąć? Jest jeszcze szansa że któryś z zyliona przełączników może to poprawić.
VBCC z -nostdlib nie ma żadnego problemu, zmienną daje za kod i tyle.
Jak widać - da się to obejść, ale niby nowoczesne narzędzie powinno pozwalać na unikanie konieczności obchodzenia takich pierdół...
14.05.2020 22:34
[#13]
Re: GCC 6.5.0 cross-kompilator
@BigBang, post #12
To w końcu jest "na początku źródeł", czy "zaraz za deklaracją main()"? Bo to jest dość istotna różnica tutaj. ;)
Być może dałoby radę to trochę schludniej zrobić korzystając z GCC z którego korzystają AROSowcy - niehunkowego, generującego pliki .elf. Wtedy może jakąś linkerscriptową magią mógłbyś narzucić kolejność symboli w .elf i potem elf2hunk by Ci to jakoś schludnie łykał. Tylko czy to jest w ogóle warte tego? Co Ci te parę bajtów robi? Piszesz coś na rozmiar bootblocka?
Możesz jeszcze ewentualnie spróbować zrobić sobie kod startowy w vasm, z użyciem gcc napisz pozostały kod i potem to wszystko ze sobą zlinkuj.
Jeśli dobrze rozumiem, że vbcc łyka Ci zmienne, które deklarujesz później niż używasz, to jest kompletnie sprzeczne ze standardem języka C. Zawsze najpierw musi nastąpić deklaracja czegokolwiek, zanim tego użyjesz, tak by kompilator był w stanie skompilować całość w jednym przebiegu.
Być może dałoby radę to trochę schludniej zrobić korzystając z GCC z którego korzystają AROSowcy - niehunkowego, generującego pliki .elf. Wtedy może jakąś linkerscriptową magią mógłbyś narzucić kolejność symboli w .elf i potem elf2hunk by Ci to jakoś schludnie łykał. Tylko czy to jest w ogóle warte tego? Co Ci te parę bajtów robi? Piszesz coś na rozmiar bootblocka?
Możesz jeszcze ewentualnie spróbować zrobić sobie kod startowy w vasm, z użyciem gcc napisz pozostały kod i potem to wszystko ze sobą zlinkuj.
Jeśli dobrze rozumiem, że vbcc łyka Ci zmienne, które deklarujesz później niż używasz, to jest kompletnie sprzeczne ze standardem języka C. Zawsze najpierw musi nastąpić deklaracja czegokolwiek, zanim tego użyjesz, tak by kompilator był w stanie skompilować całość w jednym przebiegu.
15.05.2020 09:07
[#14]
Re: GCC 6.5.0 cross-kompilator
@BigBang, post #12
No dobra, sprawdziłem ten Twój kod i tak naprawdę to wnosi on tylko taki "myk", że funkcja _start() z której wołasz main() jest po prostu na początku źródeł, zaraz za deklaracją main(). Zmienne globalne są za nią.
No tak. Skoro buduje program bez kodu startowego i sam taki kod dopisuje to musze sie trzymac regul "narzuconych" odgornie przez gcc.
Naprawdę jestem teraz zniesmaczony gcc... żeby takiej prostej sprawy nie potrafił ogarnąć? Jest jeszcze szansa że któryś z zyliona przełączników może to poprawić.
To nie jest problem gcc tylko formatu plikow .o wybranego przez bebbo w amigowej wersji kompilatora. A gcc, jak kazdy inny kompilator, i tak nie daje ci gwarancji ze kolejnosc obiektow w kompilacie jest dokladnie taka sama jak ich kolejnosc w kodzie zrodlowym, bo tego zaden standard C ani C++ nie narzuca. Co wiecej, gcc moze kolejnosc przemieszac jezeli bedzie prowadzila do bardziej optymalnego wyniku. Na etapie konsolidacji moga nastapic dalsze zmiany, lacznie z usuwaniem nieuzywanych fragmentow kodu.
Poza tym, nie widze potrzeby poprawiania czegokolwiek w gcc. Zawsze mozesz swoj wlasny kod startowy kompilowac w osobnym pliku i w odpowiedniej kolejnosci linkowac. Gdyby bebbo zdecydowal sie na format ELF zamiast HUNK moglbys fragmenty kodu umieszczac w osobnych sekcjach i ustalic ich kolejnosc na etapie konsolidaci za pomoca skryptu linkera. No, ale bebbo wybral HUNK wiec ciesz sie tym co masz ;)
Ale jezeli bardzo chcesz to zglos blad u bebbo, ale moge ci od razu powiedziec ze twojego buga zamknie w ekspresowym tempie i nie bedzie tego poprawial.
Ostatnia aktualizacja: 15.05.2020 09:11:20 przez mschulz
15.05.2020 10:38
[#15]
Re: GCC 6.5.0 cross-kompilator
@teh_KaiN, post #13
Zaraz... nie mieszajmy różnych systemów walutowych. Kod w C to jedno, a format pliku wynikowego to drugie.
Tu nie chodzi o to, że "po co mi te parę bajtów" tylko o to, że nie mam pełnej kontroli nad kodem wynikowym. Młotkiem z krzywym, nieergonomicznym trzonkiem i luźnym obuchem też można wbijać gwoździe, ale po co się męczyć.
Jeśli narzędzie nie ogarnia tak prostej sprawy, to mogę mieć wątpliwości czy ogarnia sprawy bardziej skomplikowane?
Skompilowałem test z tymi samymi opcjami na linuksie i też sie wywala (segfault), czyli gcc tak ma. Ale na linuksie się mniej znam, tu piszę wyłącznie w kontekscie Amigi.
Mam gdzieś jeszcze to stare gcc 2.95, jak znajdę to sprawdzę.
A VBCC tworzy kod tak, że hunk code zawsze rozpoczyna się od kodu. Zmienne globalne sobie wpasowuje tam, gdzie mu pasuje, bo przecież nie ma żadnego znaczenia, czy zmienna globalna jest w pamięci przed czy po kodzie. Jeszcze raz przykład, bo widzę że już snują się domysły z naruszaniem standardów itp.
char* txt="blabla";
int main(void)
{
return(0);
}
Nic prostszego nie da się chyba wymyśleć; żadne liby standardowe nie są tu potrzebne, a gcc nie potrafi tego skompilować (z opcją -nostdlib), tak aby się po prostu program uruchomił. A VBCC problemu z tym mnie ma i jeszcze mu mniejszy kod wychodzi. (ale jak pisałem, nie chodzi mi o te kilka bajtów).
Tu nie chodzi o to, że "po co mi te parę bajtów" tylko o to, że nie mam pełnej kontroli nad kodem wynikowym. Młotkiem z krzywym, nieergonomicznym trzonkiem i luźnym obuchem też można wbijać gwoździe, ale po co się męczyć.
Jeśli narzędzie nie ogarnia tak prostej sprawy, to mogę mieć wątpliwości czy ogarnia sprawy bardziej skomplikowane?
Skompilowałem test z tymi samymi opcjami na linuksie i też sie wywala (segfault), czyli gcc tak ma. Ale na linuksie się mniej znam, tu piszę wyłącznie w kontekscie Amigi.
Mam gdzieś jeszcze to stare gcc 2.95, jak znajdę to sprawdzę.
A VBCC tworzy kod tak, że hunk code zawsze rozpoczyna się od kodu. Zmienne globalne sobie wpasowuje tam, gdzie mu pasuje, bo przecież nie ma żadnego znaczenia, czy zmienna globalna jest w pamięci przed czy po kodzie. Jeszcze raz przykład, bo widzę że już snują się domysły z naruszaniem standardów itp.
char* txt="blabla";
int main(void)
{
return(0);
}
Nic prostszego nie da się chyba wymyśleć; żadne liby standardowe nie są tu potrzebne, a gcc nie potrafi tego skompilować (z opcją -nostdlib), tak aby się po prostu program uruchomił. A VBCC problemu z tym mnie ma i jeszcze mu mniejszy kod wychodzi. (ale jak pisałem, nie chodzi mi o te kilka bajtów).
15.05.2020 10:55
[#16]
Re: GCC 6.5.0 cross-kompilator
@mschulz, post #14
No tak. Skoro buduje program bez kodu startowego i sam taki kod dopisuje to musze sie trzymac regul "narzuconych" odgornie przez gcc.
OK, czyli można się zdecydować na gcc i ale jak się chce tak pokombinować, to mamy program niekompilowalny innymi kompilatorami.
To nie jest problem gcc tylko formatu plikow .o wybranego przez bebbo w amigowej wersji kompilatora. A gcc, jak kazdy inny kompilator, i tak nie daje ci gwarancji ze kolejnosc obiektow w kompilacie jest dokladnie taka sama jak ich kolejnosc w kodzie zrodlowym, bo tego zaden standard C ani C++ nie narzuca. Co wiecej, gcc może kolejnosc przemieszac jezeli bedzie prowadzila do bardziej optymalnego wyniku.
Tak, zgadza się. Mnie oburzyło jedynie to, że gcc jest tak durne, że ustawia entry point na niewykonywalny kod. W AmigaOS oznacza to że do hunka code wkopiowuje na samym początku zmienną globalną tylko dlatego że była zdefiniowana przed main() (bo jak ma być...?). Na linuksie ten test też się wywala.
A jakby bebbo nie wybrał formatu wyjściowego hunk tylko elf, to nie byłby to crosskompilator dla AmigaOS m68k, więc i tak by się nie przydał w tej sytuacji. Ale dobrze że jest, lepiej mieć większy wybór niż mniejszy.
Cóż, po prostu będę kompilował kod w cros-gcc w full opcji, a z tyłu głowy będzie cały czas.
Dzięki panowie - dyskusja była dla mnie owocna, dowiedziałem się paru rzeczy i sposobów jak sobie z tym radzić. To że mi się to nie do końca podoba, to już mój problem.
15.05.2020 11:36
[#17]
Re: GCC 6.5.0 cross-kompilator
@BigBang, post #16
OK, czyli można się zdecydować na gcc i ale jak się chce tak pokombinować, to mamy program niekompilowalny innymi kompilatorami.
Niekoniecznie. Wystarczy kod startowy (workbench message, skok do main) trzymac w osobnym pliku i linkerowi podac jako pierwszy.
A jakby bebbo nie wybrał formatu wyjściowego hunk tylko elf, to nie byłby to crosskompilator dla AmigaOS m68k, więc i tak by się nie przydał w tej sytuacji.
Mial wybor. Mogl wybrac format ELF dla obiektow (.o) i linkowac je do formatu HUNK. Wtedy mialbys pelen luksus lacznie z dzialajacymi skryptami linkera. No, ale Bebbo chcial byc jak najbardziej zgodny z innymi amigowymi kompilatorami :)