Sorry for the late reply. These are some debug statements I captured:

void* align(void* addr, ulong align, ulong offset)
{
    return align_up(addr - offset, align) + offset;
}

}

void object::set_base(void* base)
{
    auto p = std::min_element(_phdrs.begin(), _phdrs.end(),
                              [](Elf64_Phdr a, Elf64_Phdr b)
                                  { return a.p_type == PT_LOAD
                                        && a.p_vaddr < b.p_vaddr; });
    _base = align(base, p->p_align, p->p_vaddr & (p->p_align - 1)) - 
p->p_vaddr;
    debugf("***set_base-> _base is: 0x%016lx\n", _base );
    debugf("***set_base-> addr is:  0x%016lx, align: 0x%016lx, offset: 
0x%016lx, p_vaddr: 0x%016lx\n",
           base,
           p->p_align,
           p->p_vaddr & (p->p_align - 1),
           p->p_vaddr);
    auto q = std::min_element(_phdrs.begin(), _phdrs.end(),
                              [](Elf64_Phdr a, Elf64_Phdr b)
                                  { return a.p_type == PT_LOAD
                                        && a.p_vaddr > b.p_vaddr; });
    _end = _base + q->p_vaddr + q->p_memsz;
}

void* object::base() const
{
    return _base;
}


for _core:

Firmware vendor: SeaBIOS
***set_base-> _base is: 0x0000000000000000
***set_base-> addr is:  0x0000000000200000, align: 0x0000000000200000, 
offset: 0x0000000000000000, p_vaddr: 0x0000000000200000

So indeed the kernel base is set to 0x0000000000000000 even thought the 
passed in parameter base (value of ELF_IMAGE_START) is 0x0000000000200000.

Is this a bug then?

Waldek

On Sunday, February 18, 2018 at 11:10:01 AM UTC-5, Nadav Har'El wrote:
>
>
> On Thu, Feb 15, 2018 at 12:01 AM, Waldek Kozaczuk <jwkoz...@gmail.com 
> <javascript:>> 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+u...@googlegroups.com <javascript:>.
>> 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.

Reply via email to