public inbox for libc-ports@sourceware.org
 help / color / mirror / Atom feed
* [MIPS/all] FP and SIMD register handling around ld.so entry points
@ 2014-02-12 12:00 Matthew Fortune
  2014-02-12 14:06 ` Joseph S. Myers
  0 siblings, 1 reply; 2+ messages in thread
From: Matthew Fortune @ 2014-02-12 12:00 UTC (permalink / raw)
  To: libc-ports; +Cc: Joseph Myers (joseph@codesourcery.com), Paul Burton

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

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2014-02-12 14:06 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-02-12 12:00 [MIPS/all] FP and SIMD register handling around ld.so entry points Matthew Fortune
2014-02-12 14:06 ` Joseph S. Myers

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).