On 2017-01-29 at 4:07 Kevin Klues wrote: > Nice. Or not so nice. Good to know.
even more fun! it turns out my fix wasn't right. the attempt was to see if we ran the init functions already, and if so, not run them again. the problem was that it's always a bad idea to let the shared library run the ctors. the reason is the shared library has its own data structures - its own copies of __in_vcore_context, 2LS_ops, etc. and it tells the kernel to use its vcore_entry function! so at runtime, there'd be two sets of parlib running. when the kernel put a vcore into vcore context, it'd use the one from libelf. when the app entered vcore context (e.g. uthread_yield), it'd use the binary's version. and if you used a 2LS other than thread0, those versions of parlib would disagree. madness ensues. the fix, so far, is to detect when we're in a version of parlib that isn't the actual program binary and bail out. this isn't too hard - we can make a weak alias for _start, and see if it was overridden or not. all real programs have _start, but shared objects don't. and this has the benefit of meaning we don't need to worry about rebuilding shared objects when parlib changes. barret -- You received this message because you are subscribed to the Google Groups "Akaros" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. For more options, visit https://groups.google.com/d/optout.
