|> I have a wierd problem. I would like to dump the contents of a chunk
|> of contiguous memory locations. The contents represent some complex
|> graph structure which once built is constant over different
|> invocations of the program.
|> Instead of traversing the graph and dumping its contents, I would
|> like to dump the contents of this contiguous memory. Subsequent
|> invocations of this program could then use mmap() system call to map
|> the information in this file to the address used when the file was
|> first created.
| It's a bit ugly, but it should be workable on most systems. Sendmail
| does something similar with its frozen config files.
Beauty is in the eye of the beholder, I guess. I've done it, with a tree
structure, and I thought it was rather cute.
|> The program has static behavior until the creation of this graph and
|> so on the same machine I will definitely be able to guarantee the
|> availability of that address space.
| Are you sure? Part of that space is probably already occupied by
| data/bss.
Part of what space? He should dump the entire address space, for what?
| Unless you are specifically allocating a block of memory for this
| purpose, and want to save and restore only that block. You still may
| be better off with read than mmap, if for no other reason than some
| systems don't have mmap.
Specifically allocating a block of memory is likely to be a more
productive strategy, although you do have to ensure that everything that
matters gets allocated from that block. As for mmap(), not only do some
systems not have it, but it doesn't seem to behave identically between
systems that do. However, I would suggest starting with mmap(), since
that puts some extra constraints on the problem (e.g., page alignment),
and then add read() (and write()) alternatives if it proves necessary.
It's not greatly different, mmap = read, close = write, and those nice
#ifdefs make your code more readable. The mmap() incompatibilities I
alluded to aren't severe; no use asking me what they are, as I have
forgotten everything.
|> One of my concerns is will the address space be different on
|> different Operating Systems??
| Yes. The difference is usually fairly minor; most UNIXish systems just
| give you text/data/stack at runtime, so if you dump out the data
| segment you should be OK, even though the data segment may begin at a
| different address and be a different size from system to system. If
| you encounter a system that doesn't fit this model, you may have to
| abandon this technique. (On SunOS 4.x, for example, you will likely
| have to link -Bstatic if you want to dump the whole data segment,
| because otherwise pieces of the conceptual data segment are up at
| random addresses thanks to shared object files being brought in at
| run-time.)
On the other hand, if you don't aspire to dump the whole data segment, but
rather have a discrete chunk of data that's supposed to reside at a particular
address, and you have allocated the memory required for that, then the
address space is exactly the same, right? To me, this seems like the way
to go. Do consider labelling the data, inside the file, with some information
about the starting address and extent of your data - at least then when you
recompile the program and change addresses, your program can tell you that
you have obsoleted your old data.
Donn Cave, University Computing Services, University of Washington
by