New executable format (was mem.h)

[Guido Flohr <gufl0000@stud.uni-sb.de>]

On Wed, Jun 03, 1998 at 07:21:20PM +0200, Michael Schwingen wrote:
> This would require 1-2 bits in the program header, with the default value
> (as on old programs) meaning 'full cache speed', so that you only have to
> twiddle with these bits for bad programs.
> 
> Does this sound reasonable? Are there still unused bits left?

I'm working on a port of the binutils 2.9.1.  If I ever manage to handle
the remaining problems the new linker will produce executables in a
slightly different format (which should be 100 % backward compatible):

struct gemdos_external_exec {
  bfd_byte g_magic[2];		/* Always 0x601a.  */
  bfd_byte g_text[4];		/* Length of text segment (as seen by
                                   GEMDOS).  */
  bfd_byte e_data[4];		/* Length of data segment.  */
  bfd_byte e_bss[4];		/* Length of bss segment.  */
  bfd_byte g_syms[4];		/* Length of symbol table  (including
                                   the string table!)  */
#define MINT_MAGIC 0x4d694e54 /* "MiNT".  */
  bfd_byte g_mintmagic[4];	/* `Reserved for future use'.  We use this
                                 * member now for our own purposes.  If
                                 * it is MINT_MAGIC then we have an extended
                                 * executable format.
                                 */
#define MINT_DEFAULT_FLAGS F_FASTLOAD | F_ALTLOAD | F_ALTALLOC
  bfd_byte g_flags[4];		/* Program flags.  */
  bfd_byte g_dont_reloc[2];	/* Zero if relocation info present.  */
  
  /* This next two members happen to represent a branch instruction to
   * the beginning of the actual code.
   */
  bfd_byte g_branch[2];		/* Always 0x6000.  */
  bfd_byte g_skip[2];        	/* sizeof (struct gexec) - 28 - 2.  */
#define MINT_MAGIC_STRING "extended MiNT executable format"
  bfd_byte g_moremagic[32];  
  bfd_byte g_header[4];		/* Size of entire header.  */
  
  bfd_byte e_info[4];		/* Machine type and magic number.  */
  bfd_byte e_text[4];           /* Size of text segment as seen by
                                 * binutils.
                                 */
  bfd_byte e_syms[4];
  bfd_byte e_entry[4];
  bfd_byte e_trsize[4];       	/* Text relocation info.  Not standard!  */
  bfd_byte e_drsize[4];		/* Data relocation info.  Not standard!  */
  bfd_byte g_stacksize[4];	/* Size of stack following MiNTLib
                                 * conventions:
                                 */
  bfd_byte g_stackaddr[4];      /* This is the offset into the file on
                                 * disk where the stacksize can be found.
                                 */
  bfd_byte g_reserved[156];
};

Some notes on this:  The first 28 bytes are identical to the traditional
GEMDOS executable header except for the use of the formerly reserved
field at offset 18 (0x12).  It doesn't seem to be a problem to use this
field but it is actually not necessary.  The simple advantage is to
allow programs to decide on the actual format after reading only 28
bytes.  But there is enough magic following.  If some OS or emulator
has problems with this I can drop it.

If you are familiar with the (almost standard) a.out format for
other Unixes you will recognize that this new format is a weird 
mixture of a.out and old-style GEMDOS.  This makes it quite easy
to take over code written to handle a.out binaries (like the
GNU binutils) without too much trouble.  My goal is to make
the binutils `configure && make install' stuff.

Note that the symbol table included in these files will be in
the GNU format (because it is typically shorter than the DRI
format and it is understood by the GNU debugger).  Hopefully
all binutils (nm, size, objdump, ...) will finally work on
executables too.  The hard thing will probably be the debugger.
I hope that there will be no more need for a symbolic linker
and these .sym files.  Programs that rely too much on a
specific format of the symbol table 

Another advantage:  The stacksize (and the location of the
corresponding variable on disk) is written into the header.
The symbol table may be stripped entirely without losing
the possibility to change the stacksize.

You see that this header has currently room for another
156 bytes (or 1248 bits).  Maybe we can discuss their use
here.

Ciao

Guido
-- 
http://stud.uni-sb.de/~gufl0000
mailto:gufl0000@stud.uni-sb.de