Question about the segment

> 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
-
To unsubscribe from this list: send the line
"unsubscribe linux-ia64" in
the body of a message to majordomovger.kernel.org
More majordomo info at  http://vge
r.kernel.org/majordomo-info.html

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.
-
To unsubscribe from this list: send the line
"unsubscribe linux-ia64" in
the body of a message to majordomovger.kernel.org
More majordomo info at  http://vge
r.kernel.org/majordomo-info.html

"vamsi krishna" <vamsi.krishnakgmail.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, schwabsuse.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."
-
To unsubscribe from this list: send the line
"unsubscribe linux-ia64" in
the body of a message to majordomovger.kernel.org
More majordomo info at  http://vge
r.kernel.org/majordomo-info.html

Hello Andreas,

On 6/8/06, Andreas Schwab <schwabsuse.de> wrote:
> "vamsi krishna" <vamsi.krishnakgmail.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
-
To unsubscribe from this list: send the line
"unsubscribe linux-ia64" in
the body of a message to majordomovger.kernel.org
More majordomo info at  http://vge
r.kernel.org/majordomo-info.html

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?
-
To unsubscribe from this list: send the line
"unsubscribe linux-ia64" in
the body of a message to majordomovger.kernel.org
More majordomo info at  http://vge
r.kernel.org/majordomo-info.html

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.ht
ml may be of
interest.
-
To unsubscribe from this list: send the line
"unsubscribe linux-ia64" in
the body of a message to majordomovger.kernel.org
More majordomo info at  http://vge
r.kernel.org/majordomo-info.html

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.
-
To unsubscribe from this list: send the line
"unsubscribe linux-ia64" in
the body of a message to majordomovger.kernel.org
More majordomo info at  http://vge
r.kernel.org/majordomo-info.html

Hello All,

Thank you for all your comments, I fixed my issue on
linuxipf. The
problem is a standard memory corruption problem. I had a
'FILE *ptr'
which was opened in the save run, during the restore run
since the
FILE *'s are not restored I reopen the FILE * and do a
memcpy into
*ptr since in the restore run *ptr is not a valid memory
this caused
the corruption and _IO_flush_all was stuck.

Thank you once again.

Best,
Vamsi
-
To unsubscribe from this list: send the line
"unsubscribe linux-ia64" in
the body of a message to majordomovger.kernel.org
More majordomo info at  http://vge
r.kernel.org/majordomo-info.html