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

ocamlopt generates bad executable #5919

Closed
vicuna opened this issue Feb 12, 2013 · 7 comments
Closed

ocamlopt generates bad executable #5919

vicuna opened this issue Feb 12, 2013 · 7 comments

Comments

@vicuna
Copy link

vicuna commented Feb 12, 2013

Original bug ID: 5919
Reporter: zhihan
Assigned to: meyer
Status: closed (set by meyer on 2013-06-03T19:37:10Z)
Resolution: unable to duplicate
Priority: normal
Severity: crash
Platform: Linux
OS: Debian Linux 6 64-bit
OS Version: Debian 6
Version: 3.12.1
Category: -for ocamlbuild use https://github.com/ocaml/ocamlbuild/issues

Bug description

This is related to

#5474&history=1#history

But I am able to produce both good and bad executables. The only difference is the setting of "PATH" environment variable. Here is what I observed: suppose my ocaml is installed at /<path_to>/ocaml

If I add '/<path_to>/ocaml/bin' to my PATH and then invoke ocamlbuild.native, it creates an executable that seg faults. If I unset the PATH and use '/<path_to>/ocaml/bin/ocamlbuild' to build the target, it is a good executable.

File attachments

@vicuna
Copy link
Author

vicuna commented Feb 13, 2013

Comment author: zhihan

I did a little bit further investigation myself. I used readelf to disassemble the two files. Among the differences, this one might be related.
In the 'bad' file produced from ocamlopt, the relocation address of 'strcmp' and 'strcpy' are placed in the '.rela.dyn' section, while in the 'good' file these relocations are placed in the '.rela.plt' section.

According to resources on the internet, '.rela.plt' should hold relocation addresses for C functions and '.rela.dyn' should hold for data. In this regard, the relocation addresses of 'strcpy' is placed in the wrong section. Might it be the cause the seg fault?

@vicuna
Copy link
Author

vicuna commented Feb 13, 2013

Comment author: meyer

The reason for that is that ocamlbuild might pick the wrong compiler. Ocamlbuild tries to use not the compiler on path but the one it's being rooted.

Therefore:
if /usr/local/bin/ocamlbuild.native is present it will always pick the /usr/local/ocamlc and not the one pointed by PATH.

Please double check if you didn't hit that problem, perhaps you have several incompatible ocaml installations.

What will happen if you compile the program manually?

@vicuna
Copy link
Author

vicuna commented Feb 13, 2013

Comment author: meyer

the tarball you've attached cannot be opened. Please re-attach a right tarball.

@vicuna
Copy link
Author

vicuna commented Feb 13, 2013

Comment author: zhihan

So I should use the '-ocamlopt' option to make sure the right compiler is invoked?

@vicuna
Copy link
Author

vicuna commented Feb 13, 2013

Comment author: meyer

Unfortunately yes, that's the only way you can change it.

The trunk of the toolchain, if you wish to try dev version, contains also -which flag which will tell you what's being picked up. You can also use -verbose 100 which will show you the commands being invoked. Please make sure if you swap a compiler to use -clean flag before.

If you are not forced to use 3.12.1 compiler, I'd strongly advise to try 4.00.1. The easiest way to get the system working is via OPAM.

@vicuna
Copy link
Author

vicuna commented Mar 24, 2013

Comment author: @xavierleroy

So, do we have enough info on this PR to see if something needs to be done? W. Meyer wisely suggests to use a clean 4.00.1 installation. If this is enough to solve the problem, I move to close this PR.

@vicuna
Copy link
Author

vicuna commented Jun 3, 2013

Comment author: meyer

The explanation given should suffice to fix the problem, so just closing this defect too.

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

No branches or pull requests

1 participant