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. -- Joseph S. Myers joseph@xxxxxxxxxxxxxxxx -- 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
