Re: New executable format (was mem.h)

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

Hi Julian!

On Thu, Jun 11, 1998 at 11:02:27AM +0200, Julian Reschke-FJR010 wrote:
> 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.

100 % compatible.

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

No.  Notice that this member is called `g_syms'.  The member `e_syms'
following below is the length of the actual symbol table (by standard
a.out means) whereas this member reports the length of the symbol
table /plus/ the length of the string table to GEMDOS.  Since the
OS doesn't (or at least shouldn't?) care about symbol tables and
their internal format I don't see a problem.

MiNT doesn't complain about the new format but I have to admit that
I didn't test it with plain TOS.

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

I think this is the most important change.  Does this break
anything?

> >   bfd_byte e_info[4];           /* Machine type and magic number.  */
> 
> Purpose?

I want to inherit as much code as possible from the standard a.out
stuff.  And a.out implementations expect this member.

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

How do I write an `empty' symbol table?  Anyway, I think it is
impossible to avoid all possible crashes.  But as far as I can
see it only programs that are typically used by an experienced
user may crash (in fact I have tested various disassemblers and
other binary tools that produce more or less nonsense with the
new format but they don't bomb).

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

So does my `strip'.  But this extra effort won't be necessary
any longer.

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

I would appreciate that.

Julian, could you explain me what the linker would have to do
to support that MagiC feature (stack space reserved in bss)?

Ciao

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