home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Atari FTP
/
ATARI_FTP_0693.zip
/
ATARI_FTP_0693
/
Tex
/
Tex29
/
StTeXsrc.zoo
/
etc
/
tech.notes
< prev
next >
Wrap
Text File
|
1989-09-25
|
5KB
|
103 lines
A few tech notes: stuff that may or may not be obvious from the source:
usage: undump NEWFILE OLDFILE [optional args to OLDFILE]
undump the memory image of `OLDFILE args ...' to NEWFILE
(complete path names including extensions for NEWFILE and
OLDFILES must be specified)
undump is written as a utility, which launches the process `OLDFILE [args ..]'
(after some house keeping) using Pexec(3, ...), to grab the base page addr,
followed by Pexex(4, ...) to execute (Note: the environment and the
arguments are passed to OLDFILE using the MWC conventions). When the
control returns from Pexec(4, ...) to undump, it does the following
actions: (Note: the new tos 1.4 Pexec(6, ..) *cannot* be used, because
we still want memory ownership after Pexec() returns):
- un-relocate the memory image of OLDFILE in core: by this
i mean that from all the relocatable locations of
OLDFILE (in the text or data segments) in memory, subtract the
(basepage->text_start) addr, as that was the amount it was
relocated by, when Pexec(3, ..) loaded it in memory.
The relocation table is read from the disk image of OLDFILE.
(NOTE: for the text segment we could have copied the disk image
of the text segment from OLDFILE to NEWFILE, but we instead unrelocate
and copy the text segment from the memory image. This was
done to take care of the case where the application contains
any self modifying code in the text segment (besides making it easier
to code undump, otherwise it would have to run through the relocations
skipping the reloc entries that were applicable to the text segment))
- after un-relocating the text and data segments in the memory image
of OLDFILE, dump them into NEWFILE, followed by the memory
image of OLDFILE's bss (which of course goes into the data
segment of NEWFILE). The gemdos-exec header is already
written to NEWFILE at this point, and reflects the the
following facts:
NEWFILE->text size == OLDFILE->text size
NEWFILE->data size == OLDFILE->data size + OLDFILE->bss size
NEWFILE->bss size == 0
- following this, the symbol table (if present) and the relocation
table (actually anything upto EOF, since MWC etc put stuff after
the relocation) are copied from the disk image of OLDFILE to
NEWFILE.
- undump does'nt really care how/ at what point / with what exit
status, OLDFILE returns from Pexec(4, ..) (the exit status was
ignored because several applications seem to return a garbage
exit status). The usual (for unix atleast) way to exit OLDFILE
in the undumping procedure is to hit the quit character
(normally Control-\) at a prompt. TOS applications compiled
with any of the GCC libraries support the quit character
(also normally Control-\). Ofcourse, hitting the quit character
does not dump core like in unix, but it should be easy to add that
in the gcc library, and add an appropriate <core.h>. So to
get at what would be the core file, undump gets the stuff directly
from the memory image of OLDFILE, after the Pexec(4, ..)
returns. The memory image starts at the basepage addr (which undump
has from doing the Pexec(3, ..)) (this is also why tos 1.4's
Pexec(6, ..) is not appropriate to use).
- The undumped program is reponsible for recognizing that the undumped
(as opposed to the virgin) image is being run. This is usually
done by setting a flag in the virgin run (see src/tex.c for
an example).
- it should be faily obvious from the source file that gcc (or
an ansi C) is required to compile undump.c. What may not be obvious
is that the gcc library required is the one that eric smith
and i put together, which was distributed with Gcc 1.35 and
is available from terminator or dsrgsun. (if you get it from
terminator, please mail me for updates). It may work with
the origonal gcc library, but you probably will have some
header files missing, but i have'nt tried. A little commercial
for our library and gcc:
- almost complete Ansi C libarary, with all the required
headers, complete with all prototypes.
- supports both -mshort (16 bit default ints) and 32 bit
ints.
- much better unix compatibility (even stuff like vfork,
execl, popen, system with long args and re-direction
etc etc), complete with prototypes
- efficient stdio, support for both bin and ascii streams,
complete support for %[efg], with proper rounding/prec
etc etc.
- complete BSD curses, and widget library
- full IEEE floating point support, with proper normalization
rounding etc. fairly complete and accurate math library.
(max absolute error sin(x) <= 1e-16, savage.c gives
exact answer).
- efficient and readable gemlib.
- support for inline gemdos/bios/xbios/lineA etc.
inlining can be optionally turned off. (-D__NO_INLINE__)
- all prototypes can be supressed ( -D__NO_PROTO__ )
- gcc completely setup for -mshort usage.
- source has #ifdef's for makeing atari-minix-gcc too.
any feed back will be much appreciated,
--
bang: {any internet host}!dsrgsun.ces.CWRU.edu!bammi jwahar r. bammi
domain: bammi@dsrgsun.ces.CWRU.edu
GEnie: J.Bammi