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