RE: Question about the segment [[ 60000fff80000000-60000fff80004000 rw-p 0000000000000000 00:00 0 ]]

RE: Question about the segment [[ 60000fff80000000-60000fff80004000 rw-p 0000000000000000 00:00 0 ]]

[Luck, Tony]

> 60000fff80000000-60000fff80004000 rw-p 0000000000000000 00:00 0 (just
> above the stack).

RSE backing store.

> Also why IPF kernel differs from other systems where the mmap space is
> below &_etext where as on other systems its above &_end. ??

Do you have an application where this is a problem?

-Tony

Question about the segment [[ 60000fff80000000-60000fff80004000 rw-p 0000000000000000 00:00 0 ]]

[vamsi krishna]

Hello All,

I found the following segment in all the process's on IA64 linux kernel.

60000fff80000000-60000fff80004000 rw-p 0000000000000000 00:00 0 (just
above the stack).

Was wondering what excatly is there in this segment? Does it have any
information about the file descriptors /open file table ?

I have a code which tries to override this segment but once I override
this the program gets corrupted.

Also why IPF kernel differs from other systems where the mmap space is
below &_etext where as on other systems its above &_end. ??

Looking forward to hear from you.
Best,
Vamsi

Re: Question about the segment [[ 60000fff80000000-60000fff80004000 rw-p 0000000000000000 00:00 0 ]]

[vamsi krishna]

Hello Tony,

>
> RSE backing store.

Can you tell me where I can find more information about  this?

>
> > Also why IPF kernel differs from other systems where the mmap space is
> > below &_etext where as on other systems its above &_end. ??
>
> Do you have an application where this is a problem?
>

My application is similar to unexec of emacs, tries to save all the
segments in the map file and restore them back, while restoring
currently we assume that if the segment is above sbrk(0) then it needs
to be mmap'ed from the save file else override it.


Looks like If I dont overwrite the RSE backing store fclose on my open
files seem to crash when I restore my program.

RE: Question about the segment [[ 60000fff80000000-60000fff80004000 rw-p 0000000000000000 00:00 0 ]]

[Luck, Tony]

>> RSE backing store.
>
> Can you tell me where I can find more information about  this?

Section 4.1 of volume 1 of the Itanium Software Developers Manual
(you can download in PDF form from http://www.intel.com/design/itanium/manuals/iiasdmanual.htm)

> My application is similar to unexec of emacs, tries to save all the
> segments in the map file and restore them back, while restoring
> currently we assume that if the segment is above sbrk(0) then it needs
> to be mmap'ed from the save file else override it.

You'll need to look more closely at bits from /proc/$$/maps
to figure out some heuristic ... a simple comparison against
the address of sbrk(0) isn't going to cut it (as you have
alreasdy figured out).

> Looks like If I dont overwrite the RSE backing store fclose on my open
> files seem to crash when I restore my program.

Hmmm, sounds like some interesting code would be needed to do
this.  When saving, you'd need to make sure that all state
was flushed out of the stacked registers into memory.  You'd
also need to save the values of ar.bspstore etc. that refer
to the RSE backing store.  On resume, you'd need to restore
the registers.  Perhaps some creative use of setjmp/longjmp
might allow you to avoid coding this up in assembler?  But I'm
not quite sure whether that would handle everything for you.

-Tony

Re: Question about the segment [[ 60000fff80000000-60000fff80004000 rw-p 0000000000000000 00:00 0 ]]

[Andreas Schwab]

"vamsi krishna" <vamsi.krishnak@gmail.com> writes:

> Looks like If I dont overwrite the RSE backing store fclose on my open
> files seem to crash when I restore my program.

You also need to make sure that all function descriptors end up at the
very same address.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Question about the segment [[ 60000fff80000000-60000fff80004000 rw-p 0000000000000000 00:00 0 ]]

[Jes Sorensen]

>>>>> "vamsi" = vamsi krishna <vamsi.krishnak@gmail.com> writes:

