Nem kell, ilyenkor használd a
KEEP(crt0.o(.text))formát
Ezt hol? A sajat linker scriptben is feluldefinialhatom hogy a crt0.o legyen egy masik szegmensben? De akkor pont nem a "keep" mint szakkifejezes lenne logikus :)
(az nem derül ki a kimenetből, hogy vannak-e más függvények is benne, de ha megfelel a szabványnak, akkor nem kéne, hogy a crt0.o-ban bármi más legyen).
Nem, halistennek nincs benne mas. Ez oke.
Ja, és legyél biztos, hogy megfelelőek a linker kapcsolóid, mert statikus címre linkelés esetén nem szabadna, hogy a végeredményben "rela" rekordjaid legyenek.
Ezzel nincs gond, a vegeredmenyben (main.elf) nincsenek mar .rela.* szegmensek. Amit fentebb bemasoltam az a crt0.o-k felepitese.
(Megjegyzés, Darwin alatt egy tök másik szabvány terjedt el, de ez is előjöhet libc-k esetén: ott a global constructor-ok és global destructor-ok címei két tömbbe kerülnek, és a crt0.o-ban van kötelezően két ciklus, ami végigiterál ezeken, az első a main hívása előtt, a második utánna.)
Ez viszont itt is igy van: itt is vegigszalad a _start a __libc_init_array-n a main() elott es a __libc_fini_array-n a main() utan. Ez newlib-ben is, meg picolibc-ben is van mar. Szoval C-ben is tudok csinalni global konstruktorokat, azzal nincs gond (pl feluldefinialni az stdout-ot majd igy probalom meg, hogy pl a printf() egy eloredefinialt UART-ra irjon, ha ugy hozza a sors).
Ez nem így van. Erősen chipgyártó függő, nincs olyan, hogy ARM szabvány. RPi alatt például a _start-nak kell a text legelején lennie, és a vektortábla kezdőcíme egyébként meg a VBAR rendszerregiszterben található, és bárhol lehet.
Igen, jogos, akkor azt mondom hogy Cortex-M architekturakon :) Cortex-A az valoban lehet teljesen mas, de azt nem ismerem bare metal szinten. Cortex-M-nel alapesetben a 0-s cimen mindig a vektortabla van, es akkor azt implementaciofuggoen vagy atmappeled mashova (Cortex-M0), vagy VTOR-ral atirod ha szukseges es/vagy letezik egyatalan a VTOR.