On Wed, Aug 15, 2018 at 9:41 PM, Waldek Kozaczuk <jwkozac...@gmail.com> wrote:
> I hacked elf.cc to print missing symbols instead of aborting and here is a > list I got: > Beyond providing us with a valuable list of functions we should, eventually, implement (would be nice to enter them into a bug tracker issue or issues), your technique gave me another idea - Why do we have to abort when resolution fails? Clearly, when the resolution is done just before executing a function, there is no way to fail cleanly and an abort makes sense. But, with resolution during boot - the bind_now case in object::relocate_pltgot() failing to resolve a symbol should be (perhaps) a warning, but not an abort! We can leave the symbol unresolved (what is today the "else" case), and the lookup will be tried again - and abort - when the function is actually called. If it ever actually called. If we do this, we won't need to implement or stub a couple of dozen obscure library functions and can delay that for another day. What do you think? > /usr/lib/libpython3.6m.so.1.0: failed looking up symbol sched_getscheduler > /usr/lib/libpython3.6m.so.1.0: failed looking up symbol flistxattr > /usr/lib/libpython3.6m.so.1.0: failed looking up symbol unlinkat > /usr/lib/libpython3.6m.so.1.0: failed looking up symbol __wcscat_chk > /usr/lib/libpython3.6m.so.1.0: failed looking up symbol fsetxattr > /usr/lib/libpython3.6m.so.1.0: failed looking up symbol llistxattr > /usr/lib/libpython3.6m.so.1.0: failed looking up symbol fremovexattr > /usr/lib/libpython3.6m.so.1.0: failed looking up symbol lgetxattr > /usr/lib/libpython3.6m.so.1.0: failed looking up symbol listxattr > /usr/lib/libpython3.6m.so.1.0: failed looking up symbol sched_getparam > /usr/lib/libpython3.6m.so.1.0: failed looking up symbol sched_setscheduler > /usr/lib/libpython3.6m.so.1.0: failed looking up symbol sigtimedwait > /usr/lib/libpython3.6m.so.1.0: failed looking up symbol readlinkat > /usr/lib/libpython3.6m.so.1.0: failed looking up symbol fexecve > /usr/lib/libpython3.6m.so.1.0: failed looking up symbol mkdirat > /usr/lib/libpython3.6m.so.1.0: failed looking up symbol __wcsncpy_chk > /usr/lib/libpython3.6m.so.1.0: failed looking up symbol lsetxattr > /usr/lib/libpython3.6m.so.1.0: failed looking up symbol clock_settime > /usr/lib/libpython3.6m.so.1.0: failed looking up symbol fgetxattr > /usr/lib/libpython3.6m.so.1.0: failed looking up symbol > sched_rr_get_interval > /usr/lib/libpython3.6m.so.1.0: failed looking up symbol __xmknodat > /usr/lib/libpython3.6m.so.1.0: failed looking up symbol linkat > /usr/lib/libpython3.6m.so.1.0: failed looking up symbol removexattr > /usr/lib/libpython3.6m.so.1.0: failed looking up symbol getgrouplist > /usr/lib/libpython3.6m.so.1.0: failed looking up symbol sigpending > /usr/lib/libpython3.6m.so.1.0: failed looking up symbol sched_setparam > /usr/lib/libpython3.6m.so.1.0: failed looking up symbol fchownat > /usr/lib/libpython3.6m.so.1.0: failed looking up symbol getxattr > /usr/lib/libpython3.6m.so.1.0: failed looking up symbol renameat > /usr/lib/libpython3.6m.so.1.0: failed looking up symbol setxattr > /usr/lib/libpython3.6m.so.1.0: failed looking up symbol symlinkat > /usr/lib/libpython3.6m.so.1.0: failed looking up symbol waitid > /usr/lib/libpython3.6m.so.1.0: failed looking up symbol lremovexattr > > Even though these symbols are not used by Python when running the examples > from apps/python3x/README, they get resolved because Python from Fedora > distribution is > compiled to trigger eager symbols resolution (aka BIND_NOW). > > Python from Ubuntu does NOT have those problems (because symbols are > resolved lazily) all 3 example work fine with Python 3. > > We probably need to add stubs for these symbols. > > -- > You received this message because you are subscribed to the Google Groups > "OSv Development" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to osv-dev+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "OSv Development" group. To unsubscribe from this group and stop receiving emails from it, send an email to osv-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
