Update on m68k target maintenance

[msokolov at ivan dot Harhan dot ORG (Michael Sokolov)]

Binutils developers and users,

Here's an update on my work to bring the m68k target back into active
maintenance. This week I've pushed out a software release I had sitting on my
to-do list for a long time (a specialised toolchain for the PalmOS handheld
embedded system, using the Cygnus tree with a hacked gcc version and some extra
bits), and now I can get back to my main focus of expanding the m68k target
support in the mainline toolchain. (Thanks a lot Nick for the m68k ELF/SVR4 ABI
spec!)

This July I added the --embedded-relocs option to ld for m68k COFF that
generates a loadable section in the program image containing information that
an embedded PIC system can use to relocate its own data section at run time.
This is modeled after the --embedded-relocs option in MIPS ECOFF ld invented by
Ian several years ago. There is a small buglet in it actually the patch for
which will follow momentarily, but otherwise it has been working well. When I
first implemented it for m68k COFF, I promised to implement it for m68k ELF as
well right after that. Well, I got too carried away on other projects in the
past month and a half, but I'll do it now.

I will also be revamping relaxation on m68k. I will be adding some additional
relaxation possibilities for CPUs without long branches and displacements, as
well as linker relaxation that works across module boundaries for m68k ELF.

Finally, I'm addressing the issue of segmented memory architectures. While m68k
is a sane architecture with a flat virtual address space, not like Intel 80x86,
some environments define a segmented memory architecture for programs. They
divide programs into many segments and use fancy addressing and linkage between
them. MacOS and PalmOS are examples of such systems. They need special linker
processing to separate intrasegment references from intersegment ones, change
jump or other instructions accordingly, and build jump tables or segment
linkage tables of some sort. This inherently requires system-specific
processing in the BFD linker. Fortunately, there aren't too many such systems
(MacOS and PalmOS are the only ones I know of, and I hope there won't be more).
The hacks to support them will be as orthogonal as possible to the standard
ABI-compliant Binutils operation, and in this standard ABI-compliant operation
they will be completely inactive and have zero effect.

In the current m68k target support there is an almost perfect orthogonality
between the object format chosen, the CPU type, and the PIC style used. I will
strive to keep it this way. I will add several new features to be usable
wherever they make sense, as opposed to creating one single contrived
configuration with no flexibility. In particular, the new relaxation
possibilities for 68000 will be available regardless of what object format is
used or whether linker relaxation is enabled, except of course that without the
latter relaxation cannot work across module boundaries. This is also why I'll
be porting my m68k COFF embedded relocs feature to m68k ELF, to avoid making
the user choose between this and other useful embedded systems features (which
traditionally have all been COFF) and the features of ELF. The only exception
is that linker relaxation will only be available with ELF, but that is only
because ELF is the only object format for which it can be done cleanly.

m68k users, stay tuned!

--
Michael Sokolov		Harhan Engineering Laboratory
Public Service Agent	International Free Computing Task Force
			International Engineering and Science Task Force
			615 N GOOD LATIMER EXPY STE #4
			DALLAS TX 75204-5852 USA

Phone: +1-214-824-7693 (Harhan Eng Lab office)
E-mail: msokolov@ivan.Harhan.ORG (ARPA TCP/SMTP) (UUCP coming soon)