Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix new dynlink's initialisation checks #2176

Merged
merged 5 commits into from Dec 8, 2018
Merged

Conversation

@lpw25
Copy link
Contributor

@lpw25 lpw25 commented Nov 30, 2018

#1063 rewrote the various checks when loading shared libraries with dynlink in order to make them sound. However, the checks to ensure that a module is not used before it has been initialised were far too restrictive. For example, a module in a shared library could not refer to another library within the same shared library. This PR fixes that by updating the list of initialised units earlier. This PR also relaxes the "allowed units" check so that it only applies to implementation dependencies not interface dependencies -- which matches the previous behaviour and is necessary to deal with mli-only modules.

I also added a bunch of tests that exercise the various cases.

This PR should hopefully fix MPR#7876 -- although I haven't actually tried it.

This PR is on top of #2175 because that bug was causing problems with the use of packing added by #1063.

@ejgallego
Copy link

@ejgallego ejgallego commented Nov 30, 2018

I confirm this fixes Coq plugins in both build modes [using -pack and using aliases].

@gasche
Copy link
Member

@gasche gasche commented Dec 1, 2018

cc @alainfrisch @chambart @mshinwell : we don't want to wait for too long between the merge of #1063 in trunk and a fix such as included in the present PR, so I think the urgency of this review is a bit higher than the usual.

@mshinwell
Copy link
Contributor

@mshinwell mshinwell commented Dec 3, 2018

Ack, I will read this soon.

@gasche
Copy link
Member

@gasche gasche commented Dec 3, 2018

( @lpw25, you could rebase now that #2175 is merged. )

@lpw25 lpw25 force-pushed the fix-new-dynlink branch from 482d930 to 7d57ebc Dec 3, 2018
@lpw25
Copy link
Contributor Author

@lpw25 lpw25 commented Dec 3, 2018

Rebased

executed completely cannot be depended upon by another shared library being
loaded. *)
(* Check that a shared library can refer to a module in the main program
if its already loaded. *)
Copy link
Contributor

@mshinwell mshinwell Dec 3, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please clarify what "its" refers to. (And, "its" -> "it's".)

*)

(* Check that a module in a shared library can refer to another module
in the shared library if it is already loaded. *)
Copy link
Contributor

@mshinwell mshinwell Dec 3, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same comment as above regarding "it is".

*)

(* Check that a shared library that is loaded during the loading of
another shared libary can refer to modules of that library if they
Copy link
Contributor

@mshinwell mshinwell Dec 3, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Typo "libary". Also maybe name the libraries "A" and "B" so we can make "that library" precise.

@mshinwell
Copy link
Contributor

@mshinwell mshinwell commented Dec 7, 2018

This is OK to merge after the Changes file has been updated.

@lpw25 lpw25 force-pushed the fix-new-dynlink branch from f07e948 to 8c587da Dec 7, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

4 participants