You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Issue #821 describes a new OSv kernel which was run with an image missing libvdso.so, and prepare_argv() (called when running an application) aborts.
I think we should gracefully handle this case. If libvdso.so is missing, a minor feature is missing (the AT_SYSINFO_EHDR auxv setting), it's not a reason to crash immediately. I think at worst perhaps we should debug() a message?
Looking at this code also made me wonder about why we need to open a separate copy of libvso.so for each application. Unlike libenviron.so whose entire raison d'etre was to be separate for separate ELF namespace, I think (but please correct me if I'm wrong), libvdso.so could have been loaded once and reused. However, I think this is of minor importance - the savings would be minimal.
The text was updated successfully, but these errors were encountered:
I was trying to prepare a patch for this and noticed that when some programs run to create image - /tools/mkfs.so, /tools/cpiod.so, /zfs.so - file system is not present yet or mounted how come loading vdso "succeeds":
_libvdso = program->get_library("libvdso.so");
if (!_libvdso) {
abort("could not load libvdso.so\n");
}
I noticed that program::load_object() returns some kind of stub (end of the method):
} else {
printf("==> [%03d] program::load_object() returned STUB for %s!\n", sched::thread::current()->id(), name.c_str());
return std::shared_ptr<object>();
}
but that does not seem to happen for libvdso.so.
Also if we wanted to load vdso once should we try it eagerly earlier than prepare_args()? I assume we would want to make _libvdso a static member of the application class.
Regarding my last comment I realized that libvdso along with many other shared libraries is added to loader.elf as part of bootfs.manifest (look at bootfs.S). Therefore kernel is able to load libvdso when executing zpool.so or mkfs.so apps because there is only ramfs (aka bootfs) filesystem mounted.
This also means that many libraries from usr.manifest.skel are actually duplicated in loader.elf. But that is subject for another discussion.
Issue #821 describes a new OSv kernel which was run with an image missing libvdso.so, and prepare_argv() (called when running an application) aborts.
I think we should gracefully handle this case. If libvdso.so is missing, a minor feature is missing (the AT_SYSINFO_EHDR auxv setting), it's not a reason to crash immediately. I think at worst perhaps we should debug() a message?
Looking at this code also made me wonder about why we need to open a separate copy of libvso.so for each application. Unlike libenviron.so whose entire raison d'etre was to be separate for separate ELF namespace, I think (but please correct me if I'm wrong), libvdso.so could have been loaded once and reused. However, I think this is of minor importance - the savings would be minimal.
The text was updated successfully, but these errors were encountered: