On Thu, Feb 15, 2018 at 12:01 AM, Waldek Kozaczuk <jwkozac...@gmail.com> wrote:
> I have bee trying to prepare new patch to add libvdso support needed by > golang based on the work of @benoit. I came across this discussion here > https://groups.google.com/forum/#!searchin/osv-dev/Delay$20elf$20object$ > 20initialization%7Csort:date/osv-dev/DOJ23sMsZuY/EgryjmqqCQAJ (look for "vdso > fast syscall compatibility library" subthread). > > The original patch prepared by Benoit add libvdso as a separate shared > library whose base address gets passed to auxv as needed by Golang. Nadav > argued in this thread that instead libvdso could be part of kernel and > kernel base can be used instead (unless I misunderstood the conversation). > That is more or less what I *hoped* we can do, hoping we don't need yet another ".so" which just adds more mess to the build and the image (it's not *that* horrible, but if we could live without it, wouldn't it be even better?). > > To have better understanding I captured the based address of kernel by > adding debug statement like so in application::prepare_argv() - > https://github.com/benoit-canet/osv/blob/go4/core/app.cc#L298-L359: > > debug("***$$$$$ lbbvdso address: %#x\n", _libvdso->base()); > auto _libxenstore = program->get_library("libxenstore.so.3.0"); > if( _libxenstore) { > debug("***$$$$$ libxenstore address: %#x\n", _libxenstore->base()); > } > > > libxenstore.so.3.0 is one of the "virtual" libraries that is resolvable > as part of kernel (look at supplied_modules in program constructor). So if > we added libvdso.so same way as libxenstore.so.3.0 we would pass its base > address to auxv. > > Here is the output I am getting: > > ***$$$$$ lbbvdso address: 0x100000000000 > ***$$$$$ libxenstore address: 0 > > For whatever reason the base address of any library provided by OSv kernel > would be 0. Do we know why base address returned here is 0 instead of > expected 0x200000? > core/elf.cc creates _core as: _core = std::make_shared<memory_image>(*this, (void*)ELF_IMAGE_START); // ELF_IMAGE_START is 0x200000 memory_image is an elf::object and calls set_base on this ELF_IMAGE_START, and object::base() is supposed to return it. As you can see in program::program(), loading _files["libxenstore.so.3.0"] is set to _core, so we should get _core, with its base() == 0x200000 So I don't understand how we're seeing base==0. Maybe you can add various printouts to debug how this is happening? Maybe object::set_base() is doing this? It seems not to just take "base" at face value, but do all sort of computations on it. Maybe these computations are for some reason wrong for the kernel? Or maybe they are right, and the kernel should have "_base = 0" and I just don't understand why? > > Here is the Golang portion of code with the guard that Benoit is referring > - https://github.com/golang/go/blob/master/src/runtime/ > vdso_linux.go#L269-L273 > > case _AT_SYSINFO_EHDR: > if val == 0 { > // Something went wrong > return > } > > > > > > > So clearly we cannot pass 0 as base address? So I wonder of there is some > bug where base address of supplied modules is returned as 0 or indeed it is > zero instead of 0x200000 and then the only choice we have is to have it a > separate library. > > Am I missing something? > > Waldek > > -- > 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.
