GCC/binutils bug reporting

C/C++

Sziasztok!

Van-e valakinek tapasztalata a targybeli folyamattal? Ugy nez ki sikerult kifognom az elso ilyen esetet. A hiba a linkerben (ld) van, amit ugye nem a GCC, hanem binutils, de nyilvan `gcc`-bol kiihivva ugyanugy elojon a dolog. Kicsit niche a dolog, nagyon szerencsetlen osszeallitasban jon elo a bug (csak msp430-elf targeten, ott is sokmindennek kell egyuttallnia). A "mar nem lehet weben regisztralni, irj emailt ide meg ide, 24 oran belul kapsz accountot a bugzillahoz" reszen mar tulvagyok. Konkretan 48 oraja semmi sem jott, de tegyuk fel hogy jon majd (lasd meg: szep nap). Hogy erdemes rakeszulni egy ilyenre? Minimum reproducible example megvan, szepen mutatja a dolgot (nehany soros shell szkript ami leforditja + linkeli kulonbozo parameterekkel plusz 2x10 soros C kod ami elohozza a hibat). Mi kellhet meg?

koszi, A.

  • 632 megtekintés

( hrgy84 | 2025. 10. 06., h – 18:55 )

Ennyi elégnek kell hogy legyen, ha nem elég, majd kérdeznek.

Írj nekik még egy levelet (replyként az előző account kérős leveledre) hogy wazzup. 

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

( NevemTeve | 2025. 10. 07., k – 09:04 )

Bónusz, ha magad megtalálod a hibát a source-ben. (Mondjuk az munkás dolog, de ha AI-t is bevetsz, akkor könnyen és gyorsan kapsz hibás eredményt.)

( persicsb | 2025. 10. 07., k – 10:04 )

Nem kell túlgondolni. A GNU fejlesztők is emberek, ha valami nem klappol, vagy nem értik, majd visszakérdeznek.

Micsoda mintaszerű hibabejelentés, le a kalappal! Így kéne mindenkinek hibát bejelenteni. Ettől függetlenül, a bugoddal kapcsolatban: biztos vagy benne, hogy rossz a végeredmény? Nem vagyok jártas az MSP430 architektúrában, de az ELF-nél előfordulhat, hogy az offszet már magában az utasításban van, ilyenkor teljesen normális, ha a RELA addendje 0. Legalábbis i386-on egész biztos futottam ilyenbe bele, anyáztam is, hogy egyszer az utasításban 0 van, az addendben meg az offszet, máskor meg az utasításban az offszet és az addendben 0. Ha jól emlékszem, akkor ott attól függött, hogy a GOT-ba miként került bele (ha publikus volt, akkor nem volt addend, mert a run-time linker dolga volt olyankor a relokálás, egyébként ha statikus, akkor meg volt addend, ha jól emlékszem. Mindesetre csak shared PIC esetén jött elő, ha volt PLT rekord is hozzá, egyébként az egész kérdéskör elő sem jött, erre biztosan emlékszem.) Nekem egyébként nincs jó tapasztalatom a GNU fejlesztőkkel, egyszer egy olyan bugot jelentettem be, hogy inline esetén kioptimalizált valamit akkor is, ha volatile-nak volt megadva a változója. Sokáig ment a levelezés azon, hogy melyik kategóriába kéne rakni a bugot, míg végül nem lett az egészből semmi, inkább kézzel átmásoltam a kódot oda, ahová inline-olnia kellett volna a fordítónak (egyébként ez volt az, ssfn_utf8 hívás esetén nem léptette a pointert). Ezzel szemben a Clang fejlesztőivel iszonyat jó tapasztalatom volt. Ott én is hasonló linker bugba futottam bele (ha jól rémlik, mindenképp szétszedte az adat és a kód relokációt külön szekciókba, és az istennek se akarta egybre rakni, pedig Solaris alatt olyan ELF kell, emiben egyben van a kétfajta relokáció. Valami ilyesmi volt.) Kicsit értetlenkedtek ott is, de amikor belinkeltem a Sun-os ELF doksit, azonnal javították.

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. 

Clang mellé van már natív LLVM linker is, az LLD (FreeBSD-ben már 13 óta az az alap és nem a GNU binutils) , de ha amúgy linkelés, akkor vess egy pillantást a Gold-linkerre is - állítólag bitang gyors. De hogy a te környezetedben használhatóak-e ...

tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

Sajna igen.
Kár.
A wikipedia most azt irja hogy LLVM-re meg csak kiserleti valtozat van...
Azért nézz utána, a Wikipédia ilyen téren nem épp megbízható.
de ugye megintcsak, amire nekem is felhivtak a figyelmemet: ez linkeles es nem forditas... :/
Nem biztos. Ha a hiba lényege az, hogy kellene, hogy legyen addend, de nincs, akkor az lehet még fordító hiba is.
mennyire mashogy van ottan szervezve a linkeles (binutils) feladatkor
Ugyanúgy van szervezve, ugyanúgy működik, de az LLD egy teljesen független implementáció, ezért lehet, abban nincs meg ez a bug.
Szoval siman lehet hogy a clang is a binutilst hasznalja... :/
Azért ezt furcsállnám. Max. azt tudom elképzelni, hogy van még egy-két util a binutils-ban, amit még nem írtak újra (objcopy jut most eszembe, létezik ugyan llvm-objcopy, de még nem került be a hivatalos repóba, ilyesmik).
ezert is jo lenne megjavitani magamnak
Ha a forrás bújására adod a fejed, akkor a binutils egy elég bloated monstrum repó, szerintem ebből a fájlból indulj ki. Ebben van az, ami a RELA rekordokat kiírja, ezt vesd össze mondjuk az i386-os kóddal, hogy az máshogy rakja-e bele az addendeket vagy sem. Elvileg az ezt hívó rész architektúrafüggetlen még (a gyakorlatban azonban nem mindig az sajnos, főleg az optimalizáló környékén). No mind1, a lényeg, hogy azt nézd meg, ez a bfd réteg jó szimbólum címeket kap-e, vagy már híváskor nullák és amiatt ír ki 0 addendet az elf-be. Ha előbbi, akkor linker hiba, ha utóbbi, akkor fordító (vagy optimalizáló) hiba. Remélem tudtam valamit segíteni, sajnos nincs tapasztalatom ezzel az architektúrával, hogy konkrétabb dolgot tudnék mondani.

Ha a forrás bújására adod a fejed, akkor a binutils egy elég bloated monstrum repó, szerintem ebből a fájlból indulj ki

Koszi, vsz ez lesz. Marmint hogy elkezdem bujni a forrast, ebbol kiindulva amit irtal. Egyelore eltelt 2+ het, es se a GNU reszerol, se a Texas reszerol se kep, se hang. Ami egy kritikus linker bugnal azert nem annyira jo. Dehat ez van, ld. motivacio hianya, fentebb.