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

New mode where ocamlc doesn't check list of primitives #6845

Closed
vicuna opened this issue Apr 22, 2015 · 18 comments
Closed

New mode where ocamlc doesn't check list of primitives #6845

vicuna opened this issue Apr 22, 2015 · 18 comments
Assignees
Labels
Milestone

Comments

@vicuna
Copy link

vicuna commented Apr 22, 2015

Original bug ID: 6845
Reporter: @alainfrisch
Assigned to: @damiendoligez
Status: closed (set by @xavierleroy on 2017-02-16T14:16:17Z)
Resolution: fixed
Priority: low
Severity: minor
Target version: 4.03.0+dev / +beta1
Fixed in version: 4.02.2+dev / +rc1
Category: ~DO NOT USE (was: OCaml general)
Related to: #6693 #6733 #6779
Monitored by: @gasche @hcarty

Bug description

By default, ocamlc checks that all primitives used by the linked bytecode program are defined in the target runtime (the default list of primitives by default, an explicit list provided by the undocumented -use-prims option, or the list of primitives obtained from the -use-runtime). In -custom mode, no check is required, since a specific runtime with exactly the required primitives will be created (and the C compiler will complain if some primitives are not available).

For js_of_ocaml. it would make sense to have another mode, similar to -custom in that no check is done at link time, but without actually creating a custom runtime. The rationale is that the js_of_ocaml compiler will itself report warnings for missing primitives (and the program could even work with a missing primitive, if it is not actually called, or if the call is properly protected).

The current possible workarounds are either to create dummy C stubs to make ocamlc happy, or to rely on -use-prims (which requires to create the full list of primitives, the builtin ones + our custom primitives). In both cases, this is not very practical.

Proposal: -no-check-prims

@vicuna
Copy link
Author

vicuna commented Apr 22, 2015

Comment author: @alainfrisch

Committed to trunk, rev 16031. Will revert if people object to it.

@vicuna
Copy link
Author

vicuna commented Apr 22, 2015

Comment author: @gasche

I think this was also discussed in the context of cross-compilation, but I don't know if what you suggest is exactly what adrien/whitequark had in mind or if they need something else.

@vicuna
Copy link
Author

vicuna commented Apr 22, 2015

Comment author: @whitequark

Based on the patch this should fix 6779, but I have not yet ran any code.

Wish: be able to somehow activate this for all ocamlc invocations by default (might be better handled with ocamlfind, I'm not sure).

@vicuna
Copy link
Author

vicuna commented Apr 23, 2015

Comment author: adrien

Xavier Leroy had expressed his interest that some checks still be done for this case but it's definitely a complex task which I don't see done soon.

Providing a list of primitives doesn't seem like a possible option either since there would be many of them for any non-trivial program. (I don't even know if it'd avoid the issue when doing cross rather than ocamlc for js_of_ocaml actually)

I don't see a solution to that issue that is not what this patch does: allow to disable the checks.

As whitequark mentioned, this needs to be a option that can be on by default. It's been quite some time since I looked at that but the best place is probably in the compiler configuration, i.e. utils/config.{mlp,mlbuild}.

I guess you also want the command-line option for js_of_ocaml.

I don't know how whitequark typically builds for cross. I make a complete toolchain as this avoids hard-to-spot mix of incompatible toolchains (I would spot it easily; 99% of people wouldn't) but maybe he tries hard to build only the minimum set of binaries needed.

@vicuna
Copy link
Author

vicuna commented Apr 23, 2015

Comment author: @whitequark

I use opam-android1. It requests a 32-bit host ocamlc of a matching version (native or multilib) and builds everything else from scratch.

config.mlp is pretty much what I was thinking about.

@vicuna
Copy link
Author

vicuna commented Apr 23, 2015

Comment author: @whitequark

As discussed elsewhere, XL's request could be fulfilled by using libbfd in an external binary to extract the relevant list of primitives from the runtime and dllibs. I wouldn't call it complex, though it is certainly more expensive to implement than the current few-line patch.

@vicuna
Copy link
Author

vicuna commented Apr 23, 2015

Comment author: adrien

I remember the external binary solution being mentioned now. We can probably find something that already does 80% of the job somewhere, especially since for cross-compilation there will always be an extra "packaging" step (and if I had something to find 1% more bugs from the compilation machine, without touching the target, I'd definitely use it).

Also, libbfd is GPL as far as I remember so that really needs an extra binary.

@vicuna
Copy link
Author

vicuna commented Apr 23, 2015

Comment author: @whitequark

Invoke nm? Quite a few tools seem to parse nm output, so it can probably be considered stable in that regard. Also, present on BSDs without GNU tools.

@vicuna
Copy link
Author

vicuna commented Apr 29, 2015

Comment author: @damiendoligez

I have one question for @whitequark and @adrien: is this really the last thing that's needed for cross-compilation to work well on 4.02.2? If so, we should soon decide if we want to cherry-pick this change.

@vicuna
Copy link
Author

vicuna commented Apr 29, 2015

Comment author: @whitequark

Along with all the other issues I submitted, this should be enough for support in opam-android. The main two remaining issues are the need for matching bitness and lack of working configure.

@vicuna
Copy link
Author

vicuna commented Apr 29, 2015

Comment author: @gasche

whitequark, if some of those issues that have not been handled appropriately yet, now may be a good time to list them and demand prompter resolution. I don't have long-term visibility on these issues; I have none of them in my current queue of things that can be merged without much work on my part, but maybe they just slipped through.

(I do remember one ocamlbuild-related change was reverted from 4.02 because it broke oasis, so I guess one conclusion is that 4.02 won't be quite there.)

@vicuna
Copy link
Author

vicuna commented Apr 29, 2015

Comment author: @whitequark

These issues are:

I've pinged 6693 for three months despite there being a patch available and no objections were ever voiced. It's been now five. I am out of polite words to describe that.

@vicuna
Copy link
Author

vicuna commented May 12, 2015

Comment author: @damiendoligez

backported to branch 4.02 (rev 16115)

@vicuna
Copy link
Author

vicuna commented May 12, 2015

Comment author: @damiendoligez

keep open for cross-compilation: check primitives by calling nm or some other tool.

@vicuna
Copy link
Author

vicuna commented Jul 28, 2015

Comment author: @alainfrisch

The related tickets listed by whitequark are now marked as resolved. Can we close this ticket as well? (or otherwise, perhaps open a new meta-ticket for remaining cross-compilation issues?)

@vicuna
Copy link
Author

vicuna commented Jul 28, 2015

Comment author: @whitequark

I think Damien's point is that we should still check primitives during cross-compilation, but by shelling out to nm instead of using dlsym, and the current behavior is not satisfactory.

@vicuna
Copy link
Author

vicuna commented Jul 28, 2015

Comment author: @alainfrisch

we should still check primitives during cross-compilation, but by shelling out to nm instead of using dlsym

I see, but this is not directly related to this ticket, which is about disabling this check (in particular for js_of_ocaml, which can be counted as cross-compilation, but where the "nm" approach is not appropriate).

@vicuna
Copy link
Author

vicuna commented Jul 28, 2015

Comment author: @whitequark

Ah, makes sense. I think a new ticket for nm as well as an umbrella one for cross-compilation sounds nice.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants