Home Original page

ld --embedded-relocs for m68k

Michael Sokolov msokolov@ivan.Harhan.ORG
Thu Jun 8 14:44:00 GMT 2000 
Ian Lance Taylor <ian@zembu.com> wrote:

> The problem with using a section index is that it implies that you
> need a section table.  Think about converting a program to S-records.
> Whatever table you use must be recorded in the program image somehow.

That's exactly what I was saying: section indexes are meaningful when the COFF
or ELF image is being tinkered with on the host system, not when the sections
have been ripped out and S-recorded into the target system. It was simply the
case that PalmOS (the system that John Marshall wrote his patch for and *one*
of the many systems I'm interested in) does the former. For mainline binutils
the latter is much more common, but we should support both.

> For MIPS --embedded-relocs I split up text and data, and required the
> linker script and the startup code to work in tandem to record that
> information for proper relocation at run time.  See
> ld/testsuite/ld-empic/runtesti.s.

Oh, the PalmOS linker script and startup code are saturated with magic too. :-)
In fact for PalmOS there is one more component: the post-linker, a host tool
that takes the "executable" produced by the linker and turns it into a bunch of
files to be loaded on the embedded system. PalmOS is a diskless system that
uses memory as persistent storage, and has an in-memory filesystem of sorts, in
which the so-called resources play the role of files and the role of the file
name is played by the resource type and number. What is logically a single
program entity produced in one link is stored in multiple resources, the
closest UNIX equivalent of that would be a system that required each executable
to be a directory with several files in it. The role of the post-linker is
similar to objcopy, except that all resource files are produced on output at
once (it can't be done in any other way). As you've probably guessed already,
each text section in the COFF or ELF "executable" becomes a code resource.

> If you need to support multiple sections, you need a more complex
> solution.  If you need to support arbitrary numbers of sections, you
> need to write a section table somewhere, perhaps at the start of the
> relocation information.

How about storing the section name (truncated to 8 chars max) instead of the
index? I'm trying to keep the implementation within manageable complexity.

Whatever solution is chosen will be fine for PalmOS, I can always change the
post-linker to grok whatever format is chosen, I'm just trying to make it
useful for more than just PalmOS.

> But I don't know how you pass in the runtime
> addresses of the various sections.  That is bound to be system
> specific.

It is. In the case of PalmOS I know that every named section goes into a
certain named file. Each file gets loaded at an unpredictable address in the
memory filesystem, but its name stays. A system call returns the address of a
named file. (OK, to keep PalmOSers happy, not file but resource, and not name
but type and number. I'm just translating this into non-PalmOS language for
binutils.)

--
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)
More information about the Binutils mailing list