Perl 6 - the future is here, just unevenly distributed

IRC log for #divine, 2016-10-11

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

All times shown according to UTC.

Time Nick Message
00:51 divine-buildbot 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/
05:54 mornfall chybi parametr
05:55 mornfall a ten cast na rv je zbytecnej
06:11 yaqwsx joined #divine
06:26 yaqwsx Taková hloupost.
06:30 yaqwsx Jak správně ošetřit fault v kernelu? Momentálně každý fault v kernelu skončí na double faultu, protože fault handler se pokusí přerušit zpátky do scheduleru, což v kernelu nesmí. Jak zastavit scheduler a skočit do něj znovu?
07:22 yaqwsx joined #divine
07:34 mornfall handler taky pozna ze je v kernelu, asi bych to v ten moment zarizl
07:35 yaqwsx Zaříznout == uklidit zásobník?
07:36 mornfall asi hlavne stav
07:43 yaqwsx Tak teď nerozumím. Jsem v scheduleru, vyskočí mi fault a ve fault handleru se mám zachovat jak? Jak z fault handleru vykřičím stav?
07:58 mornfall yaqwsx: no, řešil bych to tak, že bych (pokud jsem v kernelu) vyklidil stav (podle _VM_CR_State), nastavil _VM_CF_Error, nastavil si parent-a na null a vrátil se
07:59 mornfall yaqwsx: když jsi na tom tak zle, že ti faultuje kernel, na nějaký unwindování do scheduleru bych si netroufal
08:03 mornfall yaqwsx: druhá věc je, že fault handler by ve skutečnosti měl spadnout do kernelu pokud tam ještě není, protože to hrabání na _VM_CR_State který teď dělá se bude muset zakázat
08:04 mornfall (a pokud bychom to řešili tím, že fault přepne mód na kernel, tak zase není jak poznat že ten fault pochází z kernelu)
08:04 mornfall nicméně uživatelský faulty mi přijde relativně bezpečný prohnat skrz syscall kterej to vyřeší a buď se vrátí nebo ne
08:07 mornfall tím by se taky mohl zlikvidovat ten 'triggered' a ten check na začátku scheduleru
08:07 mornfall kterej taky není zadarmo :)
08:49 xstill joined #divine
08:56 yaqwsx Ok, když si ve fault handleru nastavím parenta na null, nastavím __vm_control( _VM_CA_Bit, _VM_CR_Flags, _VM_CF_Error, _VM_CF_Error ), __vm_control( _VM_CA_Bit, _VM_CR_Flags, _VM_CF_Cancel, _VM_CF_Cancel ) a vrátím tak to korektně vytvoří chybový stav?
09:01 yaqwsx Tam mi ale přece bude chybět stav, ne?
09:08 yaqwsx Ok, ale ten si umím vyrobit i jinak.
09:10 yaqwsx Jedna otázka: skutečně je bit _VM_CF_KernelMode invertovaný? Tzn. 0 kernel mód, 1 user mód?
09:37 xstill joined #divine
10:52 mornfall nemel by byt
11:04 mornfall mam jit do labu az dojim? mam cas do ca 4
11:09 yaqwsx Od 13:45 do 16:00 mám výuku.
11:12 mornfall co ostatní, potřebuje někdo něco řešit?
11:13 mornfall (zítřek normálně bude, takže pokud nic tak dneska asi knihovna :)
11:13 yaqwsx Vesměs se shodli na tom, že tě chtějí až zítra, protože dneska nestíhají :D
11:15 mornfall :D
11:15 mornfall ok
11:17 yaqwsx Já bych asi potřeboval vyjadnit jednom jednu věc ohledně registrů. 1) Zápisem do _VM_CR_Frame provedu skok?
11:18 yaqwsx 2) Při návratu do scheduleru najdu v _VM_CR_IntFrame rámec, který byl přerušen?
11:18 yaqwsx 3) Ve scheduleru _VM_CR_Frame obsahuje co?
11:19 yaqwsx 4) Zápis do _VM_CR_IntFrame má nějaký efekt?
11:19 yaqwsx EDIT: Už jsem našel polovinu odpovědí v manuálu, prvně mrknu tam.
11:21 yaqwsx Ok, manuál mi nedal odpověď na 1 a 4
11:41 yaqwsx Vyřešeno, přehlížel jsem jeden detail...
15:27 yaqwsx joined #divine
16:38 yaqwsx joined #divine
16:38 mornfall yaqwsx: jaký detail to byl?
16:39 yaqwsx Že se prohazuje Frame a IntFrame
16:40 yaqwsx Zítra bych se s tebou chtěl ještě pobavit o tom, jak vyrábět chybový stav přímo z fault handleru. Narazil jsem na jeden problém.
16:45 mornfall ok (jestli se ti to chce tady popsat, tak se můžu vyjádřit i zde, ale klidně to počká do zítra)
16:49 yaqwsx Můžu to zkusit - chci vyrábět chybový stav přímo v fault handleru. Tzn. nechci scheduler->terminate() volat interruptu, ale přímo z fault handleru. Scheduler-terminate() je třeba volat v kernel módu (tzn. musím mít korektní rámce vláken v interních strukturách DiOSu). Když jej totiž zavolám z user kódu, nemám konzistentní rámce a můžu přistoupit do neplatné paměti.
16:49 yaqwsx Otázka - jak to řešit?
16:50 yaqwsx Zavést syscall terminate, který bude hybridní? (tzn. když je volán z user space, tak proběhne syscall_trap, jinak se zavolá přímo)
16:51 mornfall já si to představoval tak, že fault handlel se rozdělí na 2 části, třeba f1( ... ) který se podívá na _VM_CF_KernelMode a podle toho buď udělá syscall na f2 nebo f2 rovnou zavolá
16:52 mornfall to jestli to bylo z kernelu nebo z user mode by byl jeden z parametrů f2
16:52 mornfall no a f2 se může (ale nemusí) vrátit
16:52 mornfall třeba klidně může udělat terminate
16:52 mornfall (pokud šlo o user-mode fault)
16:53 yaqwsx Ok, to se naše představy celkem shodují.
16:53 mornfall (a podle toho jaká je konfigurace faultu)
16:53 mornfall mimo jiné to znamená, že f1 nepotřebuje vidět _VM_CR_State, stačí tomu Flags
16:54 yaqwsx Ok
16:54 mornfall a v f2 není potřeba řešit syscally, jen zavolá scheduler->terminate() nebo jak se to jmenuje
16:54 mornfall ctx->scheduler->terminate()
16:55 yaqwsx A f1 bude traceovat.
16:55 mornfall to spíš f0 ne?
16:55 mornfall kde f0 ~ __dios_fault
16:55 mornfall f1 je to co je ve _VM_CR_FaultHandler
16:56 mornfall Lundenburg, musím vystoupit :D
16:56 mornfall bbiab
16:56 yaqwsx Ok
17:16 evenfall ten problém by tady neměl existovat, je tak?
17:24 xstill mornfall: ono to vypadá, že podle Itanium ABI _Unwind_RaiseException neunwinduje pokud nenajde handler. Přičemž libc++ nebere cleanup jako handler. Takže buď bychom museli modifikovat libc++ (což se mi moc nechce), nebo unwindovat i přes to, že to ABI unwinderu nepovoluje (což mi vadí míň), pak bych to ale dělal jen pokud ta výjimka bude C++ výjimka, stejně jinak nemáme moc jak zavolat
17:24 xstill terminate handler (ten totiž bude muset volat unwinder, protože jinak by resume vrátil a to fakt nejde).
17:36 evenfall asi mi to není jasný
17:37 evenfall teď když se na to dívám, tak mi přijde, že pokud se ten stack unwinduje, tak to dopadne tak, že __cxa_throw bude mít null parenta, což ničemu nevadí, zavolá se std::terminate jako kdyby unwinder nic neudělal a jede se dál?
17:37 evenfall resp. terminate handler
17:48 xstill no 1. standard c++ nefinuje, že pokud výjimka není chycená, tak se zavolá terminate handler, který program zabije (to zabití teda na cppreference není, ale odvozuju to z implementace a logiky věci), říká ale, že to jestli se zásobník v tomto případě unwinduje je implementation defined
17:49 xstill 2. standarně na x86(_64) na linuxu se používá Itanium-ABI unwinder, _Unwind_RaiseException definuje, že pokud není handler tak vrátí
17:50 xstill 3. libc++ nereportuje cleanup jako handler, nejspíš proto, že po unwindu do clenup handleru by se už nemusela dostat ke slovu aby měla šanci zavolat terminate
17:50 xstill (cleanup handler volá _Unwind_Resume, přímo, ne přes nějaké C++ věci)
17:50 xstill s/libc++/libc++abi
17:53 xstill (tj. libc++abi už nedostane šanci zavolat terminate z _Unwind_Resume pokud tam není další handler, což by způsobilo, že by _Unwind_Resume vrátil, s tím se ale nepočítá)
17:53 xstill takže vlastně modifikace libc++abi ani nepřichází v úvahu
17:53 xstill možnosti jsou tedy:
17:53 xstill a) vykašlat se na to
17:54 xstill b) využít znalosti o libc++ abi a pokud zdetekujeme, že jde o C++ výjimku tak simulovat unwindování, to jde samo udělat různě
17:55 xstill i. unwindovat normálně a v _Unwind_Resume nějak poznat, že toto nastalo a pokud už není hanlder tak zavolat std::terminate nějak (což vytárí cyklickou závislost mezi libunwind a libc++abi :-/)
17:56 xstill ii. unwindovat magicky tak, že __cxa_throw a _Unwind_RaiseException zůstanou navrchu/odložený a unwindovat se bude "pod nimi" a nakonec _Unwind_RaiseException vrátí do __cxa_throw které bude v tu chvíli už jediné na rámci
17:58 xstill to poslední je asi nejsložitější ale nejrobustnější, byď to předpokládá schopnost poznat, že jedeme na C++ výjimkách (což se ale dá, unwinder k tomu má exception class)
17:58 xstill a teda vyžaduje to úplně překopat __dios_unwind tak aby byl schopnej unwindovat jinej stack než na kterým jede
18:00 xstill dobrá správa je, že v _Unwind_Exception je 2x uintptr_t místa které se dá využít pro cokoli (protože klasickej unwinder si tam drží nějaký doplňující informace který mi ale nepotřebujeme)
18:00 xstill (teda vlastně forced unwind možná někdy potřebovat budeme, ale pořád nám tam zbývá 1 uintptr_t)
18:07 xstill další co je potřeba zvážit je, že pokud do unwinderu dáme __vm_choose tak si dost kompilikujeme nativní protipříklady, leda bychom si chtěli napsat vlastní nativní unwinder :-/ To je teda zatím jediná nevýhodna posledního postupu na kterou jsem přišel (kromě složitosti)
18:12 xstill nehledě na to, že nám vzniká stack s dírou a dokonce se ten stack může i rozvětvit (a nejspíš bude, pokud se destruktory nezainlinují)
18:32 evenfall xstill: no, ale _Unwind_RaiseException se musí umět vrátit aj z prostředka phase2
18:32 evenfall xstill: takže na tom, že se __cxa_throw přeskočí mi nic magickýho nepřipadá
18:33 evenfall If the unwinder encounters an unexpected error during phase 2, it should return _URC_FATAL_PHASE2_ERROR to its caller. In C++, this will usually be __cxa_throw, which will call terminate(). <b>NOTE</b>: The unwind runtime will likely have modified the stack (e.g. popped frames from it) or register context, or landing pad code may have corrupted them. As a result, the the caller of _Unwind_RaiseException can
18:33 evenfall make no assumptions about the state of its stack or registers.
18:35 evenfall tzn. případ kdy není cleanup handler a chceme i tak unwindovat zhruba odpovídá situaci, kdy toplevel fce v zásobníku handler má, a ten handler třeba zavolá resume, nebo něco podobnýho co se chápe jako chyba fáze 2
18:37 evenfall (ok, beru zpět volání resume, ale určitě lze nějakou 'vhodnou' phase2 chybu vymyslet)
18:38 evenfall (třeba že personality pochroumá zásobník a ten handler kterej našla už neexistuje...)
18:40 evenfall xstill: ještě teda jiná věc, máš nějak provozuschopný divine ~3.3? asi bych chtěl do článku o VM zařadit nějakou malou demonstraci že to není (moc) regrese ve výkonu
18:40 evenfall a k tomu by se hodilo pustit divine 3 a 4 na pár stejných programech
18:40 evenfall (bez taustores, které do té doby v divine 4 nebudou)
18:41 evenfall (tzn. nemusí nás ani moc bolet, že v divine 3.3 jsou ne úplně dobře)
18:46 xstill jo phase2 chyba může nastat kdyby personality dělala problémy (kdyby se rozbil zásobník). U nás teď unwinder unwinduje až když dokončí phase2 hledání (což nutne nemusí tak dělat, on to může unwindovat mezitím nějak magicky)
18:46 xstill mornfall: divine 3.3 asi umím zařídit
18:48 xstill mornfall: /home/xstill/DiVinE/next, v _build je buld co minimálně na pythia01 zdá se funguje, takže by měl jet i na arke
18:48 evenfall xstill: no, já tim nemyslim, že bychom to měli dělat takhle, jen že ta specifikace víceméně vyžaduje možnost vrátit se do callera _Unwind_RaiseException i potom co se něco s tím zásobníkem provedlo
18:48 xstill je to +- poslední verze co jsem měl
18:49 xstill hm, to asi vyžaduje
18:49 evenfall to by teda znamenalo, že rámec toho __cxa_throw by se měl likvidovat jako poslední
18:50 evenfall a protože personality je technicky mimo kontrolu unwinderu, tak to teoreticky dokonce i může zmastit
18:50 xstill OK, tak já zítra překopu __dios_unwind
18:54 evenfall pro native runtime by to taky nemusela být až taková rána
18:57 evenfall já už nevim, dostal to nakonec spito na starost?
19:06 xstill taky nevím
21:06 yaqwsx joined #divine
23:42 divine-buildbot joined #divine

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