home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / unix / wizards / 5293 < prev    next >
Encoding:
Internet Message Format  |  1992-12-21  |  2.7 KB
  1. Xref: sparky comp.unix.wizards:5293 comp.unix.programmer:5750 comp.unix.questions:14856
  2. Path: sparky!uunet!olivea!charnel!sifon!thunder.mcrcim.mcgill.edu!mouse
  3. From: mouse@thunder.mcrcim.mcgill.edu (der Mouse)
  4. Newsgroups: comp.unix.wizards,comp.unix.programmer,comp.unix.questions
  5. Subject: Re: Portability issues in using a memory dump
  6. Message-ID: <1992Dec21.165835.17205@thunder.mcrcim.mcgill.edu>
  7. Date: 21 Dec 92 16:58:35 GMT
  8. References: <1992Dec17.222402.18347@sj.ate.slb.com>
  9. Organization: McGill Research Centre for Intelligent Machines
  10. Lines: 48
  11.  
  12. In article <1992Dec17.222402.18347@sj.ate.slb.com>, bharat@sj.ate.slb.com (Bharat Venkatasubramanian) writes:
  13.  
  14. > I have a wierd problem.  I would like to dump the contents of a chunk
  15. > of contiguous memory locations.   The contents represent some complex
  16. > graph structure which once built is constant over different
  17. > invocations of the program.
  18.  
  19. > Instead of traversing the graph and dumping its contents, I would
  20. > like to dump the contents of this contiguous memory.  Subsequent
  21. > invocations of this program could then use mmap() system call to map
  22. > the information in this file to the address used when the file was
  23. > first created.
  24.  
  25. It's a bit ugly, but it should be workable on most systems.  Sendmail
  26. does something similar with its frozen config files.
  27.  
  28. > The program has static behavior until the creation of this graph and
  29. > so on the same machine I will definitely be able to guarantee the
  30. > availability of that address space.
  31.  
  32. Are you sure?  Part of that space is probably already occupied by
  33. data/bss.  You'd probably be better off using brk() to set the break to
  34. the appropriate place and then just read()ing in the file.  Be careful
  35. to use only automatic variables....
  36.  
  37. Unless you are specifically allocating a block of memory for this
  38. purpose, and want to save and restore only that block.  You still may
  39. be better off with read than mmap, if for no other reason than some
  40. systems don't have mmap.
  41.  
  42. > One of my concerns is will the address space be different on
  43. > different Operating Systems??
  44.  
  45. Yes.  The difference is usually fairly minor; most UNIXish systems just
  46. give you text/data/stack at runtime, so if you dump out the data
  47. segment you should be OK, even though the data segment may begin at a
  48. different address and be a different size from system to system.  If
  49. you encounter a system that doesn't fit this model, you may have to
  50. abandon this technique.  (On SunOS 4.x, for example, you will likely
  51. have to link -Bstatic if you want to dump the whole data segment,
  52. because otherwise pieces of the conceptual data segment are up at
  53. random addresses thanks to shared object files being brought in at
  54. run-time.)
  55.  
  56.                     der Mouse
  57.  
  58.                 mouse@larry.mcrcim.mcgill.edu
  59.