Re: New executable format (was mem.h)

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

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

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

Sorry, I was thinking of the relocation table format.

Anyway, it probably wouldn't hurt to start the symbol table with a
symbol name like "".


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

Basically the process must be happy with the fact that the TPA
ends directly behind the BSS. Which means that the stack needs to
be the last element *in* the BSS.

Regards, jr