Re: run time memory address of my application

benmidgley@xxxxxxxxxxxxxx writes:

I have shared object as part of an application, within this shared
object called by an application which I do not want to modify I have
state data, which I want to be able to back up and restore under the
feet of the application.

If the data is inside the DSO, and you have control over that DSO,
and you want to save/restore the data from within the same process
that is executing "application", then it is not clear why you can't
refer to the data directly.

If you have some constraint that prevents that, you didn't do a
good job explaininig that constraint :-(

Cheers,
--
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.
.

Relevant Pages

  • Re: run time memory address of my application
    ... I do not want to modify that application even just to make ... If the data is inside the DSO, and you have control over that DSO, ... good job explaininig that constraint :-( ... In order to understand recursion you must first understand recursion. ...
    (comp.os.linux.development.apps)
  • Re: Converting .o files into shared and static libraries
    ... but this leads to some new symbols (which were defined ... You may still be able to build a DSO out of them by "simulating" ... what the linker does with archives: ... In order to understand recursion you must first understand recursion. ...
    (comp.unix.programmer)
  • Re: creating a "closed" shared object
    ... > prevent the zlib libraries from the loading process from being executed? ... as your DSO is with the older ones). ... In order to understand recursion you must first understand recursion. ...
    (comp.unix.solaris)
  • Re: About *.so files
    ... The reason you don't is that by the time 'ld' is finished producing ... the DSO, all the various *.o that went into it have been "welded" ... In order to understand recursion you must first understand recursion. ...
    (comp.unix.solaris)