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: [PATCH 5/6] Refactor hp-timing rtld usage

On 15/02/2019 10:51, Florian Weimer wrote:
> * Wilco Dijkstra:
>> Hi Florian,
>>>> You need something to compile without timer support without unused
>>>> variable errors.
>>> I assumed we would get generic timer support?
>> The generic timer code calls __clock_gettime which requires VDSO
>> to be setup, so I don't believe it is safe to call it from rtld.
> It would be safe to call if we provide a definition of __clock_gettime
> which uses the system call, which gets then interposed by the libc
> definition (potentially using the vDSO) after full relocation.  So it
> would just turn into a matter of performance then.  (I assume the time
> scales of the vDSO and non-vDSO version of the system call are
> compatible.)
> Thanks,
> Florian
The INLINE_VSYSCALL check the __vdso_* symbol value, demangles it,
and call the vDSO, otherwise it issues the syscall. We will need to either
add stub symbol on rtld that will overwritten after reallocation, or
just use syscall regardless for architectures without hp-timing support.  

The time profiling also is always enabled assuming hp-timing is cheap.
Using syscalls will incur in extra overhead on loading time. We can 
conditionality issue the profiling by DL_DEBUG_STATISTICS, but it will 
either add overhead on hp-timing architectures or add more code complexity 
(for the case of the profiling conditional is just checked for non 
hp-timing architectures).

The code is already convoluted for profiling and trying to use clock_gettime
syscall will add more complexity. Do we really need this functionality?

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