vamsi> Also why IPF kernel differs from other systems where the mmap
vamsi> space is below &_etext where as on other systems its above
vamsi> &_end. ??

There is no requirement for this - it also bit ld.so initially.

If you post your code, people could take a look as to what you're
doing and possibly tell you what you do wrong.

Jes

Re: Question about the segment [[ 60000fff80000000-60000fff80004000 rw-p 0000000000000000 00:00 0 ]]

[vamsi krishna]

Hello Andreas,

On 6/8/06, Andreas Schwab <schwab@suse.de> wrote:
> "vamsi krishna" <vamsi.krishnak@gmail.com> writes:
>
> > Looks like If I dont overwrite the RSE backing store fclose on my open
> > files seem to crash when I restore my program.
>
> You also need to make sure that all function descriptors end up at the
> very same address.
>

More to add to this I found that '__IO_flush_all' seem to get stuck ,
when I dont overwrite my RSE backing store, if I overwrite my RSE
backing store some of the data on the stack is getting corrupted.

is '__IO_flush_all' a weak symbol so that I can override ? also
fflush(NULL) hangs and also fcloseall() (I think all are calling
__IO_flush_all)

In my program to restore the state just as emacs unexec I try to save
all the mmaps and either overwrite (for heap) or mmap for all the
things above &_etext.

I tried to save all the maps in /proc/pid/maps except the RSE backing
store and it seems problems in __IO_flush_all , I also made sure that
I flushed all my filestreams before I save.


Really appreciate your comments, let me know if you need more info.

Thank you,
Vamsi

Re: Question about the segment [[ 60000fff80000000-60000fff80004000 rw-p 0000000000000000 00:00 0 ]]

[vamsi krishna]

Hell Andreas,

>
> > Looks like If I dont overwrite the RSE backing store fclose on my open
> > files seem to crash when I restore my program.
>
> You also need to make sure that all function descriptors end up at the
> very same address.
>

Do you mean file descriptors?

Re: Question about the segment [[ 60000fff80000000-60000fff80004000 rw-p 0000000000000000 00:00 0 ]]

[Matthew Wilcox]

On Thu, Jun 08, 2006 at 10:51:13PM +0530, vamsi krishna wrote:
> Hell Andreas,
> >You also need to make sure that all function descriptors end up at the
> >very same address.
> 
> Do you mean file descriptors?

No.  A function descriptor is sometimes called a 'fat pointer'.
Function pointers on ia64 (as with ppc64 and parisc) are not pointers to
the start of the function.  Instead they are pointers to function
descriptors -- small structs which contain information about the
function, including a pointer to the start of the function.

http://lists.debian.org/debian-ia64/2003/10/msg00056.html may be of
interest.

Re: Question about the segment [[ 60000fff80000000-60000fff80004000 rw-p 0000000000000000 00:00 0 ]]

[vamsi krishna]

Hello Matt,

Thank you,

> > Do you mean file descriptors?
>
> No.  A function descriptor is sometimes called a 'fat pointer'.
> Function pointers on ia64 (as with ppc64 and parisc) are not pointers to

If the memory of the fat pointers is there on the heap or mmaped some
where in the mmap space I already take care that , I remap them with
the same address in restore run.

I save all the maps during my save run (including the text of dynamic
shared objects, I dont save the STACK) and mmap them back when I start
my program back.

I only thing (map) I did'nt save during the save run is STACK segment,
so if I leave the STACK segment as it is in the restore run and just
overwrite the RES backstore area then I see that variable on the
current stack are getting corrupted, Is it because that RES backstore
also have some information about the stack ?

Can I slice up RES backstore area avoiding overwriting of the register
information?

My program is a little different from unexec because it tries to
change itself on the fly by writing into its own address space........

The code works on all other linux kernels  except one on IA64...:((

Your suggestions are greatly appreciated .

Sincerely,
Vamsi.