* VDSO
@ 2015-08-12 10:21 Alex Smith
2015-08-12 10:21 ` VDSO Alex Smith
2015-08-12 16:14 ` VDSO David Daney
0 siblings, 2 replies; 5+ messages in thread
From: Alex Smith @ 2015-08-12 10:21 UTC (permalink / raw)
To: linux-mips
Hi,
I'm intending to start work on a proper VDSO implementation for MIPS that can provide user implementations of gettimeofday() and such, as well as take over from the current signal return trampoline code.
Just wondering if there's anyone else who's doing any work towards this so we can avoid duplication of effort if so?
Thanks,
Alex
^ permalink raw reply [flat|nested] 5+ messages in thread
* VDSO
2015-08-12 10:21 VDSO Alex Smith
@ 2015-08-12 10:21 ` Alex Smith
2015-08-12 16:14 ` VDSO David Daney
1 sibling, 0 replies; 5+ messages in thread
From: Alex Smith @ 2015-08-12 10:21 UTC (permalink / raw)
To: linux-mips
Hi,
I'm intending to start work on a proper VDSO implementation for MIPS that can provide user implementations of gettimeofday() and such, as well as take over from the current signal return trampoline code.
Just wondering if there's anyone else who's doing any work towards this so we can avoid duplication of effort if so?
Thanks,
Alex
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: VDSO
2015-08-12 10:21 VDSO Alex Smith
2015-08-12 10:21 ` VDSO Alex Smith
@ 2015-08-12 16:14 ` David Daney
2015-08-13 8:25 ` VDSO Alex Smith
1 sibling, 1 reply; 5+ messages in thread
From: David Daney @ 2015-08-12 16:14 UTC (permalink / raw)
To: Alex Smith; +Cc: linux-mips
On 08/12/2015 03:21 AM, Alex Smith wrote:
> Hi,
>
> I'm intending to start work on a proper VDSO implementation for MIPS that can provide user implementations of gettimeofday() and such, as well as take over from the current signal return trampoline code.
>
> Just wondering if there's anyone else who's doing any work towards this so we can avoid duplication of effort if so?
>
I am not working on it, but have a small laundry list of what could be done:
1) Perhaps the VA of the vdso needs to be randomized.
2) Provide proper .eh_frame data for the signal return trampolines.
3) gettimeofday (as you suggest).
4) Provide optimized versions of memcpy, etc.
David Daney
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: VDSO
2015-08-12 16:14 ` VDSO David Daney
@ 2015-08-13 8:25 ` Alex Smith
2015-08-13 8:25 ` VDSO Alex Smith
0 siblings, 1 reply; 5+ messages in thread
From: Alex Smith @ 2015-08-13 8:25 UTC (permalink / raw)
To: David Daney; +Cc: linux-mips
On 12/08/2015 17:14, David Daney wrote:
> On 08/12/2015 03:21 AM, Alex Smith wrote:
>> Hi,
>>
>> I'm intending to start work on a proper VDSO implementation for MIPS that can provide user implementations of gettimeofday() and such, as well as take over from the current signal return trampoline code.
>>
>> Just wondering if there's anyone else who's doing any work towards this so we can avoid duplication of effort if so?
>>
>
> I am not working on it, but have a small laundry list of what could be done:
>
> 1) Perhaps the VA of the vdso needs to be randomized.
>
> 2) Provide proper .eh_frame data for the signal return trampolines.
>
> 3) gettimeofday (as you suggest).
Yes, I intend to do all of these.
> 4) Provide optimized versions of memcpy, etc.
Is this something that belongs in a VDSO? memcpy and friends aren't syscalls, this belongs in libc IMO. ELF HWCAP flags provided by the kernel could be used by libc to decide which CPU features it can make use of to implement them.
Thanks,
Alex
>
> David Daney
>
>
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: VDSO
2015-08-13 8:25 ` VDSO Alex Smith
@ 2015-08-13 8:25 ` Alex Smith
0 siblings, 0 replies; 5+ messages in thread
From: Alex Smith @ 2015-08-13 8:25 UTC (permalink / raw)
To: David Daney; +Cc: linux-mips
On 12/08/2015 17:14, David Daney wrote:
> On 08/12/2015 03:21 AM, Alex Smith wrote:
>> Hi,
>>
>> I'm intending to start work on a proper VDSO implementation for MIPS that can provide user implementations of gettimeofday() and such, as well as take over from the current signal return trampoline code.
>>
>> Just wondering if there's anyone else who's doing any work towards this so we can avoid duplication of effort if so?
>>
>
> I am not working on it, but have a small laundry list of what could be done:
>
> 1) Perhaps the VA of the vdso needs to be randomized.
>
> 2) Provide proper .eh_frame data for the signal return trampolines.
>
> 3) gettimeofday (as you suggest).
Yes, I intend to do all of these.
> 4) Provide optimized versions of memcpy, etc.
Is this something that belongs in a VDSO? memcpy and friends aren't syscalls, this belongs in libc IMO. ELF HWCAP flags provided by the kernel could be used by libc to decide which CPU features it can make use of to implement them.
Thanks,
Alex
>
> David Daney
>
>
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2015-08-13 8:25 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-08-12 10:21 VDSO Alex Smith
2015-08-12 10:21 ` VDSO Alex Smith
2015-08-12 16:14 ` VDSO David Daney
2015-08-13 8:25 ` VDSO Alex Smith
2015-08-13 8:25 ` VDSO Alex Smith
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox