On Wed, May 07, 2008 at 01:13:20PM +0000, Joseph S. Myers wrote:
On Wed, 7 May 2008, Richard Zidlicky wrote:
As of the locking instructions that the codlfire does not provide, would
it be more straghtforward to use a new relocation type that would either
patch the 680x0 insn inline or a subroutine call?
Anything like that (static linker modifying instructions for different
processors) is *less* straightforward. That sounds like it's purely an
optimization for binaries built for the intersection of m68k and ColdFire
(a hypothetical possibility with no compiler or glibc support at present)
if you want to build a static library for both and select one at link
time. The ABI allows for the possibility of this intersection, but any
work to implement it (including defining such static-link optimizations if
desired) would need to be done by those who care for it. As the ABI says,
"If glibc is configured for a subset of processors where the necessary
operations do not require a kernel helper, then it does not need to use
the kernel helper" and making glibc use different sequences on different
processors is simpler than making the linker do so (glibc already knows
how to use cas instructions on m68k) - especially when there may be
special cases to handle in the dynamic linker when glibc is starting up
and the vDSO may not yet be available.
thanks for the clarification, seems like the best solution.
Did you already decide how to do the details of TLS handling and context
switches?
Richard
--
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html