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

Make (nat)dynlink sound (also fixes MPR#4208, MPR#4229, MPR#4839, MPR#6462, MPR#6957, MPR#6950) #1063

Open
wants to merge 3 commits into
base: trunk
from

Conversation

Projects
None yet
@mshinwell
Contributor

mshinwell commented Feb 24, 2017

This patch forbids dynlinking of compilation units that have already been loaded (either as part of the main program or via a previous dynlink). This appears to be sufficient to solve the problems described in the five Mantis issues in the title of this pull request.

In bytecode, it was previously possible to break type abstraction, since there is no implementation CRC for bytecode. In native, it was also possible to produce segmentation faults, via various means.

It has previously been suggested that platform-dependent solutions such as RTLD_DEEPBIND on glibc systems might be sufficient to solve these problems. @chambart and I discussed this and it appears not to be the case: for example suppose there is some module N that generates fresh names. A depends on N in the main program. We dynlink B which also depends on N. Further, B passes values made in N to A. Whilst under RTLD_DEEPBIND the code of B successfully references its own copy of N, it passes values to A that could break invariants of A's copy of N if they were to flow into there---and they might. It seems safer to just be conservative.

@chambart and I discussed whether this new restriction would be problematic for authors of plugin systems that might end up loading modules more than once. However we believe these problems can be solved by such systems using their own caching layer that can catch the new error value returned (Dynlink.Error(Module_already_loaded ...)).

A further improvement would be able to effectively incorporate such caching into the dynlink system itself such that, for example, if a module had already been dynlinked then some handle to that module could be returned. Such a handle would naturally be a corresponding first class module. Some of this work is already in GPR #100, although that does not include the protections introduced by this pull request. @chambart will follow up about that.

It is possible that there remains one problematic situation: a module that tries to load itself whilst it is being initialised. @chambart is checking this now.

@mshinwell mshinwell requested a review from chambart Feb 24, 2017

@lpw25

This comment has been minimized.

Show comment
Hide comment
@lpw25

lpw25 Feb 24, 2017

Contributor

I think that RTLD_DEEPBIND could still be useful for the loadfile_private case. Your problematic example relies on there being a module A in the non-private linked modules which has N in its interface dependencies. This can be avoided with the rules:

  • A module can only be linked publically if there is no other module with that name already linked publically

  • A module can only be linked privately if there is no other module with that name linked publically, or mentioned in the interface dependencies of a module linked publically.

This would be a useful rule to support (on platforms with RTLD_DEEPBIND or equivalent) since it allows you to load plugins without having to worry if they conflict with each other -- only whether they conflict with the main program.

Contributor

lpw25 commented Feb 24, 2017

I think that RTLD_DEEPBIND could still be useful for the loadfile_private case. Your problematic example relies on there being a module A in the non-private linked modules which has N in its interface dependencies. This can be avoided with the rules:

  • A module can only be linked publically if there is no other module with that name already linked publically

  • A module can only be linked privately if there is no other module with that name linked publically, or mentioned in the interface dependencies of a module linked publically.

This would be a useful rule to support (on platforms with RTLD_DEEPBIND or equivalent) since it allows you to load plugins without having to worry if they conflict with each other -- only whether they conflict with the main program.

@mshinwell

This comment has been minimized.

Show comment
Hide comment
@mshinwell

mshinwell Feb 24, 2017

Contributor

After looking at MPR#4208 it looks like the dynlink.ml code needs a bit more work, e.g. due to prohibit. It's also not immediately obvious whether loadfile_private is going to be safe at present even after MPR#4208 is fixed. The easiest solution seems like a separate table of all modules ever loaded, which I'll investigate in due course.

Contributor

mshinwell commented Feb 24, 2017

After looking at MPR#4208 it looks like the dynlink.ml code needs a bit more work, e.g. due to prohibit. It's also not immediately obvious whether loadfile_private is going to be safe at present even after MPR#4208 is fixed. The easiest solution seems like a separate table of all modules ever loaded, which I'll investigate in due course.

@mshinwell

This comment has been minimized.

Show comment
Hide comment
@mshinwell

mshinwell Feb 24, 2017

Contributor

@lpw25 Yes, perhaps the rules could be refined to take into account the private case. However it isn't clear to me whether it's worth spending the time to implement and test that, especially if it only works on a subset of platforms. At the least I think we should probably get the basic fix in first before relaxing it, given how long some of these issues have been open. Other opinions on the benefit of a more precise treatment would be welcome.

Contributor

mshinwell commented Feb 24, 2017

@lpw25 Yes, perhaps the rules could be refined to take into account the private case. However it isn't clear to me whether it's worth spending the time to implement and test that, especially if it only works on a subset of platforms. At the least I think we should probably get the basic fix in first before relaxing it, given how long some of these issues have been open. Other opinions on the benefit of a more precise treatment would be welcome.

@xavierleroy

This comment has been minimized.

Show comment
Hide comment
@xavierleroy

xavierleroy Feb 25, 2017

Contributor

Thanks for getting the ball rolling on this long-standing issue. Maybe @maximedenes and the Coq dev team wish to follow the discussion, as Coq is a heavy users of plugins that don't respect any naming discipline :-) and will be broken by the proposed solution.

Contributor

xavierleroy commented Feb 25, 2017

Thanks for getting the ball rolling on this long-standing issue. Maybe @maximedenes and the Coq dev team wish to follow the discussion, as Coq is a heavy users of plugins that don't respect any naming discipline :-) and will be broken by the proposed solution.

@maximedenes

This comment has been minimized.

Show comment
Hide comment
@maximedenes

maximedenes Feb 27, 2017

@xavierleroy thanks for drawing my attention to this patch. I don't expect so much trouble because nowadays, Coq plugins are packed (as in -pack). Not sure what happens when we play the same Require multiple times, though. I'll do a quick test and give feedback.

maximedenes commented Feb 27, 2017

@xavierleroy thanks for drawing my attention to this patch. I don't expect so much trouble because nowadays, Coq plugins are packed (as in -pack). Not sure what happens when we play the same Require multiple times, though. I'll do a quick test and give feedback.

@mshinwell

This comment has been minimized.

Show comment
Hide comment
@mshinwell

mshinwell Feb 27, 2017

Contributor

@maximedenes Do you use natdynlink or the bytecode version? If testing, it's probably best to use the native version with this patch at the moment, since the bytecode version may need a few tweaks (though it should approximately work).

Contributor

mshinwell commented Feb 27, 2017

@maximedenes Do you use natdynlink or the bytecode version? If testing, it's probably best to use the native version with this patch at the moment, since the bytecode version may need a few tweaks (though it should approximately work).

@maximedenes

This comment has been minimized.

Show comment
Hide comment
@maximedenes

maximedenes Feb 27, 2017

What is the easiest way to get camlp4/camlp5 compiled for ocaml with this patch? It is required for testing Coq plugins.

maximedenes commented Feb 27, 2017

What is the easiest way to get camlp4/camlp5 compiled for ocaml with this patch? It is required for testing Coq plugins.

@diml

This comment has been minimized.

Show comment
Hide comment
@diml

diml Mar 6, 2017

Member

@maximedenes, for camlp4 I think the easiest way it is build it by hand from the git repository

Member

diml commented Mar 6, 2017

@maximedenes, for camlp4 I think the easiest way it is build it by hand from the git repository

@mshinwell

This comment has been minimized.

Show comment
Hide comment
@mshinwell

mshinwell Apr 10, 2017

Contributor

@maximedenes Has there been any progress on testing this patch?

Contributor

mshinwell commented Apr 10, 2017

@maximedenes Has there been any progress on testing this patch?

@maximedenes

This comment has been minimized.

Show comment
Hide comment
@maximedenes

maximedenes Apr 10, 2017

Oh! I thought I had sent a partial report, sorry.

I could only devote a few minutes to it, but I can already say that this patch breaks the compilation of Coq's stdlib. It is surprising, but could be explained if the behavior of some static initializers (code like let _ = register... at toplevel in dynamically loaded units) has changed in some way.

I can investigate more and report next week.

maximedenes commented Apr 10, 2017

Oh! I thought I had sent a partial report, sorry.

I could only devote a few minutes to it, but I can already say that this patch breaks the compilation of Coq's stdlib. It is surprising, but could be explained if the behavior of some static initializers (code like let _ = register... at toplevel in dynamically loaded units) has changed in some way.

I can investigate more and report next week.

@mshinwell

This comment has been minimized.

Show comment
Hide comment
@mshinwell

mshinwell Apr 24, 2017

Contributor

@maximedenes Was that when running bytecode or native code?

Contributor

mshinwell commented Apr 24, 2017

@maximedenes Was that when running bytecode or native code?

@maximedenes

This comment has been minimized.

Show comment
Hide comment
@maximedenes

maximedenes Apr 25, 2017

I tested a bit more, and the incompatibility I was mentioning is in fact already present in the base commit of this PR (sorry, I should have checked earlier). So not directly related to this PR, but it prevents me from testing properly. I'll try with 4.05 beta 3 and a recent 4.06 to see if rebasing this PR could help.

maximedenes commented Apr 25, 2017

I tested a bit more, and the incompatibility I was mentioning is in fact already present in the base commit of this PR (sorry, I should have checked earlier). So not directly related to this PR, but it prevents me from testing properly. I'll try with 4.05 beta 3 and a recent 4.06 to see if rebasing this PR could help.

@maximedenes

This comment has been minimized.

Show comment
Hide comment
@maximedenes

maximedenes Apr 26, 2017

@mshinwell I was running native code.

The failure is in fact unrelated, so I'll try again with a rebased version of this PR.

So far, testing did reveal that we link twice a camlp5 module, but it is easy to fix on Coq's side.

maximedenes commented Apr 26, 2017

@mshinwell I was running native code.

The failure is in fact unrelated, so I'll try again with a rebased version of this PR.

So far, testing did reveal that we link twice a camlp5 module, but it is easy to fix on Coq's side.

@maximedenes

This comment has been minimized.

Show comment
Hide comment
@maximedenes

maximedenes Apr 26, 2017

Ok, so after rebasing, I confirm that modulo a small fix, Coq compiles fine with this PR, and plugins are usable. I tested only native code.

maximedenes commented Apr 26, 2017

Ok, so after rebasing, I confirm that modulo a small fix, Coq compiles fine with this PR, and plugins are usable. I tested only native code.

@mshinwell

This comment has been minimized.

Show comment
Hide comment
@mshinwell

mshinwell Apr 26, 2017

Contributor

OK, that's good news, thanks. I need to do some more careful work on the bytecode part of this PR, but will try to do that soon, and then it can be considered further.

Contributor

mshinwell commented Apr 26, 2017

OK, that's good news, thanks. I need to do some more careful work on the bytecode part of this PR, but will try to do that soon, and then it can be considered further.

@chambart

This comment has been minimized.

Show comment
Hide comment
@chambart

chambart May 2, 2017

Contributor

I did check various self loading situations and couldn't come up with any failing one. Not that there isn't any possibility, but this would certainly not appear by surprise.

Contributor

chambart commented May 2, 2017

I did check various self loading situations and couldn't come up with any failing one. Not that there isn't any possibility, but this would certainly not appear by surprise.

@chambart

This effectively checks the presence of previously loaded modules. A test exercising it might be useful. I can provide it.

@mshinwell

This comment has been minimized.

Show comment
Hide comment
@mshinwell

mshinwell May 2, 2017

Contributor

I actually noticed a bug in this and the bytecode version needed some more work (as per previous conversation with @chambart ). Whilst looking at that the large amount of duplicated code made me think that we can probably make this more robust with a bit more refactoring and sharing of code, which I'm working on now. I will post here again once it's ready.

Contributor

mshinwell commented May 2, 2017

I actually noticed a bug in this and the bytecode version needed some more work (as per previous conversation with @chambart ). Whilst looking at that the large amount of duplicated code made me think that we can probably make this more robust with a bit more refactoring and sharing of code, which I'm working on now. I will post here again once it's ready.

@mshinwell

This comment has been minimized.

Show comment
Hide comment
@mshinwell

mshinwell May 2, 2017

Contributor

@alainfrisch In the existing natdynlink.ml file there is a conditional which circumvents various checks if the name of a compilation unit being loaded happens to match the name of a predefined exception. Leo and I experimented with this and couldn't find why this restriction, which appears to introduce an unsoundness, would be required. Could you explain? (As far as I can tell from git this is your code.)

Contributor

mshinwell commented May 2, 2017

@alainfrisch In the existing natdynlink.ml file there is a conditional which circumvents various checks if the name of a compilation unit being loaded happens to match the name of a predefined exception. Leo and I experimented with this and couldn't find why this restriction, which appears to introduce an unsoundness, would be required. Could you explain? (As far as I can tell from git this is your code.)

@mshinwell mshinwell changed the title from Forbid dynlinking of previously-loaded units (MPR#4229, MPR#4839, MPR#6462, MPR#6957, MPR#6950) to Make (nat)dynlink sound (also fixes MPR#4229, MPR#4839, MPR#6462, MPR#6957, MPR#6950) May 2, 2017

@mshinwell

This comment has been minimized.

Show comment
Hide comment
@mshinwell

mshinwell May 5, 2017

Contributor

@chambart Would you be able to take a look at this version? This now passes the test suite although I need to do a pass of review myself. Adding the test case you suggest would be appreciated.

This pull request refactors the dynlink library by introducing a new Dynlink_common module. The implementation of this module is based on the old natdynlink implementation; in particular it uses maps rather than hashtables, which should solve MPR#4208. It has checks which should prevent a module being dynlinked if it is already loaded, which should solve the various other Mantis issues listed above. It does not contain the checks in the old natdynlink.ml concerning the names of exceptions, since they appear to be unsound.

This patch also removes the deprecated functions in the interface and the digest_interface internal function (I grepped OPAM for real uses of the latter and didn't find any). I haven't surveyed usage of the deprecated functions, but given that some of them appear to have been deprecated I think it was 15 years ago and others deprecated about 9 years ago, they seem ripe for removal.

I hope that overall this produces a significant increase in robustness and maintainability for this library.

I had a long struggle with the various makefiles and the requirement that programs using dynlink.cma don't need compilerlibs too. Care is thus taken to ensure that dynlink_common.ml only depends on the stdlib. The dynlink code is built no fewer than three times (in otherlibs/dynlink/, in driver/ and in debugger/)!

I would like to tidy the formatting of these files, which is currently rather inconsistent; this can be done as a separate changeset after the main review is done.

The diff for this PR is probably best read using patdiff.

Contributor

mshinwell commented May 5, 2017

@chambart Would you be able to take a look at this version? This now passes the test suite although I need to do a pass of review myself. Adding the test case you suggest would be appreciated.

This pull request refactors the dynlink library by introducing a new Dynlink_common module. The implementation of this module is based on the old natdynlink implementation; in particular it uses maps rather than hashtables, which should solve MPR#4208. It has checks which should prevent a module being dynlinked if it is already loaded, which should solve the various other Mantis issues listed above. It does not contain the checks in the old natdynlink.ml concerning the names of exceptions, since they appear to be unsound.

This patch also removes the deprecated functions in the interface and the digest_interface internal function (I grepped OPAM for real uses of the latter and didn't find any). I haven't surveyed usage of the deprecated functions, but given that some of them appear to have been deprecated I think it was 15 years ago and others deprecated about 9 years ago, they seem ripe for removal.

I hope that overall this produces a significant increase in robustness and maintainability for this library.

I had a long struggle with the various makefiles and the requirement that programs using dynlink.cma don't need compilerlibs too. Care is thus taken to ensure that dynlink_common.ml only depends on the stdlib. The dynlink code is built no fewer than three times (in otherlibs/dynlink/, in driver/ and in debugger/)!

I would like to tidy the formatting of these files, which is currently rather inconsistent; this can be done as a separate changeset after the main review is done.

The diff for this PR is probably best read using patdiff.

@mshinwell mshinwell changed the title from Make (nat)dynlink sound (also fixes MPR#4229, MPR#4839, MPR#6462, MPR#6957, MPR#6950) to Make (nat)dynlink sound (also fixes MPR#4208, MPR#4229, MPR#4839, MPR#6462, MPR#6957, MPR#6950) May 5, 2017

@alainfrisch

This comment has been minimized.

Show comment
Hide comment
@alainfrisch

alainfrisch May 9, 2017

Contributor

In the existing natdynlink.ml file there is a conditional which circumvents various checks if the name of a compilation unit being loaded happens to match the name of a predefined exception.

Probably some left over of a work-around required at that time, where builtin exception global identifiers were recorded in ui_imports_cmx.

FTR, this was introduced in:

http://caml.inria.fr/cgi-bin/viewvc.cgi/ocaml/branches/natdynlink/otherlibs/dynlink/natdynlink.ml?r1=7893&r2=7894&pathrev=8477&

apparently to make Camlp4 compile. This can probably go away now.

(On a related note: https://caml.inria.fr/mantis/view.php?id=3829 )

Contributor

alainfrisch commented May 9, 2017

In the existing natdynlink.ml file there is a conditional which circumvents various checks if the name of a compilation unit being loaded happens to match the name of a predefined exception.

Probably some left over of a work-around required at that time, where builtin exception global identifiers were recorded in ui_imports_cmx.

FTR, this was introduced in:

http://caml.inria.fr/cgi-bin/viewvc.cgi/ocaml/branches/natdynlink/otherlibs/dynlink/natdynlink.ml?r1=7893&r2=7894&pathrev=8477&

apparently to make Camlp4 compile. This can probably go away now.

(On a related note: https://caml.inria.fr/mantis/view.php?id=3829 )

@mshinwell

This comment has been minimized.

Show comment
Hide comment
@mshinwell

mshinwell May 9, 2017

Contributor

MPR#3829 appears fixed, so I've closed it. We also experimented the other day with various scenarios involving compilation units with the same names as predefined exceptions and couldn't get anything to fail.

Contributor

mshinwell commented May 9, 2017

MPR#3829 appears fixed, so I've closed it. We also experimented the other day with various scenarios involving compilation units with the same names as predefined exceptions and couldn't get anything to fail.

@alainfrisch

This comment has been minimized.

Show comment
Hide comment
@alainfrisch

alainfrisch May 9, 2017

Contributor

MPR#3829 is actually not fixed, I've reopened and added a slightly modified example.

Contributor

alainfrisch commented May 9, 2017

MPR#3829 is actually not fixed, I've reopened and added a slightly modified example.

@stedolan

This comment has been minimized.

Show comment
Hide comment
@stedolan

stedolan May 12, 2017

Contributor

It has previously been suggested that platform-dependent solutions such as RTLD_DEEPBIND on glibc systems might be sufficient to solve these problems. @chambart and I discussed this and it appears not to be the case: for example suppose there is some module N that generates fresh names. A depends on N in the main program. We dynlink B which also depends on N. Further, B passes values made in N to A. Whilst under RTLD_DEEPBIND the code of B successfully references its own copy of N, it passes values to A that could break invariants of A's copy of N if they were to flow into there---and they might. It seems safer to just be conservative.

This explains why it is wrong for a dynlinked plugin to contain a copy of a module that is part of the main program. What about the case when two dynlinked plugins both contain a copy of the same module, which the main program does not contain? I would expect this to work when I load the plugins via Dynlink.loadfile_private - that seems to be what this function is for.

Does this patch support such usage?

Contributor

stedolan commented May 12, 2017

It has previously been suggested that platform-dependent solutions such as RTLD_DEEPBIND on glibc systems might be sufficient to solve these problems. @chambart and I discussed this and it appears not to be the case: for example suppose there is some module N that generates fresh names. A depends on N in the main program. We dynlink B which also depends on N. Further, B passes values made in N to A. Whilst under RTLD_DEEPBIND the code of B successfully references its own copy of N, it passes values to A that could break invariants of A's copy of N if they were to flow into there---and they might. It seems safer to just be conservative.

This explains why it is wrong for a dynlinked plugin to contain a copy of a module that is part of the main program. What about the case when two dynlinked plugins both contain a copy of the same module, which the main program does not contain? I would expect this to work when I load the plugins via Dynlink.loadfile_private - that seems to be what this function is for.

Does this patch support such usage?

@mshinwell

This comment has been minimized.

Show comment
Hide comment
@mshinwell

mshinwell May 24, 2017

Contributor

I've noticed that an important piece of this patch appears to be missing; I will fix that and then think further about @stedolan 's comment. (I think the answer is that we could support such uses so long as the platform supports RTLD_DEEPBIND.)

Contributor

mshinwell commented May 24, 2017

I've noticed that an important piece of this patch appears to be missing; I will fix that and then think further about @stedolan 's comment. (I think the answer is that we could support such uses so long as the platform supports RTLD_DEEPBIND.)

@stedolan

This comment has been minimized.

Show comment
Hide comment
@stedolan

stedolan May 24, 2017

Contributor

I think the answer is that we could support such uses so long as the platform supports RTLD_DEEPBIND.

I don't understand why RTLD_DEEPBIND is needed for the usage I described. Why isn't the standard flag RTLD_LOCAL (which is the default behaviour of dlopen, and currently used by loadfile_private) sufficient?

Contributor

stedolan commented May 24, 2017

I think the answer is that we could support such uses so long as the platform supports RTLD_DEEPBIND.

I don't understand why RTLD_DEEPBIND is needed for the usage I described. Why isn't the standard flag RTLD_LOCAL (which is the default behaviour of dlopen, and currently used by loadfile_private) sufficient?

@mshinwell

This comment has been minimized.

Show comment
Hide comment
@mshinwell

mshinwell May 24, 2017

Contributor

I was kind of thinking you'd want complete isolation, so that if the plugin defined some other module that happens to be in the main program, there wouldn't be a clash. I think you need RTLD_DEEPBIND for that, but if you're willing to live without that, we could have an intermediate level of isolation (perhaps the default) whereby plugins may contain modules that aren't in the main program but do clash on names across plugins. That seems fine.

Contributor

mshinwell commented May 24, 2017

I was kind of thinking you'd want complete isolation, so that if the plugin defined some other module that happens to be in the main program, there wouldn't be a clash. I think you need RTLD_DEEPBIND for that, but if you're willing to live without that, we could have an intermediate level of isolation (perhaps the default) whereby plugins may contain modules that aren't in the main program but do clash on names across plugins. That seems fine.

@lpw25

This comment has been minimized.

Show comment
Hide comment
@lpw25

lpw25 May 24, 2017

Contributor

I think if you allow multiple plugins containing modules with the same name then you'll need a slightly stricter check. At the moment the check prevents you from loading a module with the same name as one that was linked into the main program, but I think you would need to expand that to include any modules "imported" by the main program but not actually linked.

For example, the main program might have a module A containing a value r with type B.t ref even though the program does not link B into it. In this case, two plugins might both have different B modules (with the same .cmi digest but different implementations) and put different types of values into r.

Contributor

lpw25 commented May 24, 2017

I think if you allow multiple plugins containing modules with the same name then you'll need a slightly stricter check. At the moment the check prevents you from loading a module with the same name as one that was linked into the main program, but I think you would need to expand that to include any modules "imported" by the main program but not actually linked.

For example, the main program might have a module A containing a value r with type B.t ref even though the program does not link B into it. In this case, two plugins might both have different B modules (with the same .cmi digest but different implementations) and put different types of values into r.

This has been completely reworked; we need to review from scratch

@mshinwell

This comment has been minimized.

Show comment
Hide comment
@mshinwell

mshinwell Jun 29, 2017

Contributor

I think this is now ready for a first pass of code review. @lpw25 has volunteered. Some of the main features:

  • It should now be sound. Lots of tricky cases have been carefully thought about.
  • Much code has been shared between bytecode and native dynlink, with some error messages harmonised too.
  • A fix for a self-initialization problem in natdynlink (when a main program loads a plugin P which has an initializer that loads a plugin Q which in turn has an initializer that references P).
  • An improved interface for access control.
  • The long-deprecated functions have been removed.

Where possible I have added the test cases from the various Mantis issues about dynlink to the testsuite. They are all run both for bytecode and native even if the original reporters did not do so.

Contributor

mshinwell commented Jun 29, 2017

I think this is now ready for a first pass of code review. @lpw25 has volunteered. Some of the main features:

  • It should now be sound. Lots of tricky cases have been carefully thought about.
  • Much code has been shared between bytecode and native dynlink, with some error messages harmonised too.
  • A fix for a self-initialization problem in natdynlink (when a main program loads a plugin P which has an initializer that loads a plugin Q which in turn has an initializer that references P).
  • An improved interface for access control.
  • The long-deprecated functions have been removed.

Where possible I have added the test cases from the various Mantis issues about dynlink to the testsuite. They are all run both for bytecode and native even if the original reporters did not do so.

@mshinwell mshinwell requested a review from lpw25 Jun 29, 2017

mshinwell added some commits Jun 29, 2017

upon by either the main program or a previously-loaded shared library.
This applies even if such dependency is only a "module alias" dependency
(i.e. just on the name rather than the contents of an interface).

This comment has been minimized.

@bobot

bobot Jun 29, 2017

Contributor

An example of what can be done with loadfile_private and what can't would help to understand this paragraph.

@bobot

bobot Jun 29, 2017

Contributor

An example of what can be done with loadfile_private and what can't would help to understand this paragraph.

@xavierleroy

This comment has been minimized.

Show comment
Hide comment
@xavierleroy

xavierleroy Sep 23, 2017

Contributor

What's the status on this PR? Could we plan it for 4.07?

Contributor

xavierleroy commented Sep 23, 2017

What's the status on this PR? Could we plan it for 4.07?

@mshinwell

This comment has been minimized.

Show comment
Hide comment
@mshinwell

mshinwell Sep 25, 2017

Contributor

@xavierleroy Sure. @lpw25 is going to review it when he's back from vacation.

Contributor

mshinwell commented Sep 25, 2017

@xavierleroy Sure. @lpw25 is going to review it when he's back from vacation.

@damiendoligez damiendoligez added this to the 4.07-or-later milestone Sep 25, 2017

@xavierleroy

This comment has been minimized.

Show comment
Hide comment
@xavierleroy

xavierleroy Dec 20, 2017

Contributor

This GPR is slowly rotting away (no action since Sept), and that's sad because it's addressing a very serious issue. Could we please have @lpw25's review and perhaps some more eyeballing as well?

Contributor

xavierleroy commented Dec 20, 2017

This GPR is slowly rotting away (no action since Sept), and that's sad because it's addressing a very serious issue. Could we please have @lpw25's review and perhaps some more eyeballing as well?

@lpw25

This comment has been minimized.

Show comment
Hide comment
@lpw25

lpw25 Dec 21, 2017

Contributor

I should have time in January to look at this. Anyone else should feel free to review before then if they have the time.

Contributor

lpw25 commented Dec 21, 2017

I should have time in January to look at this. Anyone else should feel free to review before then if they have the time.

@XVilka

This comment has been minimized.

Show comment
Hide comment
@XVilka

XVilka Feb 9, 2018

Are there any updates on this one?

XVilka commented Feb 9, 2018

Are there any updates on this one?

@mshinwell

This comment has been minimized.

Show comment
Hide comment
@mshinwell

mshinwell Feb 12, 2018

Contributor

It really is on the stack for review soon; unfortunately some important type system related work scheduled for 4.07 is getting in the way.

Contributor

mshinwell commented Feb 12, 2018

It really is on the stack for review soon; unfortunately some important type system related work scheduled for 4.07 is getting in the way.

@lpw25

I've reviewed this now. There were a few things that needed changing in order to match the specification in Mark's description. I've turned these changes into a pull request against this branch (mshinwell#10). Once Mark has reviewed and merged those changes into this PR then I think it is ready to be merged upstream.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment