TREE_PUBLIC for module symbols?

[Paul Richard Thomas]

Hi Damian,

There is a double problem:

(i) Since entities in submodules have to behave as if they are host
associated to the module, it means that all entities in the module
have to be visible. I have chosen to implement this by having two
parts to the module file; the first is the normal part, such that
other program units than submodules can use the module as usual. The
second part contains everything else and is only read by submodules.
This has the advantage of minimizing the changes. However, it means
that the potentially IPR sensitive part of the module is visible by
gunzipping the module file.

(ii) The fact that all the private entities in the module have to be
TREE_PUBLIC means that, in principle, they are visible and accessible
outside submodules. I do not think that this much of a problem but I
am worried that I do not know enough to be sure of this.

My thinking is that one could encrypt the private part of the module
file but, being open source, the key would be visible and even a
slightly determined hacker could expose the private entities. For this
reason, I do not think that it is worth trying.

I would be very curious to know what the other brands have done, since
I think that this is a problem that is implicit to the introduction of
submodules. Of course, one of the advantages of submodules is that all
the IPR can be hidden there, if this is an issue. Maybe we in gfortran
should take the view that open source is where we are at?

Cheers

Paul

On 1 July 2015 at 19:37, Damian Rouson <damian@sourceryinstitute.org> wrote:
>
>
>> On Jul 1, 2015, at 3:42 AM, Paul Richard Thomas <paul.richard.thomas@gmail.com> wrote:
>>
>> Dear Tobias,
>>
>> Following the latest version of my submodule patch, I have managed to
>> overcome the difficulty of making private symbols available to
>> submodules in a reasonably economical fashion. Of course, the solution
>> makes these symbols visible in the module file, albeit in a different
>> section to public symbols.
>
> How does this impact the compiler cascade?  If private entities appear in the module file, then won’t that cause other program scopes to be recompiled whenever there are changes to private symbols in the module file change.  My understanding is that preventing unnecessary compiler cascades was one of the primary motivations for submodules. If not preventing them is the cost of an economical solution, then it might be worth redefining economical to include the costs of compiling. :)
>
>>
>> Since private symbols are now visible in the module files, the meaning
>> or usefulness of privacy becomes rather moot, as already discussed on
>> the list.
>
> In light of what I wrote above, it might be time to consider paths other than storing private symbols in the module file.  However, as you know, I’m a fan of progressive steps.  It would be reasonable to accept otherwise unnecessary compiler cascades as a necessary evil of getting submodules into the compiler expediently, but I hope there will be subsequent consideration of a redesign after the initial submodule support is complete.
>
>> This conundrum is made still worse because module variables
>> have to be set TREE_PUBLIC, otherwise they disappear at any level of
>> optimization and leave the linker complaining verbosely.
>
> Ouch.  I think most Fortran programmers would rank runtime performance above compile-time performance.  Hmm… I guess it wouldn’t be the first time a new language construct didn’t achieve its intended purpose (preventing cascades), but let’s hope someone can propose a way to get both.
>
>>
>> Consider an example:
>> module foo
>>
>>  private
>>
>>  public bar
>>
>>  integer :: a = 1
>>
>>  interface
>>    module subroutine bar
>>    end subroutine
>>  end interface
>>
>> contains
>> end module
>>
>> submodule(foo) fooson
>>
>> contains
>>  module subroutine bar
>>    print *, a
>>    a = a+1
>>  end subroutine
>> end submodule
>>
>> program test
>>  use foo
>>  call bar
>>  call bar
>>  call bar
>>  call bar
>>  call bar
>> end program test
>>
>> Unless 'a' is forced to be TREE_PUBLIC the link stage fails at -O1 and
>> above. Is there an alternative to TREE_PUBLIC? If not, what are the
>> ramifications of making all module entities TREE_PUBLIC?
>
> An explanation for the layperson would be great if you don’t mind.
>
> Damian
>



-- 
Outside of a dog, a book is a man's best friend. Inside of a dog it's
too dark to read.

Groucho Marx