Joachim Breitner
Hi,
Am Montag, den 15.12.2014, 10:58 -0500 schrieb Ben Gamari:
- Travis has not picked up on these errors.
unfortunately, travis is slighly less useful since a few weeks due to T5681 failing (possibly due to the use of LLVM-3.4), but I’m still waiting for an reply on that issue.
You aren't looking for a response from me on this, are you? I just checked and I don't seem to have any outstanding messages from you but it's entirely possible I overlooked something.
this is independent of our arm issues, and I think a tad older; I did not direct it to anyone specific.
But I guess you are likely a person that can tell what’s wrong here:
Am Sonntag, den 30.11.2014, 20:01 +0100 schrieb Joachim Breitner:
Compile failed (status 256) errors were: /tmp/ghc16123_0/ghc16123_5.s: Assembler messages:
/tmp/ghc16123_0/ghc16123_5.s:26:0: Error: can't resolve `.rodata' {.rodata section} - `Main_zdwwork_info$def' {.text section}
/tmp/ghc16123_0/ghc16123_5.s:46:0: Error: can't resolve `.rodata' {.rodata section} - `Main_work_info$def' {.text section}
/tmp/ghc16123_0/ghc16123_5.s:66:0: Error: can't resolve `.rodata' {.rodata section} - `Main_main1_info$def' {.text section}
/tmp/ghc16123_0/ghc16123_5.s:86:0: Error: can't resolve `.rodata' {.rodata section} - `Main_main_info$def' {.text section}
/tmp/ghc16123_0/ghc16123_5.s:106:0: Error: can't resolve `.rodata' {.rodata section} - `Main_main2_info$def' {.text section}
/tmp/ghc16123_0/ghc16123_5.s:126:0: Error: can't resolve `.rodata' {.rodata section} - `ZCMain_main_info$def' {.text section}
*** unexpected failure for T5681(optllvm)
https://s3.amazonaws.com/archive.travis-ci.org/jobs/42557559/log.txt
Any ideas?
Is it possible that this is due the llvm version used? Do we support 3.4 in GHC HEAD?
Using LLVM tools llc : /usr/local/clang-3.4/bin/llc opt : /usr/local/clang-3.4/bin/opt
(http://smart-cactus.org/~ben/posts/2014-11-28-state-of-llvm-backend.html does not talk about GHC HEAD explicitly. Should I look at the 7.10 row? Does that mean that 3.4 is not supported? Shouldn’t the build system, or at least the compiler, fail harder and more helpfully in this case?)
LLVM 3.4 appears to have an unfortunate behavior whereby it will lose track of which section symbols with Internal linkage belong. I haven't had a chance to delve into this too deeply, however given that both 3.3 and 3.5 behave as expected I'm pretty sure this a bug. There are a few options here, a. Mark the `$def` symbols as ExternallyVisible, working around the issue at the expense of exposing internal symbols to the outside world. b. Mark LLVM 3.4 as unsupported At the moment I'm leaning towards (b) since I haven't had a chance to think through the implications of (a); if nothing else I suspect this wouldn't help the DLL symbol table size issues on Windows. Giving up on LLVM 3.4 might be unfortunate for a good number of users, however. Ultimately this underlines the need to package LLVM with GHC. Cheers, - Ben