3:14 a.m.
> Ben> Pdump has been rock-solid for me on Windows and
Cygwin for a
> Ben> long time, with no recent patches.
>
> There is some lingering unsigned uncleanliness on Mac OS X IIRC.
>
> Ben> Is it time to nuke the old unexec code and use pdump
> Ben> everywhere?
>
> I have heard _no_ complaints about pdump since the bug where some
> dumped variables were overriding command-line switches got worked
> around sometime around 21.4.5, with the single exception of the
> annoying .dmp files. As long as those are now gone on all
platforms
> (I think OG fixed that last summer?) I'm in favor of getting rid of
> unexec.
It looks like pdump doesn't yet work on all platforms. In
the xemacs.spec file for SuSE Linux, we use don't use pdump
for the ia64 architecture. Andreas Schwab (CC:), our ia64
expert said it doesn't work on ia64. He even told me today it
*cannot* work on ia64.
I find that hard to believe; I wonder what his reasons are ...
3:53 a.m.
New subject: Nuking unexec
>>>> "Ben" == Ben Wing <ben(a)666.com>
writes:
Ben> I find that hard to believe; I wonder what his reasons are ...
Some of the objects that get dumped contain function pointers. In the IA64
ABI, these point to a descriptor containing { &code, &data_context }. At the
very least data_context varies between machines and across reboots (I'm not
sure about per process). Data_context is so machine dependant that there is
no useful way that we can get access to it in XEmacs.
SuSe have a patch to 21.4 that re-assigns these function pointers at startup
(in a similar vein to reinit_vars_of_X()). It's pretty invasive but I think
it's the only way we can work around it. I've a dusty workspace that tries to
clean the patch up a bit but haven't worked on it recently for a lack of two
IA64 boxes to try it on (I'm not allowed to reboot the one I've access to).
Emacs doesn't have this problem because I don't think it dumps function
pointers.
Malcolm
--
Malcolm Purvis <malcolmp(a)xemacs.org>
4:20 a.m.
New subject: Nuking unexec
Malcolm Purvis <malcolmp(a)xemacs.org> wrote:
Some of the objects that get dumped contain function pointers. In
the IA64
ABI, these point to a descriptor containing { &code, &data_context }. At the
very least data_context varies between machines and across reboots (I'm not
sure about per process). Data_context is so machine dependant that there is
no useful way that we can get access to it in XEmacs.
SuSe have a patch to 21.4 that re-assigns these function pointers at startup
(in a similar vein to reinit_vars_of_X()). It's pretty invasive but I think
it's the only way we can work around it. I've a dusty workspace that tries to
clean the patch up a bit but haven't worked on it recently for a lack of two
IA64 boxes to try it on (I'm not allowed to reboot the one I've access to).
Emacs doesn't have this problem because I don't think it dumps function
pointers.
I am about to commit Olivier Galibert's patch to enable dumping and
loading of bignums. It does this via a mechanism very like Java's
serialization mechanism. That is, for a given data type, you specify a
function that converts to a dumpable external format, and a function
that converts back from that format. Is there something we could save
that would let us recover the function pointer at run time? How about
an internal dictionary of [names <-> function pointers] and do lookups
there while undumping?
(It isn't quite that easy. We would have to make function pointers be a
data type in their own right for this to work, but it could be done.)
To what functions do we dump pointers?
--
Jerry James
http://www.ittc.ku.edu/~james/
10:20 a.m.
New subject: Nuking unexec
Malcolm Purvis <malcolmp(a)xemacs.org> writes:
>>>>> "Ben" == Ben Wing <ben(a)666.com>
writes:
Ben> I find that hard to believe; I wonder what his reasons are ...
Some of the objects that get dumped contain function pointers. In the IA64
ABI, these point to a descriptor containing { &code, &data_context }. At the
very least data_context varies between machines and across reboots (I'm not
sure about per process). Data_context is so machine dependant that there is
no useful way that we can get access to it in XEmacs.
Note that only dynamic assignments are a problem, because their function
descriptors are allocated at runtime (during initial relocation), thus
their address differ before and after dumping. (This is unlike powerpc64
where every function has a descriptor preallocated.) For static
initialisations the corresponding descriptors are also statically
allocated and won't change. Thus for example C++ vtables would not pose a
problem.
Andreas.
--
Andreas Schwab, SuSE Labs, schwab(a)suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
10:42 a.m.
New subject: Dumping IA64 function pointers (was Re: Nuking unexec)
>>>> "Jerry" == Jerry James
<james(a)xemacs.org> writes:
Jerry> To what functions do we dump pointers?
The console methods listed in console.h are the biggest but there are similar
ones in other files.
Remember, the key to undumping IA64 function pointers is knowing the value of
<data_context>, which has to be determined each time XEmacs starts. What I
don't know is if the IA64 API provides a function to fetch it. Does anyone
else know?
What would need to be done to turn function pointers into their own datatype?
Malcolm
--
Malcolm Purvis <malcolmp(a)xemacs.org>
11:10 a.m.
New subject: Dumping IA64 function pointers (was Re: Nuking unexec)
Malcolm Purvis <malcolmp(a)xemacs.org> writes:
Remember, the key to undumping IA64 function pointers is knowing the
value of
<data_context>, which has to be determined each time XEmacs starts. What I
don't know is if the IA64 API provides a function to fetch it. Does anyone
else know?
*(struct { void *ip; void *gp; } *)&fun
Andreas.
--
Andreas Schwab, SuSE Labs, schwab(a)suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
1:56 p.m.
New subject: Nuking unexec
>>>>>> "Ben" == Ben Wing
<ben(a)666.com> writes:
>
> Ben> I find that hard to believe; I wonder what his reasons are ...
>
> Some of the objects that get dumped contain function
pointers. In the
> IA64 ABI, these point to a descriptor containing { &code,
> &data_context }. At the very least data_context varies between
> machines and across reboots (I'm not sure about per process).
> Data_context is so machine dependant that there is no
useful way that
> we can get access to it in XEmacs.
Note that only dynamic assignments are a problem, because
their function descriptors are allocated at runtime (during
initial relocation), thus their address differ before and
after dumping. (This is unlike powerpc64 where every
function has a descriptor preallocated.) For static
initialisations the corresponding descriptors are also
statically allocated and won't change. Thus for example C++
vtables would not pose a problem.
I'm not quite sure what you are referring to here by "dynamic assignment of
function pointers" -- can you give me an example? I'm sure there is a way
of simply reassigning the function at dump-load time.
1:58 p.m.
New subject: Nuking unexec
SuSe have a patch to 21.4 that re-assigns these function
pointers at startup (in a similar vein to
reinit_vars_of_X()). It's pretty invasive but I think it's
the only way we can work around it. I've a dusty workspace
that tries to clean the patch up a bit but haven't worked on
it recently for a lack of two IA64 boxes to try it on (I'm
not allowed to reboot the one I've access to).
Go ahead and post what you've got; I'll clean it up as necessary.
Ben
2:05 p.m.
New subject: Nuking unexec
"Ben Wing" <ben(a)666.com> writes:
I'm not quite sure what you are referring to here by
"dynamic assignment of
function pointers" -- can you give me an example?
Anything that is not static initialisation.
I'm sure there is a way of simply reassigning the function at
dump-load
time.
That's what our patch is doing, but unfortunately not in a very clean way.
Andreas.
--
Andreas Schwab, SuSE Labs, schwab(a)suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
3:11 p.m.
New subject: Dumping IA64 function pointers (was Re: Nuking unexec)
Malcolm Purvis <malcolmp(a)xemacs.org> wrote:
What would need to be done to turn function pointers into their own
datatype?
No, that's nonsense. It seemed to make sense when I wrote it just
before going to bed last night ...
What we really need to do is to find all the places where function
pointers are being dumped and make them be XD_OPAQUE_PTR_CONVERTIBLE
instead of whatever they are now. We would also have to write the
encoding and decoding functions, but from what I've read so far, that
would not be exceptionally difficult.
I'm willing to help with this, but I have no access to an IA64 box.
I'll commit OG's stuff later today so everybody can see it.
--
Jerry James
http://www.ittc.ku.edu/~james/
5:56 p.m.
New subject: Dumping IA64 function pointers (was Re: Nuking unexec)
On Wed, Feb 02, 2005 at 09:11:07AM -0600, Jerry James wrote:
What we really need to do is to find all the places where function
pointers are being dumped and make them be XD_OPAQUE_PTR_CONVERTIBLE
instead of whatever they are now.
They're not tagged at that point. Not a problem to add a tag for them
though, that will be happily ignored on sane cpus.
I am a tad afraid of the address randomazing craze that's currently
going on though.
We would also have to write the
encoding and decoding functions, but from what I've read so far, that
would not be exceptionally difficult.
There is a way to convert a function pointer from the pre-dump value
to the post-load one?
I'm willing to help with this, but I have no access to an IA64
box.
I'll commit OG's stuff later today so everybody can see it.
Remember that, unless you did it, half of it is untested.
OG.
7025
days inactive
7025
days old
10 comments
5 participants
participants (5)
-
Andreas Schwab -
Ben Wing -
Jerry James -
Malcolm Purvis -
Olivier Galibert