Ettől függetlenül, a bugoddal kapcsolatban: biztos vagy benne, hogy rossz a végeredmény?
Sajna igen. Neztem en is amit mondtal hogy az addend nem a RELA reszben van hanem mar a targykodban... de sajna itt az MSP430-as valtozatlanl nem, konstans zero mindenutt. Szoval az oke hogy az addend lehet itt is meg ott is, meg jo is hogy tobb variacio lehetseg (pl az ARM az igy csinalja: ott csak REL entry-k vannak es a targykod tartalmazza az addendet, ezt pont a fenti jelentesben linkelt minimal reproducible example is tartalmazza), de most sajna nem ez a baj.
Egyebkent siman lehet hogy ez a hiba forrasa magaban a kodban: ketfelekeppen is csinalhatod es mindegyik resz (RELA + addend, ill REL + targykodbeli offset) azt hiszi hogy a masik feladata lesz a relokaciok helyrehozatala a .bss.* => .bss (.whatever.* => .whatever) section-ok osszelinkelese utan. Szoval valojaban ezt a reszt kene megtalalnom a 2.4MLoC-ban. Egyebkent erdekes mert a konkret relokaciokat vegzo eljarasokat/fuggvenyeket/procedurakat megtalaltam, azt relative konnyu kiszurni/kiszurni a forraskodban (a `readelf -r ...` szimbolikusan kiirja a REL/RELA type-okat, es csak azokra eleg rakeresni hogy hol is vannak).
De ugye ez az erdekes a dologban hogy az egesz section + relocation merging, foleg ha a RELA + addend modon kodolod mint itt (ami absz nem erinti a targykodot), szoval ez egy full architektura fuggetlen hiba mert csak section/relocation juggling az egesz. Ezert is neztem meg kvazi-rogton hogy mas architekturaknal elojon-e. Es hat nem jott elo.
Sajna igen, az MSP430 elegge niche architektura. Noha elvileg mar full hivatalos a tamogatas (talan 11-es ota), es most mar a "GCC target processor families" kozott sorolja fel, a mainstream architekturakkal egykupacban. De eleg sokaig csak a "Lesser-known target processors" alatt volt.
Nekem egyébként nincs jó tapasztalatom a GNU fejlesztőkkel, egyszer egy olyan bugot jelentettem be, [...]
Hat, meglatjuk :) De igen, ezert is jo lenne megjavitani magamnak mert akkor vsz hamarabb meglenne az upstream javitas (es joesetben Texas-ek/Mitto-ek is javitjak es lesz a 9.3.1.11 utan egy 9.3.1.12 is). Meg tanulok valamit...
Ezzel szemben a Clang fejlesztőivel iszonyat jó tapasztalatom volt.
A wikipedia most azt irja hogy LLVM-re meg csak kiserleti valtozat van... de ugye megintcsak, amire nekem is felhivtak a figyelmemet: ez linkeles es nem forditas... :/ Szoval kerdes hogy mennyire vagyunk beljebb es hogy mennyire mashogy van ottan szervezve a linkeles (binutils) feladatkor. Lehet hogy csak compiler van ottan, linker meg nincs is. Most igy nagyon gyorsan raneztem, Debian alatt olyan a clang fuggosege hogy clang => clang-19 => binutils. Szoval siman lehet hogy a clang is a binutilst hasznalja... :/
Kozben egyebkent annyi fejlemeny van hogy direkt assembly kodbol is konnyen elohozhato, a minimal reproducible example igy nez ki:
.section .rodata.var1
.global var1
var1:
.short 42
.section .rodata.var2
# .global var2
var2:
.short 137
.section .text
.global funct
funct:
mov var1, r12
add var2, r12
ret
Ha a .global ki van kommentezve akkor rossz lesz a vegeredmeny (a parcialisan linkelt ELF az egy 4 byteos .rodata-t tartalmaz, mind a var1, mind a var2 ugyanugy .rodata + 0-ra cimezve), ha van .global akkor meg teljesen okes. Pont ugy mint C-ben a van static, nincs static.