On Mon, 23 Aug 2004, Tim Jenness wrote:
> - ARD on 64bit: the %LOC problem. It occurs to me that the real
> difficulty with a CNF_PREG function for registering arbitrary pointers
> with CNF is that CNF tries to be really clever and tries to make sure
> the the lower 32bits of the pointer are unique. Surely this is
> unimportant. Yes, if sizeof(Cpointer)==sizeof(Finteger) then it is
> important that pointers generated by NDF_MAP and PSX_CALLOC are
> "real" pointers and not aribtrary numbers (else "legacy" code that
> does not use CNF_PVAL will simply fail immediately). The problem
> is that when Fortran integer and C pointer are of different sizes
> it's all a bit irrelevant what CNF does with the pointer to integer
> mapping so long as CNF_PVAL returns the correct thing. Code that
> uses %VAL but no CNF_PVAL will still work on 32bit systems and (as
> in the alpha case) where the deep juju linker options are used
> to make sure that low 32bits are always okay.
>
> Anyway, what this ramlbing is trying to say is that in the two
> cases when:
>
> a) We are registering %LOC pointers with CNF using CNF_PREG
>
> b) sizeof(Cpointer) != sizeof(Fpointer) [and no deep juju link
> options]
>
> CNF will be perfectly within its rights simply to store the
> C pointers in a lookup table with a monotonically increasing
> index. Currently if you forget to use CNF_PVAL in 64bit code
> you get a core dump. Making CNF return "1" for the first pointer
> and "2" for the second will still give core dumps without CNF_PVAL
> (no change there) but guarantees that ALL pointers can be
> registered.
Hi,
your explanation seems to reflect pretty much what I remember of these
discussions (which I wasn't directly involved in either), but there surely
is a problem with this idea of returning what will be an arbitrary pointer
to the address space of the process. Yes, 1 and 2 and so on will probably
code dump, but that's not guaranteed, I think 0 is the only valid, invalid
pointer. The safe way to create an invalid pointer must be to allocate
some memory and then deallocate it.
Naturally if no "64bit unclean" applications are linked/distributed that's
all a redundant argument.
> What I'm proposing then is that CNF will check
> sizeof(void*) != sizeof(F77_POINTER_TYPE) and change it's indexing
> scheme to be guaranteed to work [the current scheme always works fine
> if the pointer == integer]. The only real issue is the alpha where
> in general void* != integer but the current scheme still works
> due to linker cleverness (meaning that legacy code using %VAL on
> those systems works without CNF_PVAL). As a migratory step we could
> engineer things such that CNF will first try to register a pointer
> using the current scheme, and fallback to monotonic index scheme
> if that fails. [the register code could have a new flag argument
> indicating whether this fallback should happen such that psx_
> can do it's memory reallocation if needs be].
>
> Comments welcome. It's not clear I have the C skills to modify CNF
> safely but it seems to me that this is the easiest way to get the
> 64bit port working without peppering the code with that INTEGER*8 hack
> of Norman's :-)
Sounds like it should work.
Peter.
|