C fordító hiba?

[attuska]

attila@derp-x8664:~$ trigger-rally Érvénytelen utasítás (core készült) attila@derp-x8664:~$ A gdb -ben futtatva a bt simán a /usr/lib/libc.so.6 -t hibáztatja. Ebben mutatkozott a hibás kód.

A saját gépemen fordított példány simán megy, mivel az én gépemben más a CPU, mint azon, amelyen a letölthető kód készült!

Van egy ilyen sor a trigger-rally/src/GNUMakefile fájlban:

OPTIMS ?= -march=native -mtune=native -Ofast

Ezek szerint a -Ofast optimatizációval a generált kód nem minden CPU által értelmezhető!

[rezso]

Szerintem inkább a -march=native -mtune=native okozza a gondot, mivel ez készít natív, azaz az adott CPU-ra optimalizált kódot.

[attuska]

Ezt nem lehet az AMD processzorok hibájának, vagy egyes INTEL processzorok hibájául felróni, mert ez az illegális utasítási hiba már jelentkezett más progiknál is, nem csak AMD procin, hanem INTEL procin is. Volt egy időszak, mikor az O3 optomatizációt kellett kicserélni O2-re, amit abbahagytunk egy ideje, az Ofast típust nem is néztük sohase. Most megnézem a trigger appimage csomagot is kiváncsiságból. Ha aNem néztem más progikat, de emlékeim szerint van még jó pár, melyek z jó, akkor nagy a kérdés, hogy nálunk mi más?? Nem néztem más progikat, de emlékeim szerint volt még jó pár.

[attuska]

A trigger-rally appimage sem indul ezen a masinán. Éppúgy nem biztonságos ez az appimage, mert örökölt ablakkezelő rendszert használ, mint az etlegacy is. Ez utóbbi viszont megy az Intel CPU-s masinán, most megnézem ezen is ez utóbbi progi mindegyik változatát is.

[attuska]

Az etl flathubos változata vígan megy minden rendszeremen. Az etlagacy csomagunk már elérhetetlen nagyon helyesen.

[attuska]

https://github.com/uhulinux/ub-ubk4/issues/89#issuecomment-1336483472 Akkor talán arra kellene rákerestetni a csomagokban és likvidálni bennük az ilyet. Az ilyen hiba akkor kiküszöböltethető, ennek kipróbálását megtehetem, de ehhez kellne nekem egy általad készített csomag amit feltelepítek, ha az megy, akkor remélhetőleg ez meggyógyult.

[attuska]

Ezt a teljes full rebuild sem hozta helyre, ami várható volt.

[rezso]

#89 (comment) Akkor talán arra kellene rákerestetni a csomagokban és likvidálni bennük az ilyet. Az ilyen hiba akkor kiküszöböltethető, ennek kipróbálását megtehetem, de ehhez kellne nekem egy általad készített csomag amit feltelepítek, ha az megy, akkor remélhetőleg ez meggyógyult.

Épeszű fejlesztő nem tesz ilyet. Amúgy pedig az OPTIMS felülbírálható, tehát egy 'ub_make OPTIMS=' elvileg helyrerakja.

[rezso]

No meg akkor jön az, ami anno a python2-nél volt, hogy nem mindegy, ki fordítja? Hagyjuk már.

[attuska]

https://github.com/uhulinux/ub-ubk4/issues/89#issuecomment-1337349803 Mi nem fejlesztők, hanem csomagolók vagyunk csupán. Akkor talán kihajítás helyett ezt az OPTIMS -t kellene felülbírálnunk a trigger-rally csomag készítésénél. Az mégsem várható el a még meglévő kevés usertől, hogy nekik is ugyanolyan CPU legyen a masinájukban, mint ami a csomag készítőjének masinájában van. Én találkoztam ilyennel a VICE esetében többször is a c128 parancs futtatásakor az én szintén kétmagos Intel processzoros gépemen, A csomagot Imre csinálta, vagy te. Újrafordítottam mindig, és rögtön helyrejött és az nálatok is futott, vagy ki sem próbáltátok.

[rezso]

Én biztos, hogy pl. egy trigger-rally, vagy vice esetében nem nézek ilyesmit. Nekem emulátorból elég a virtualbox, a játékokból pedig a tsc és a zaz, bár gondolkozom rajta, hogy kidobom őket. Van gond és nyűg épp elég a játékok és emulátorok spéci hülyeségei nélkül is.

[attuska]

A trigger rally appimage az Intel GPU-s masinán sem megy, a csomagunk is illegális utasítást észlel. Nyilván az appimage is más CPU -val készült, mással, mint amik nekem vannak. Ha meg akarjuk tartani, akkor ki kell belőle irtani ezt a beleégetett optimatizálást. Én képtelen vagyok leellenőrizni az eredményt, mivel nekem más CPU -im vannak, és nem a saját gépemre fordítok csomagot, így, módosítás nélkül az egész játék kuka! Aki használni akarja, az rakja fel a saját gépére, arra optimalizálva. Így, ahogy van nem lehet belőle univerzális, minden CPU-n futó csomagot csinálni belőle sehova semmilyen disztribúción!

[rezso]

Te vagy az egyetlen, aki ilyen gondot jelzett, szóval nyugodtan lefordíthatod magadnak.

[attuska]

Lehet, hogy más meg sem próbálta a trigger-rally-t. Én nem használom, alig van egy-két játék, amit használok, nekem nem kell. Maradjon felőlem úgy ahogy van. Ha valakinek majd problémája akad, vele, akkor majd jelzi.

[rezso]

Én úgy látom, hogy a 2 játék sor, a 03-16 (emuátorok), és a 03-12 (development) tele van olyan cuccokkal, amiket senki nem használ. Szóval ezeket simán lehetne ritkítani.

[attuska]

Felőlem kihajíthatod mind, én nem teszem. A választék bővítésére vannak csupán, sokan fáradoztak valaha a csomagok elkészítésével és nem csupán saját célra. Az UBK3-at, vagy az UBUNTU-t illetve annak származékait fogom majd ajánlani az esetleges hiányolóknak. A végén az egész UBK4-et csak te fogod egyedül használni.

[rezso]

Akkor úgy lesz. Nem működő cuccoknak nincs értelme. Ha a trigger-rally fordításának módosításához is én kellek, akkor hadd döntsek arról, akarok-e foglalkozni vele.

[attuska]

A trigger-rally-t módosítottam, csomagot felraktam. https://github.com/uhulinux/ub-ubk4/commit/aa14c4a37c95412da844b552d7c6189bf3b0f9fa

[attuska]

A tulip is kidobandó! Az intel dual CPU-n ez van: attila@derp-x8664:~$ gdb tulip GNU gdb (GDB) 12.1 Copyright (C) 2022 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-pc-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: https://www.gnu.org/software/gdb/bugs/. Find the GDB manual and other documentation resources online at: http://www.gnu.org/software/gdb/documentation/.

For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from tulip... (No debugging symbols found in tulip) (gdb) r Starting program: /usr/bin/tulip [Thread debugging using libthread_db enabled] Using host libthread_db library "/usr/lib/libthread_db.so.1". [New Thread 0x7fffe502b6c0 (LWP 11090)] [New Thread 0x7fffdf3a56c0 (LWP 11091)] [New Thread 0x7fffdeb816c0 (LWP 11092)] [New Thread 0x7fffd7fff6c0 (LWP 11093)] [New Thread 0x7fffd77fe6c0 (LWP 11094)] [New Thread 0x7fffd6ffd6c0 (LWP 11095)] [New Thread 0x7fffd67ba6c0 (LWP 11096)] [New Thread 0x7fffd5fb96c0 (LWP 11097)] [Thread 0x7fffd67ba6c0 (LWP 11096) exited]

Thread 1 "tulip" received signal SIGILL, Illegal instruction. 0x00007fffd459b8c6 in ?? () from /usr/bin/../lib/../lib/tulip/libOGDFPlugins-5.6.3.so (gdb) bt

0 0x00007fffd459b8c6 in ?? ()

from /usr/bin/../lib/../lib/tulip/libOGDFPlugins-5.6.3.so

1 0x00007ffff7fcec2e in ?? () from /usr/lib/ld-linux-x86-64.so.2

2 0x00007ffff7fced1c in ?? () from /usr/lib/ld-linux-x86-64.so.2

3 0x00007ffff5b6dc54 in _dl_catch_exception () from /usr/bin/../lib/libc.so.6

4 0x00007ffff7fd5326 in ?? () from /usr/lib/ld-linux-x86-64.so.2

5 0x00007ffff5b6dbfe in _dl_catch_exception () from /usr/bin/../lib/libc.so.6

6 0x00007ffff7fd56bc in ?? () from /usr/lib/ld-linux-x86-64.so.2

7 0x00007ffff5aa258c in ?? () from /usr/bin/../lib/libc.so.6

8 0x00007ffff5b6dbfe in _dl_catch_exception () from /usr/bin/../lib/libc.so.6

9 0x00007ffff5b6dcb3 in _dl_catch_error () from /usr/bin/../lib/libc.so.6

10 0x00007ffff5aa205f in ?? () from /usr/bin/../lib/libc.so.6

11 0x00007ffff5aa2641 in dlopen () from /usr/bin/../lib/libc.so.6

12 0x00007ffff7820021 in tlp::PluginLibraryLoader::loadPluginLibrary(std::__cxx11::basic_string<char, std::char_traits, std::allocator > const&, tlp::PluginLoader*) () from /usr/bin/../lib/libtulip-core-5.6.so

13 0x00007ffff782051d in tlp::PluginLibraryLoader::initPluginDir(tlp::PluginLoader*, bool, std::__cxx11::basic_string<char, std::char_traits, std::allocator > const&) () from /usr/bin/../lib/libtulip-core-5.6.so

14 0x00007ffff78216c8 in tlp::PluginLibraryLoader::loadPluginsFromDir(std::cxx11::basic_string<char, std::char_traits, std::allocator > const&, tlp::PluginLoader*, std::cxx11::basic_string<char, std::char_traits, std::allocator > const&) () from /usr/bin/../lib/libtulip-core-5.6.so

--Type for more, q to quit, c to continue without paging--

15 0x00007ffff7c3756b in tlp::initTulipSoftware(tlp::PluginLoader*, bool) ()

from /usr/bin/../lib/libtulip-gui-5.6.so

16 0x00005555555ad28e in main ()

(gdb) q A debugging session is active.

Inferior 1 [process 11087] will be killed.

Quit anyway? (y or n) y attila@derp-x8664:~$

[attuska]

Véletlen futottam be ebbe a tulip gondba, a frissebb és ezen a gépen fordítoitt simán megy. Nem rakom fel. A letöltött Appimage sem működik.

Talán a te laptottyodon megy a tárolónéli, ha nem, akkor neked is laptottyot kell cserélni mert ez a hiba nindenképp CPU güggő kód opimalizálási gond.

A másik lehetőség, hogy sorravesszük az összes csomagot, és amelyik illegális utasításba fut, azt mind kidobjuk.

[rezso]

Vagy el kell felejteni az -march=k8 gcc opciót. Az is simán okozhat gondokat, és talán a debian használja csak. Nálam amúgy megy, de gőzöm sincs, mire való. Akár ki is dobhatjuk.

[attuska]

Nekem sem kell ez a tulip, de valami épeszűt ki kellene találni erre az optimatizációra, mert bármikor bárki belefuthat bármelyik csomagnál, aki nem épp az ő gépére fordítottat használja. Úgy vélem, hogy a programok karbantarói, fejlesztő csak arra koncentrálnak, hogy mindenki a saját gépére fordítja az ápoltjukat. Mi, UHU linux csomagkészítők pedig nem! Az mégsem megy, hogy minden fejlesztő, karbantartó figyelmét erre felhívjuk erre a tényre. Az sem, hogy valamennyi csomagunkat temérdek hardveren kipróbáljuk.

[rezso]

A mostani helyzetnek egy előnye azért van: így mindjárt kiderül, ha egy csomag nem szükséges / nem megfelelő opciókat használ alapból / túl problémás. Persze az igazi kérdés az, hogy ugyanaz (?) az uhubuild ugyanazzal a gcc-vel és alap opciókkal miért készít más kódot? Lehet, hogy az UB_CFLAGS az ub_compile scriptbe kellene az ub_configure helyett? És vissza kellene tenni bele az -march=k8 opciót? Mert a tulip ugye cmake-s. Ettől függetlenül azért ilyesminek nem lenne szabad előfordulnia.

[attuska]

"Persze az igazi kérdés az, hogy ugyanaz (?) az uhubuild ugyanazzal a gcc-vel és alap opciókkal miért készít más kódot? Lehet, hogy az UB_CFLAGS az ub_compile scriptbe kellene az ub_configure helyett? És vissza kellene tenni bele az -march=k8 opciót? Mert a tulip ugye cmake-s." Ennyire nem vagyok otthon ebben, csak felfigyeltem újból egy problémánkra. Főleg a cmake idegen nekem. De az már a második cmake-s cucc, amivel nem bírok. Most fordítottam le az AMD CPU-s masinámra ezt (szintén befrissítve), ezen is megy, valamit lépni kell.

[rezso]

Nem maga a cmake a gond, hanem az, hogy nem autotools-os a cucc. Autotools-nál az ub_configure tartalmaz egy ilyet: UB_CFLAGS="-O2 -m64 -mtune=generic ${CFLAGS:-}" De ha nincs configure, mert épp cmake-s a cucc, akkor ez a cflag nincs beállítva. Talán ez a gond. De csak talán, mert semmi nem biztos...

[attuska]

Erről a tulip-ról már volt egy issue-m. Volt még egy rakás másról is, ami épp a kezem ügyébe került. (VICE, eduke32, openttd, satöbbi ) Az esetleges leendő build tesztelése csak kooperációban lehetséges, többféle CPU-n kipróbálva a binárist.

[rezso]

Jut eszembe: rengeteg cmake-s cucc van, ami teljesen jó, ilyen pl. a teljes kde és lxqt. Szóval nem itt lesz a hiba.