|Anonymous | Login | Signup for a new account||2019-02-24 02:39 CET|
|Main | My View | View Issues | Change Log | Roadmap|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0005921||OCaml||~DO NOT USE (was: OCaml general)||public||2013-02-13 18:03||2015-12-11 19:29|
|Platform||OS||MacOS X||OS Version||10.8|
|Target Version||4.02.2+dev / +rc1||Fixed in Version||4.01.0|
|Summary||0005921: 4.01.0dev emits compact unwind warnings since switch to clang|
|Description||On latest MacOS X and trunk, any invocation of the linker results in warnings such as:|
ld: warning: could not create compact unwind for _camlTypecore__add_pattern_variables_1925: stack subq instruction is too different from dwarf stack size
ld: warning: could not create compact unwind for _camlTypecore__type_pattern_1937: stack subq instruction is too different from dwarf stack size
ld: warning: could not create compact unwind for _camlTypecore__type_pattern_list_1949: stack subq instruction is too different from dwarf stack size
ld: warning: could not create compact unwind for _camlTypecore__type_class_arg_pattern_1959: stack subq instruction is too different from dwarf stack size
ld: warning: could not create compact unwind for _camlTypecore__mkpat_1981: stack subq instruction is too different from dwarf stack size
The warnings can be suppressed by passing -no-compact-unwind to the linker:
@@ -734,7 +734,8 @@ case "$arch,$nativecc,$system,$host_type" in
*,*,rhapsody,*) nativecccompopts="$gcc_warnings -DDARWIN_VERSION_6 $dl_defs"
if $arch64; then partialld="ld -r -arch ppc64"; fi;;
*,gcc*,cygwin,*) nativecccompopts="$gcc_warnings -U_WIN32";;
- amd64,gcc*,macosx,*) partialld="ld -r -arch x86_64";;
+ amd64,gcc*,macosx,*) partialld="ld -r -arch x86_64"
amd64,gcc*,solaris,*) partialld="ld -r -m elf_x86_64";;
but I've not got an older 10.6/7 to see if this breaks anything there. Although I notice that trunk is also broken on 10.6 due to http://caml.inria.fr/mantis/view.php?id=5912 [^]
The above patch also still results in relocation warnings while bootstrapping the compiler.
|Steps To Reproduce||$ echo 'let _ = Printf.printf "foo%!"' > test.ml|
$ ocamlopt -linkall test.ml
<warnings result on MacOS X 10.8>
Reproduced on 10.7.5 with Xcode 4.5.1.
Your patch doesn't work (at least on my machine) because this part of the configuration script is totally messed up: the nativecccompopts variable is not used to link native executables.
We will need to clean up the configuration script and the "driver" part of the compilers.
In fact, $nativecccompopts is not used for linking executables. Nor is $nativecclinkopts (this is used only with ld for packing libraries). The flag must be put into both $mksharedlib and $mkexe.
I've done that and the warning disappeared (commit 13423 in trunk). Not tested on earlier versions of XCode. If they break and someone cares, we'll probably have to test for the presence of "clang" in the path before we add this flag.
This warning is now gone with 4.01.0 on Xcode 5 / OS X 10.9, without any patch.
However, we now have another rather abundant noisy warning:
ocamlfind ocamlc cpdflibwrapper.c;
clang: warning: argument unused during compilation: '-fno-defer-pop'
|I think just silencing these warnings may have been a mistake; it might indicate an error in the DWARF information emitted by the OCaml compiler. I am going to investigate further later this week, since there has been recent evidence of problems in this area.|
I looked into this further. The problem appears to arise from code in the OS X linker that attempts to synthesize compact unwind sections from DWARF CFA information. I didn't manage to understand completely how it works, but I'm fairly sure it's tripping up on the OCaml CFA information because we don't have any callee-save registers.
There is a comment in recent versions of libunwind that suggests the OS X linker has stopped this behaviour since it is fragile (no surprises there). It wasn't clear from the latest version of the ld64 source code I looked at that this was the case, however. In any event, I think keeping compact unwind section generation disabled is the correct thing to do. If in future we wish to revisit this, the correct solution is very likely to have the OCaml compiler emit the compact unwind information directly. Then there should be no misunderstandings.
|2013-02-13 18:03||avsm||New Issue|
|2013-02-26 13:43||doligez||Note Added: 0008929|
|2013-02-26 13:43||doligez||Status||new => confirmed|
|2013-03-22 18:59||doligez||Note Added: 0009002|
|2013-03-22 18:59||doligez||Status||confirmed => resolved|
|2013-03-22 18:59||doligez||Resolution||open => fixed|
|2013-11-14 12:25||johnwhitington||Note Added: 0010635|
|2014-06-11 17:41||shinwell||Note Added: 0011742|
|2014-06-11 17:41||shinwell||Assigned To||=> shinwell|
|2014-06-11 17:41||shinwell||Status||resolved => assigned|
|2014-06-11 17:42||shinwell||Resolution||fixed => open|
|2014-06-11 17:42||shinwell||Target Version||=> 4.02.0+dev|
|2014-07-31 16:45||doligez||Tag Attached: patch|
|2014-07-31 16:59||doligez||Target Version||4.02.0+dev => 4.02.1+dev|
|2014-09-04 00:25||doligez||Target Version||4.02.1+dev => undecided|
|2014-09-24 19:40||doligez||Target Version||undecided => 4.02.2+dev / +rc1|
|2015-05-07 17:54||shinwell||Note Added: 0013867|
|2015-05-07 17:59||shinwell||Status||assigned => resolved|
|2015-05-07 17:59||shinwell||Fixed in Version||=> 4.01.0|
|2015-05-07 17:59||shinwell||Resolution||open => fixed|
|2015-12-11 19:29||xleroy||Status||resolved => closed|
|2017-02-23 16:36||doligez||Category||OCaml general => -OCaml general|
|2017-03-03 17:55||doligez||Category||-OCaml general => -(deprecated) general|
|2017-03-03 18:01||doligez||Category||-(deprecated) general => ~deprecated (was: OCaml general)|
|2017-03-06 17:04||doligez||Category||~deprecated (was: OCaml general) => ~DO NOT USE (was: OCaml general)|
|Copyright © 2000 - 2011 MantisBT Group|