This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: ppc64 vDSO in mainline

> Yes if the has .odp entries then must avoid exporting 
> any relocations against its .opd. Either the can be bound at a 
> static address (which allows the .opd entry contents to be resolved at 
> link time). Or the kernel must perform any required relocations in the 
> vdso and must remove those relocations from ELF header before it is made 
> visible to

The vDSO doesn't have .opd and won't have. The kernel can't perform any
relocation as the vDSO will be virtually mapped at different addresses.
It is not the case now but will be once I enable randomization.

> You linked the vdso to a static address so it is the actual address. 
> Anyway the dynmaic linkers symbol resolutions should do any required 
> arthimatic. 

The vDSO is linked to 0 and mapped at 1Mb with the current
implementation. It doesn't expose OPDs so you can't call vDSO functions
from a test executable without an asm glue on ppc64. ppc32 is easier to
deal with in this regard :)

> See my comment above. I agreed to removing the .opd to get around a 
> problem in the short term. Now we are discussing design which should be 
> looking long term.

Well, it's done and in mainline, so we'll have to deal with it now. 

> Like I mentioned about there are reasons why the vdso will need the TOC 
> pointer set. Even static leaf routines can use the TOC to access large 
> constants and there is the issues of how gettimeofday accesses the magic 
> timer conversation values (which change periodically).

This has been implemented without a TOC. It's there, look at the code.
It might be possible to change that in the future, however I yet have to
figure out how to pass a TOC pointer to to put in the .opd's.
Again, these can't be fixed up by the kernel unless we give up on the
possibility to have the vDSO ever be elsewhere than a fixed address,
identical in every process.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]