(j3.2006) Alternative binding label without C interoperability?

Thu Sep 29 08:59:13 EDT 2016

On Sep 29, 2016, at 2:31 AM, Van Snyder <Van.Snyder at jpl.nasa.gov<mailto:Van.Snyder at jpl.nasa.gov>> wrote:

On Thu, 2016-09-29 at 14:01 +0900, Cohen Malcolm wrote:
I don't even follow what the alleged problem is with module procedures
either, since the same compiler is involved!

I don't know whether Tom is thinking of POSIX functions called dlopen()
and dlsym() (IEEE Std 1003.1), but it would seem to be a problem to use
them.  dlopen() isn't a problem because it just wants a file name.

Yes and yes.

But
dlsym() wants a handle for a loaded shared library (provided by dlopen),
and a string for an entry name.  I don't know if these are Windows
function names.  There are Linux man pages for them, as well as pages in
The Open Group Base Specifications Issue 7 (2013 edition), for example
at http://pubs.opengroup.org/onlinepubs/9699919799/, where you can put
dlopen and dlsym into a search pane.

If the entry name is for a module procedure, it's unlikely the program
will be able to guess how the compiler mangled it.  If the processor
mangles names of external procedures, that's a problem too.

This is actually quite possible, but difficult to maintain.   When I did this before ~5-7 years ago, I was able to accurately predict the external binding names for the compilers I was using:   Intel, GNU, NAG, and possibly IBM (back when Mac?s had motorolla chips).

If a non-mangled label for an external or procedure can be specified,
then using shared libraries dynamically according to the dynamic needs
of the program, not just what was discovered by ld, becomes possible and
portable.

I have been asked whether it's possible to create a dynamic library of
Fortran procedures, load it dynamically (without ld being aware of its
future use or the names of any entries in it), get a handle for a
Fortran procedure name in it, which procedure name might have come from
input without appearing anywhere in the program, associate that entry
with a procedure pointer, and then invoke the procedure.  So far, my
answer has been "Not in portable standard Fortran."  The nonportable
part has been the mangling of both external and module procedure names.
People have gone to some interesting nonportable extremes, such as
looking in .mod and .o files, and trying to guess how one particular
processor has mangled procedure names.

Again.  I?ve done this.   And one just needs to maintain a growing list of compiler specific routines that do the translation.    In general these take two arguments:   The procedure name and the module name, the latter of which is optional.  If not present, then it is an external procedure.     In theory there are lots of ways this could go wrong - e.g. if the binding name started having components that dependended on the types of the arguments (ala C++ mangling), but at least at that time I had no further difficulties.

I mentioned one way to do this in a paper that I circulated informally
at the 2001 London WG5 meeting, wherein it was suggested that a
variation of the ALLOCATE statement might provide the functionality:

 ALLOCATE ( LIBRARY = '/mypath/mylibrary', &
   & ASSOCIATE = ( proc_ptr_1, 'entry_1'), &
   & ASSOCIATE = ( proc_ptr_2, 'entry_2'), STAT = oops )

The problem of entry name mangling was not discussed.  Of course, it
should be possible to provide the entry names as variables.  Otherwise,
the feature offers nothing new.  Nobody commented on anything proposed
in that paper, other than Dan, who said the next revision would be
minor.

As I said, I don't know what scenario Tom is battling, but I and my
colleagues would like a solution for this one.

I believe your approach would solve my problem as well.   Essentially I want a portable means to ?find? a given procedure by specifying its name.

There are lots of approaches and all have some problems.

  1.  Existing approach:   Parent components directly pass the setServices() procedures of their children components to the  ESMF framework.   This cleanly sidesteps the ?name? issue, but then the parent has a compile-time dependency on its children.   This is something that the framework otherwise is attempting to eliminate.    A workaround is to make the various setServices() procedures into external procedures, but then we have to establish a naming convention to avoid collisions in namespace at load time.    And I might even go down that path.   But I would prefer the ability to swap equivalent children components at run time rather than recompiling with the swapped names.
  2.  The model develops a high level initialization routine that registers all possible setServices() procedures with string names.    (2 variants depending on whether we put the setServices() are module procedures or have unique Fortran names.)  This is technically workable, but violates good design because one now needs to maintain this procedure to be consistent with all of the possible components.    I.e. one change must be implemented in 2 places.   But this is not unworkable, and would provide the ability to use a configuration file to swap children components.
  3.  Find a designated procedure in the executable itself through some lookup mechanism.   I?m told C++ has limited abilities in this direction.
  4.  Find a designated procedure in a library.   DSO?s are great for this sort of thing, and appear to work well for this problem _other_ than the issue of the per-compiler name mangling that must be maintained.   But as the number of compilers is much smaller than the number of components and changes on a much longer time scale, this too is not completely unworkable.
     *   A variant of this is to modify the specific interface of interest here such that BIND(C) can be used.   We can then ignore the compiler-specific mangling.   This one is likely to be pursued, but would not help in other situations.
  5.  Propose new Fortran mechanism that would be simpler.

I can?t immediately rattle off a number of specific use cases.   But it won?t be difficult to find them.   The basic capability is to enable run-time selection of code elements via a configuration input file rather than compile time.   Common in other software communities - a bit rarer in the Fortran/HPC world.

Cheers,

- Tom

_______________________________________________
J3 mailing list
J3 at mailman.j3-fortran.org<mailto:J3 at mailman.j3-fortran.org>
http://mailman.j3-fortran.org/mailman/listinfo/j3

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.j3-fortran.org/pipermail/j3/attachments/20160929/672d99ae/attachment-0001.html 