[MIPS/all] FP and SIMD register handling around ld.so entry points

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

[MIPS/all] FP and SIMD register handling around ld.so entry points

Matthew Fortune
I'm currently looking into potential problems with ld.so and caller save argument registers that may be live on entry to ld.so.

Joseph pointed me towards the following thread which discusses this issue in depth:
https://sourceware.org/ml/libc-alpha/2014-01/msg00673.html

I generally agree that there is currently risk for a number of ports, MIPS included, that the current approach of ignoring all but integer argument registers is increasingly unsafe with features such as ifunc becoming more widely used. As soon as ld.so allows user code to be called as part of symbol resolution then the hope that floating point argument registers and/or SIMD argument registers will not be clobbered becomes increasingly unrealistic. A similar effect occurs when introducing highly optimised code into ld.so for such things as memcpy which may then clobber SIMD registers. While things like memcpy could be crafted to avoid clobbering any caller save SIMD argument registers this is an unintuitive restriction to require.

To solve this we need to change the ld.so entry points to preserve any caller save register that may be involved in argument passing around ld.so entry points. The thread above points out that since there can be ABI extensions that are dependent on hardware features then the set of registers that need saving may depend on the current hw capabilities. This is ugly but the cost is likely to be minimal in comparison to the real work done inside ld.so.

I do however have one problem with just changing to save all argument registers. If ld.so preserves floating point argument registers then we will trigger the inclusion of floating point register state in a process's context. The same applies to SIMD register state. It seems unwise to force all processes to have this state context switched when they may well have only hit it as part of dynamic linking! Lazy context save/restore reduces the cost of switching extended register state that is unused (except for ld.so) because the state would only get switched when next entering ld.so. We cannot just check to see if the FP unit/SIMD unit is enabled at the point of entering ld.so as it may be inactive as part of a lazy context mechanism and there could be live state waiting to be restored by the kernel.

Ideally we need a way to avoid preserving extended registers (FP/SIMD) unless the current process has already got it included in its context. Any ideas for this?

Matthew

--

Matthew Fortune
Leading Software Design Engineer, MIPS processor IP
Imagination Technologies Limited
t: +44 (0)113 242 9814
www.imgtec.com

Reply | Threaded
Open this post in threaded view
|

Re: [MIPS/all] FP and SIMD register handling around ld.so entry points

Joseph Myers
Please resend your message to libc-alpha.  MIPS has moved out of ports;
libc-ports should only be used for things specific to alpha / hppa / ia64
/ microblaze until they too have moved out of ports.

--
Joseph S. Myers
[hidden email]