ld --embedded-relocs for m68k

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

Hi there,

OK, I'm proceeding with the port of MIPS ECOFF ld --embedded-relocs to m68k
COFF and ELF. I would appreciate it if Ian as the author of the original MIPS
code could comment on this.

The MIPS ECOFF ld scans the .sdata section for 32-bit absolute address relocs
and writes embedded reloc records in the .rel.sdata section it creates for
them. It does not allow relocs in any other data sections. This is the same
behavior I need for m68k (others can have other needs, but we don't know them,
and at least I'm doing exactly the same thing that's already done for MIPS).
The only difference is that the data section is plain .data instead of .sdata.

However, I have reservations about naming the embedded reloc section .rel.sdata
or .rel.data. This name is good for neither COFF nor ELF. For COFF it's over 8
characters, and .prefixSECNAME is not normal for COFF in the first place. For
ELF .relSECNAME is already taken up by normal relocs. Also if at all possible
I'd like to make this section the same for COFF and ELF to make life easier
when linking them together. Since there is only one data section for which
embedded relocs are generated, we don't really need the .prefixSECNAME form. I
propose calling this section .emreloc for m68k, both COFF and ELF. (Of course I
won't change it for MIPS unless you tell me to.)

Now the embedded reloc records themselves. For MIPS each record contains the
location in the data section of the reloc and the indication of whether the
reloc is targeting a text section or a data section, so that the run-time reloc
processor can process it as text-relative or data-relative. What I need for
m68k (again, others may need something else, but we don't know it, and at least
it's as close as possible to the existing MIPS code) is almost the same with
only one difference. The difference is that I need not just a two-state
indicator of text vs. data, but an indication of the specific target section.
The system I'm working with has an unlimited number of text sections all
starting at VMA 0 in the image, which end up being loaded at unpredictable
addresses, each independently, and the runtime reloc processor needs to
distinguish between them.

I can't think of a really good way of representing this target section
indication in the embedded reloc records. John Marshall's solution (which I
won't further elaborate on, if John believes that his approach and patch are
right for mainline binutils and he wants his patch checked in, he would have to
argue for it himself, I can't do it for him) was to store the section index of
the target section in the executable in there. This is convenient when the
embedded reloc section is being ripped by a special post-linker program linked
with BFD, which is actually the case for his PalmOS environment, but doesn't
make much sense when it's burned into ROM for processing on the embedded
system. My PalmOS environment also uses the same post-linker trick as John's,
so this approach would work for it too. However, unlike John I'm a little more
concerned about binutils in general, rather than my specific need at the
present time.

Was the MIPS --embedded-relocs support intended to be general, or was it a
solution for some specific oddball embedded system? It's there for the standard
MIPS ECOFF configuration, no special configuration triplet, so I would hope
it's general. As I was thinking about making the m68k one the same way, i.e.,
no special configuration triplet, a standard m68k feature, it better be general
too. The MIPS --embedded-relocs support appears fit for a traditional "bare
board" embedded system, and m68k is also very common on bare board systems. OK,
bare boards with ROMs don't usually need PIC, but some may. High-end DEC VAXen,
for example, have a slave processor on almost every board. A lot of them are
68000s and 68020s. (Also T-11, 80186, 8051, etc.) Almost all DEC slave
processors have hackable firmware, and firmware hacks could presumably need
embedded PIC. In short, I think for mainline binutils a generic solution that
can support a wide range of reasonable embedded systems plus PalmOS post-linker
tricks would be better than one that supports just the post-linker trick.

The problem is, can we find such a solution? I can't think of any better way of
encoding the target section indication than the section index. If no one can
think of anything better, the section index would work for me, if the
maintainers are willing to check in such a kludge, even for the lack of
anything better. :-(

--
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)