Perl 6 - the future is here, just unevenly distributed

IRC log for #divine, 2016-10-10

| Channels | #divine index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:31 divine-buildbot joined #divine
00:39 divine-buildbot joined #divine
01:17 divine-buildbot joined #divine
01:31 xstill joined #divine
01:48 ilbot3 joined #divine
01:48 Topic for #divine is now DIVINE | http://divine.fi.muni.cz | http://irclog.perlgeek.de/divine/
02:04 divine-buildbot joined #divine
02:12 divine-buildbot joined #divine
06:24 divine-buildbot joined #divine
07:40 yaqwsx joined #divine
08:26 xstill_ jo, buidlbot na postgresu je super, má špatně velké sloupce na kontext
08:27 xstill_ takže jsem opravil databázi a snad si to nemodifikuje schéma :-D
09:00 yaqwsx joined #divine
09:01 divine-buildbot joined #divine
09:14 evenfall on je celej ten darcs plugin do buildbota trochu jetej
09:55 xstill_ no je
09:55 xstill_ však já ho mám ohackovanej aby uměl UTF-8
10:23 yaqwsx U mě jsou patche, které implementují __dios_fault a nahrazují __vm_fault.
10:27 mornfall zrovna jsem vylezl z domu, ale jak se vratim mrknu na to
11:31 yaqwsx Ok
12:08 yaqwsx __vm_obj_make o velikosti 0 vrátí validní pointer (na který samozřejmě nepůjde nic zapsat, ale i tak jej bude možné použít pro id vlákna)
12:10 evenfall to je dotaz nebo konstatování?
12:11 yaqwsx Chybí otazník a je to dotaz, jestli je to možné.
12:14 evenfall yaqwsx: mělo by to vyfaultovat
12:16 yaqwsx Ok, takže není rozumné se v __dios_start_thread ptát na to, kolik nalokovat paměti jako TLS.
12:24 yaqwsx Bude něčemu vadit, když TLS zavedu 1bytovou "hlavičku" - tzn. i když uživatel DiOS sycallů nebude chtít žádné TLS, tak mu naalokuji 1 byte?
12:25 evenfall nevim, pomůže něčemu zrovna 1 bajt? :)
12:25 yaqwsx Můžu jeho pointer použít jako ID vlákna :)
12:25 evenfall jo to chápu, ale pokud to má být hlavička tak radši zarovnaná
12:26 yaqwsx Ok, myslel jsem, že DIVINE si na zarovnání nehraje
12:27 evenfall nicméně pokud tam nechceš nic ukládat, tak nevidim důvod dávat tomu hlavičku (prostě bych alokoval std::max( žádaná velikost, 1 )
12:27 evenfall )
12:27 evenfall hraje nehraje, až tam někdo uloží ukazatel na offset 1 tak poznáš jak nehraje :p
12:27 yaqwsx Přemýšlím, jestli bych pro to našel nějaké využití. Pokud jej nenajdu, tak naalokuji max(1, vel)
13:08 xheno joined #divine
13:17 xheno evenfall: Padá mi divine run pri inicializácii a netuším čo s tým. Bitkód na ktorom to padá je na arke /var/tmp/xlauko/abstract.bc.
13:35 evenfall xheno: zdá sa že run nefunguje na ničom :-)
13:39 evenfall xheno: ale ak ti to padá s   expected funcMetaT->getNumElements() == 11 && "Incompatible _MD_Function"
13:40 evenfall xheno: tak máš starý bitkód
13:40 xstill_ evenfall: protože máš novější divine
13:41 evenfall ok, zrovna jsem vytáhl rozbitej test.c, run normálně funguje
13:42 evenfall xheno: updatuj si divine a bitkód, ať tady nemusím laborovat
13:42 xheno Pracujem na tom.
14:19 yaqwsx evenfall: Přemýšlel jsem, jak řešit uvolňování TLS. Nejrozumnější mi připadá, aby si uživatel mohl zaregistrovat destruktor TLS, který se zavolá kdykoliv vlákno skončí nebo je zabito. Vyhnu se tak problému, jak v pthreadech dealokovat vlákno, které samo skončilo.
14:21 evenfall yaqwsx: jak může vlákno samo skončit?
14:22 yaqwsx Skončí jeho hlavní rutina?
14:22 evenfall no, to je typicky _pthread_entry nebo tak cosi
14:22 evenfall to si asi může řešit dealokaci úplně libovolně
14:23 kejsty joined #divine
14:23 yaqwsx Takže v podstatě by stačilo prohlásit, že jakmile skončí hlavní rutina, bude TLS ihned dealokováno?
14:23 evenfall tady je dneska nějak živo :D
14:24 xstill_ evenfall: řešíme ve VFS, že je to napsané tak, že to vyhazuje výjimky při chybě a to se pak konvertuje na errno, jenže teď v kernelspace nefungují výjimky. Otázka je, jestli zprovoznit výjimky v kernelspace, nebo to řešit nějak jinak
14:24 evenfall xstill_: proč nefungují?
14:24 xstill_ jak na to kejsty koukala, tak ty výjimky jsou dost hluboko
14:24 xstill_ evenfall: protože používají pthreadové TLS
14:25 evenfall to je pravda trochu nešťastné
14:25 xstill_ asi se to dá obejít tak že se zdetekuje, že jsme v kernelu
14:25 xstill_ jde nejspíš jen o __cxa_get_globals
14:25 evenfall ale ty cxa globals přece nejsou v tls
14:25 xstill_ tj. muselo by se upravit __cxa_get_globals aby v kernelu vracelo nějakou globální poměnnou
14:26 xstill_ jsou, signal handlery jsou per thread
14:27 xstill_ aha ne handlery ale uncaughtExceptions
14:27 evenfall jo, je tam něco perthread
14:27 xstill_ (libcxxabi/src/cxa_exception.hpp)
14:27 xstill_ je to přes pthread_key
14:28 xstill_ pokud má kernel vždycky stejné globální proměnné tak se na kernel globals dá vytvořit globální proměnná a tu vrátit
14:28 xstill_ jinak by se musel dost zásadně přepsat filesystém
14:28 evenfall ne, kernel nemá žádné globální proměnné
14:28 evenfall resp. teď má ty stejné jako (jediný) proces
14:29 evenfall ale není v plánu to tak nechat
14:29 xstill_ hm, pak je to docela problém, protože já se ke stavu scheduleru asi nedostanu
14:29 evenfall v kernelu jo, je v registru
14:29 xstill_ aha
14:30 xstill_ ale je zas trochu úchylné tam cpát implementační detail z C++ výjimek
14:31 evenfall no, ono by dost pomohlo kdyby byl dios v jiným .bc než program
14:31 evenfall takhle to bude docela bolet
14:31 xstill_ jak to s tím souvisí; nevím no, v podstatě jde o to, jestli mít v kernelu výjimky
14:31 evenfall nemít je tam znamená -fno-exceptions pro kernel a to znamená jinak přeložený libc++
14:33 evenfall (stejně tak by šlo řešit výjimky #ifdefama v libcxxabi, ale momentálně máme stejný knihovny pro kernel aj pro program)
14:33 evenfall přepisovat dios do C asi nikdo nechce :-)
14:34 evenfall a C++ bez výjimek je dost opruz, protože se s nima všude počítá
14:35 evenfall asi bych prozatím upravil cxa_exception_storage.cpp resp. __cxa_get_globals aby v kernelu vraceli něco ze stavu a dios si to bude muset vytáhnout z cxa_exception.hpp (tam je ta struktura kterou to chce)
14:36 evenfall to že běží kernel se pozná z _VM_CR_Flags
14:36 evenfall viz https://divine.fi.muni.cz/manual.html#control-registers ;-)
14:37 xstill_ jo to mi Honza říkal, že to dokážu zjistit
14:38 xstill_ OK, tak já to zkusím vymyslet
14:38 evenfall on by to měl být třířádkovej patch...
14:45 xstill_ hm, ono je to ale divný, ono to zfaultuje až při release masky, ne v tom __cxa_get_globas
14:47 xheno evenfall: Nahral som nový bitkód na arke.
14:47 xstill_ je možný, že __vm_control spustí tu chybu (interrupt v kernel space)?
14:48 xstill_ teda odmaskování
14:48 evenfall xstill_: odmaskovat se v kernelu je fakt blbej nápad :)
14:48 xstill_ jo, tak to bude tím
14:51 evenfall my máme někde odmaskování které nerespektuje to že to už bylo pod maskou?
14:51 evenfall (jinde než v syscall-u)
14:51 xstill_ jo, protože InterruptMask je blbě
14:52 xstill_ teda release v něm
14:52 evenfall nojo, fakt
14:53 xstill_ jo, až to opravím tak to možná začne fungovat, ačkoli ty výjimky budou technicky pořád rozbitý
14:54 evenfall jo, pokud je getspecific bezsyscallový tak to bude fungovat než Honza udělá fork
14:57 xstill_ kejsty: zkus darcs pull /home/xstill/DIVINE/divine4 a vzít jen ten úplně poslední patch na runtime, snad by neměl na ničem závist
14:59 xstill_ evenfall: ty to ještě netahej, nedoběhly testy
14:59 evenfall xstill_: není to dole hlavou?
14:59 evenfall hm, není
14:59 xstill_ proč?
15:00 evenfall ale to acquire je divný
15:00 evenfall jenžé ono vlastně aj to release je divný
15:00 evenfall jenže*
15:02 xstill_ no není, ten release nesmí nic udělat pokud to bylo pod maskou předtím, z toho hlediska ani acquire nemůže, protože je to pořád pod maskou (nedá se vytvořit nezamaskovaný InterruptMask)
15:04 evenfall jo já chápu proč to tak má být, ale nevim co udělat aby to bylo zřejmý
15:05 evenfall pojmenovat to reacquire by mohlo být trochu jasnější (tzn. je smysluplný volat to jen po release)
15:06 xstill_ to by šlo, ale to bych udělal zvláš, stejně budu vyhazovat to _owns
15:06 evenfall jo, já si říkal že to _owns jsme už někdy řešili
15:09 evenfall ještě teda nevim jestli by nebylo lepší to release/acquire zrušit úplně a mít API který dostane lambdu
15:10 evenfall to by mělo výhodu, že to jde udělat exception-safe
15:11 evenfall (takhle když ti mezi release/acquire vyletí výjimka kterou chytne ta stejná funkce, tak se to asi dost rozsype)
15:11 xstill_ jo, to by šlo
15:12 evenfall resp. když se ta maska předává, tak to ani nemusí být stejná funkce, ale prostě pokud ta výjimka nezlikviduje ten RAII objekt
15:14 evenfall xheno: kam si to dal?
15:14 evenfall xheno: abstract.bc mi stále padá na to isté
15:16 evenfall
15:17 xheno evenfall: už by tam mal byť určite ten nový
15:18 xheno Padalo mi to v ~Module().
15:24 evenfall zjavne sa tomu nepáči keď BitCode::init() vyhodí výnimku
15:26 evenfall xheno: pokúša sa to hlásiť unresolved symbol
15:26 evenfall declare %lart.abstract.i32* @lart.abstract.create()
15:26 evenfall ale prečo to skape mi nie je úplne jasné
15:52 xheno evenfall: dik, už to beží :)
17:05 yaqwsx joined #divine
17:52 yaqwsx Co všechno je třeba upravit, pokud chci změnit typ PI, který se traceuje, když chci reportovat seznam vláken?
18:31 yaqwsx Eh... současná implementace pthreadů těžce spoléhá na to, že gtid je číslo...
18:56 evenfall yaqwsx: a jak to je s tím typem faultu? cos říkal že padá?
18:57 evenfall (zatím jsem to nepullnul, částečně taky proto, že 3 patche na 4 řádky změn mi přijde trochu přehnaný :)
18:57 evenfall (chápu snahu rozdělit to podle toho kam to spadlo, ale tady by asi bylo lepší to splácnout pod VM: s tím, že ty ostatní změny jsou logický důsledek)
18:58 evenfall (nebo maximálně rozdělit na VM: a runtime:)
18:59 yaqwsx Jakmile jsem pullnul patche za poslední 4 dny, tak to najednou přestalo padat
19:00 yaqwsx Umím nějak v darcsu ty runtime patche spojit, když mám momentálně velmi rozházený pracovní adresář?
19:00 evenfall asi si to zarecorduj jako XXX :)
19:00 evenfall kdyžtak nakonec zase unrecord
19:04 evenfall yaqwsx: no nevim, tento měsíc tam nevidim nic co by s tím mohlo souviset... je to docela záhadný
19:07 xstill evenfall: není možný že ta výjimka se vyhodí v době kdy je modul z nějakého důvodu v nekonzistentním stavu? Ale vypadá to trochu jako bug v llvm…
19:07 yaqwsx Já právě také ne. Podezřelé mi bylo i to, že to dělalo jen v release buildu.
19:07 yaqwsx Patche jsem splácnul dohormady.
19:07 xstill počkat, nám tu výjimku něco chytá? Protože jinak se ten destruktor neměl proč volat…
19:08 xstill hm, tak si říkám jak se vlastně v tomhle chová můj unwinder
19:10 xstill aha to vlastně řeší libc++abi
19:14 xstill hm, až na to, že se to chová jinak než nativně, protože to vesele odunwinduje až do _start
19:16 xstill mornfall: btw. když si sim-uješ test/cpp/exception-uncaught.cpp až k fault handeru, pak skáčeš po stacku k __clang_call_terminate a dáš source tak to zasegví (v release)
19:17 xstill ok, v debugu to zdechne ještě dřív
19:17 xstill evenfall: E: .../divine/vm/eval.hpp: 213:
19:17 xstill expected p.defined()
19:20 xstill popravdě moc nechápu kde se v _start vzal ten chatchall landingpad
19:23 xstill jo, už vím
19:25 yaqwsx joined #divine
19:26 xstill on totiž _start nesmí být noexcept
19:34 xstill btw. tohle je příklad dalšího místa kde by dávalo smysl mít konfigurovatelnost (a zrovna tady se to bude dělat relativně blbě): je tu nedefinované chování, standard řáká, že pokud výjimka není chycena, ka se může, ale nemusí unwindovat
19:35 evenfall to není UB
19:35 evenfall implementation-specified
19:35 evenfall (je to rozdíl)
19:36 evenfall dělá to v něčem rozdíl?
19:36 evenfall stejně se pak zavolá nějakej ten handler
19:36 xstill OK, to je pro tohle uvažování skoro jedno. Mě dává větší smysl mít jako default neunwindovat, jednak proto, že to je chování běžné implementace (alespoň na linuxu) jednak proto, že to může potenciálně rozbít věci co spolíhaj na destruktory. Na druhou stranu, ten unwind může potenciálně taky něco rozbít
19:36 yaqwsx Proč se v současné implementaci pthreadů pokládá mutex_owner roven gtid + 1?
19:36 xstill podobně jak teď nám ten unwind v divine nejspíš zavolat destruktor nekonzistentního modulu
19:36 evenfall yaqwsx: 0 asi znamená odemčeno?
19:37 xstill yaqwsx: jo, tak jak říká mornfall
19:37 xstill main thread je 0
19:37 evenfall xstill: no ne, kdyby to bylo UB tak se může stát cokoliv
19:37 evenfall xstill: můžeš se nedeterministicky rozhodnout :p
19:38 evenfall jsou jen 2 možnosti
19:38 xstill no dobře, tak to není UB, ale to nic nemění na tom, že dává smysl se zamyslet, kterou alternativu chceme a moct se rozhodnout
19:39 evenfall bych tam klidně dal obojí a uvidíme jak se to chová
19:39 xstill zkusím se podívat jestli to nějak rozumně jde
19:39 evenfall jestli jde co?
19:40 xstill no, záleží kdo rozhodne jestli se bude nebo nebude unwindovat, pokud unwinder tak to v pohodě můžeme nedetrmisticky rozhodnout, jestli libc++ může to být horší
19:40 xstill druhá věc je otázka kam unwindovat
19:41 xstill ale asi po poslední landingpad na stacku a resume z něj ten stack zníčí úplně? (jak se vůbec ničí stack?)
19:41 evenfall libc++abi by mohlo, libc++ skoro určitě ne
19:41 xstill to jsem myslel samozřejmě
19:41 evenfall unwindovat můžeš až na dno
19:42 evenfall resume jen zavolá zase unwinder
19:42 xstill jo, ale dnem myslíš poslední rámec, nebo "nic"?
19:42 xstill a pak je možná požeba nějak říct diosu, že jsem zničil vlákno
19:42 xstill yaqwsx: ^
19:43 evenfall no teoreticky to jde až na nic, ale není jasné co má ten unwinder udělat pak
19:43 evenfall resp. musí to jít až na nic, jinak se spustí nějakej kus kódu úplně mimo očekávaný kontext
19:43 yaqwsx Pokud vláknu nastavíš rámec na nullptr, tak pak se s tím DiOS vypořádá sám.
19:44 evenfall yaqwsx: jo, jenže to dost dobře nejde
19:44 evenfall no teda jde
19:44 evenfall xstill: stačí aby si unwinder pak nastavil parent pointer na null a udělal ret
19:44 xstill vida, to ani nebolí
19:45 xstill hm, tak teď když to nikdo nechytá tak se _Unwind_RaiseException vrátí
19:45 xstill což nevím jeslti odpovídá linuxovému libunwindu
19:46 evenfall xstill: odpovídá
19:46 evenfall xstill: __cxa_throw zavolá failed_throw když se to vrátí
19:46 evenfall komentář píše, že to může znamenat 'no handler'
19:48 xstill jop, to vidím, mě šlo o to jestli se unwinder vrací
19:48 xstill to že libc++ dělá v divine to samé co v systému není až tak překvapivé
19:48 xstill aha, komentář jsem ale neviděl
19:49 xstill nicméně i s libsupc++ se to chová stejně
19:51 xstill což je vlastně celkem fajn
19:51 xstill protože se stačí nedeterministicky rozhodnout jestli to teda unwindovat nebo se vrátit z unwinderu
19:57 xstill hm, nějaká LTL, já potřebuju alespoň CTL* na většinu vlastností který nepopíšu safety
19:57 evenfall yaqwsx: ad to PI, co s ním chceš měnit?
19:58 yaqwsx TID je nyní pointer, nikoliv int
19:58 evenfall yaqwsx: a nevim co přesně jsi provedl s tím change fault handler type, ale zmizelo to
19:58 evenfall yaqwsx: no tak to není :]
19:59 evenfall yaqwsx: to info je pro uživatele sim-u
19:59 evenfall takže by bylo dobrý z toho vyčarovat něco smysluplnýho
19:59 yaqwsx Nechtěl jsem si u vláken držet lidsky čitelné ID, aby to nepokazilo kanonizaci.
20:00 evenfall chápu že sekvenční to asi nebude, ale třeba object id v konverzi na číslo?
20:00 yaqwsx Nemůže tam nastat kolize?
20:00 evenfall kolize v čem?
20:00 yaqwsx Přetypování pointeru na int
20:00 yaqwsx Abych nedostal 2 vlákna se stejným id.
20:00 evenfall no ale kolize jakého typu?
20:00 evenfall jo to by nemělo jít :-)
20:01 evenfall nebo myslíš proto že je int krátkej?
20:01 yaqwsx Pointer je v Divinu 64 bit, nebo se pletu?
20:02 evenfall yaqwsx: jo, ale ideálně chceš jen prvních PointerObjBits což je shodou okolností 32
20:03 evenfall nicméně tady narážíme na mnohem veselejší problém
20:03 evenfall (z pohledu uživatele)
20:04 evenfall když v sim-u dorazíš do nějakého stavu nějakou cestou, a pak nějakou jinou, tak nemusí štimovat tady ty object id
20:04 evenfall a když to bude zrovna hrát roli thread id, mohlo by to být docela matoucí
20:04 yaqwsx Meh.
20:05 evenfall (on teda divine pozná, že to je stejnej stav, ale nemá moc jak zabezpečit tady tu kontinuitu z obou stran)
20:11 xstill jo, ale s tím se nic nedá dělat než dekanonizovat vlákna, a to za to nestojí
20:12 xstill nicméně celkově by (časem) stálo za to mít něco co na tracu dokáže sledovat změny hodnot pointrů a "polidštit" to, už třeba proto aby se dalo poznat, kde se naalokoval leaknutej pointr…
20:14 evenfall na tracu se pointry snad ani měnit nemůžou, protože parent strom vede po prvních objevených cestách (potřeba rozmyslet)
21:31 yaqwsx Co je na tomto userspace kódu tak špatně, že přiměje Divine zasegvit? bool kernel = ( (uint64_t) __vm_control( _VM_CA_Get ) ) & _VM_CF_KernelMode;

| Channels | #divine index | Today | | Search | Google Search | Plain-Text | summary