Re: New executable format (was mem.h)

[Julian Reschke-FJR010 <Julian_Reschke-FJR010@email.mot.com>]

gufl0000@stud.uni-sb.de%INTERNET wrote:

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

As a general statement: if it doesn't break anything (like the ability
to run these binaries without MiNT), there shouldn't be a problem.
 
> 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!)  */

Hmm. If the string table (string constants?) is part of the symbol
table, it won't be loaded by GEMDOS...

> #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.  */

Purpose?

>   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

Please make sure that this symbol table is prefixed by an "empty"
DR type symbol table so that existing tools do not panic.

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

My "strip.ttp" from the programming utilities archive already
skips that symbol if not told explicitly otherwise...

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

If you are serious with this and the "MiNT" magic in the original
header will be used, we should document the "reserved word" in
the MiNT header files (like: 4 byte magic word describing type
of extended program header).

Regards, jr