Hello Jonathan, Eric,

Thank you for your replies


> Generally, but there are (of course) more sections that can go into
> that. .data1, etc.  I'd think that the program headers would be a better
> thing to rely upon, instead of the section headers.

The Elf_Phdr's seems to have sections merged in it, i.e both .data and
.bss are merged into a 'rw-p' segment which is used by elf_loader to
load it directly.

But there is NO WAY I can get information on where excatly (which
virtual address) the data starts and its size, I can get this
information from unstripped section headers (Generally people dont
strip section headers) from the executable even though its totally
redundant.

Eric as you said data sections are named as 'data' , 'data1' ... why
does'nt the linker merge all the DATA sections together, Where do all
my application global variables (initialized) go into .data or .data1
??

Is it the sheer size of the DATA section causes this split for page
alignment during loading ??

>
> 'elfdump -c' dumps the section headers, 'elfdump -p' dumps the program 
> headers.
>

Thank you, I tested elfdump its working fine.

> > My application tries to persist the contents of DATA and BSS and
> > rewrite them back.
>
> To do what?  Is this an 'undump'-style thing, like emacs does?

Yes!! this is excatly what my program does, reads the elf_shds to
figure out the excat begin and size of .data and .bss sections dump
them and reload them.

The other thing I do is to dump the heap, How can I get the base of
the heap in solaris? In linux I read /proc/maps files to figure out
the range of heap virtual address, so I write them and read them back.

You might well wonder why I dont dumpout all the memory maps form
/proc/maps file and read them back just as emacs unexec does, all this
is because of the new Address Space Layout Randomization (ASLR)  which
randomizes the 'mmap' return virtual address's and also randomizes the
brk_base.

emacs 'undump' style may well be screwed up while the program restores
itself since the shared libraries (libc.so ...) are loaded at
different virtual address locations.

So since the state of the program theoretically depends on the
following (NEW WAY TO UNDUMP)

o BSS, DATA sections of the application, BSS and DATA sections of all
the shared libraries
o Heap

I thought its better if we just dump out and undump these sections
from the running program.

Do you see anything missing, It will be really great to have your
valuable feedback to revamp what I'am doing, do share your
suggestions.

Best Regards,
Vamsi.

Reply via email to