[GHC] #14291: Tests tend to fail in the ext-interp when testing a tree built with a source distribution
#14291: Tests tend to fail in the ext-interp when testing a tree built with a
source distribution
-------------------------------------+-------------------------------------
Reporter: bgamari | Owner: (none)
Type: bug | Status: new
Priority: normal | Milestone: 8.4.1
Component: Compiler | Version: 8.2.1
Keywords: | Operating System: Unknown/Multiple
Architecture: | Type of failure: None/Unknown
Unknown/Multiple |
Test Case: | Blocked By:
Blocking: | Related Tickets:
Differential Rev(s): | Wiki Page:
-------------------------------------+-------------------------------------
One issue I've noticed while working on #13716 is that most (if not all)
of the tests runs in the `ext-interp` way fail when run inside a tree
derived from a source distribution tarball. For instance,
{{{
$ git clone git://git.haskell.org/ghc
$ cd ghc
$ git submodule update --init
$ mk/get-win32-tarballs.sh download all
$ ./boot
$ ./configure
$ make sdist
$ mkdir tmp; cd tmp
$ ls ../sdistprep/ghc-*-src.tar.xz | xargs -n1 tar -xf
$ cd ghc-*
$ ./boot
$ ./configure
$ make -j9
$ make test TEST=T10638
...
=====> T10638(normal) 1 of 1 [0, 0, 0]
cd "./th/T10638.run" && "/mnt/work/ghc/ghc-
testing/temp/ghc-8.3.20170927/inplace/bin/ghc-stage2" -c T10638.hs -dcore-
lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-
specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-
diagnostics-show-caret -dno-debug-output -XTemplateHaskell -package
template-haskell -v0
=====> T10638(ext-interp) 1 of 1 [0, 0, 0]
cd "./th/T10638.run" && "/mnt/work/ghc/ghc-
testing/temp/ghc-8.3.20170927/inplace/bin/ghc-stage2" -c T10638.hs -dcore-
lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-
specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-
diagnostics-show-caret -dno-debug-output -XTemplateHaskell -package
template-haskell -fexternal-interpreter -v0
Actual stderr output differs from expected:
diff -uw "./th/T10638.run/T10638.stderr.normalised"
"./th/T10638.run/T10638.comp.stderr.normalised"
--- ./th/T10638.run/T10638.stderr.normalised 2017-09-27
12:18:45.737974039 -0400
+++ ./th/T10638.run/T10638.comp.stderr.normalised 2017-09-27
12:18:45.737974039 -0400
@@ -1,5 +1,18 @@
+ghc-iserv.bin: internal evacuate(static): strange closure type 16476
+ (GHC version 8.3.20170927 for x86_64_unknown_linux)
+ Please report this as a GHC bug:
http://www.haskell.org/ghc/reportabug
-T10638.hs:26:11:
- ‘static test2’ is not a valid C identifier
- When checking declaration:
- foreign import prim safe "static test2" cmm_test2 :: Int# -> Int#
+T10638.hs:26:9:
+ Exception when trying to run compile-time code:
+ {handle:
#14291: Tests tend to fail in the ext-interp when testing a tree built with a source distribution -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 13716 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Well, unsurprisingly, the culprit is actually not the fact that the compiler was built from a source tarball. Doing the build on the git tree gives the same result. I suspect the problem is rather that the `validate` build flavour isn't being used since I didn't provide a `build.mk`. Here are some relevant settings from the two configurations, No `build.mk`: {{{ DYNAMIC_BY_DEFAULT="NO" DYNAMIC_GHC_PROGRAMS="YES" GhcLibHcOpts="-O2" GhcRtsCcOpts="-O2 -fomit-frame-pointer -g" GhcRtsHcOpts="-O2 -Wcpp-undef" GhcStage1HcOpts=" -Wcpp-undef" GhcStage2HcOpts="-O2 -Wcpp-undef" SplitObjs="NO" SplitSections="YES" SRC_HC_OPTS="-H32m -O -Wall" SRC_HC_OPTS_STAGE1=" " }}} Validate: {{{ DYNAMIC_BY_DEFAULT="NO" DYNAMIC_GHC_PROGRAMS="YES" GhcLibHcOpts="-O -dcore-lint -dno-debug-output" GhcRtsCcOpts="-O2 -fomit-frame-pointer -g" GhcRtsHcOpts="-O2" GhcStage1HcOpts="-O -DDEBUG" GhcStage2HcOpts="-O -dcore-lint -dno-debug-output" SplitObjs="NO" SplitSections="NO" SRC_HC_OPTS="-O0 -H64m -Wall" SRC_HC_OPTS_STAGE1="-fllvm-fill-undef-with-garbage -Werror" }}} These differ as follows, {{{#!diff --- good 2017-09-27 13:27:52.809897224 -0400 +++ bad 2017-09-27 13:28:01.425893705 -0400 @@ -1,11 +1,11 @@ DYNAMIC_BY_DEFAULT="NO" DYNAMIC_GHC_PROGRAMS="YES" -GhcLibHcOpts="-O -dcore-lint -dno-debug-output" +GhcLibHcOpts="-O2" GhcRtsCcOpts="-O2 -fomit-frame-pointer -g" -GhcRtsHcOpts="-O2" -GhcStage1HcOpts="-O -DDEBUG" -GhcStage2HcOpts="-O -dcore-lint -dno-debug-output" +GhcRtsHcOpts="-O2 -Wcpp-undef" +GhcStage1HcOpts=" -Wcpp-undef" +GhcStage2HcOpts="-O2 -Wcpp-undef" SplitObjs="NO" -SplitSections="NO" -SRC_HC_OPTS="-O0 -H64m -Wall" -SRC_HC_OPTS_STAGE1="-fllvm-fill-undef-with-garbage -Werror" +SplitSections="YES" +SRC_HC_OPTS="-H32m -O -Wall" +SRC_HC_OPTS_STAGE1=" " }}} There are a number of differences here. However, what catches my eye most is `SplitSections` since this sort of crash is often due to linker issues. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14291#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#14291: Tests tend to fail in the ext-interp when testing a tree built with a source distribution -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 13716 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Indeed `SplitSections` is the culprit. It seems enabling `SplitSections` breaks `ext-interp`. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14291#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#14291: Tests tend to fail in the ext-interp when testing a tree built with a source distribution -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 13716 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): In particular only the statically-linked `iserv` is affected. `ghci -dynamic -fexternal-interpreter` appears to work fine. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14291#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#14291: Tests tend to fail in the ext-interp way when split sections is enabled -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 13716 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by bgamari: Old description:
One issue I've noticed while working on #13716 is that most (if not all) of the tests runs in the `ext-interp` way fail when run inside a tree derived from a source distribution tarball. For instance, {{{ $ git clone git://git.haskell.org/ghc $ cd ghc $ git submodule update --init $ mk/get-win32-tarballs.sh download all $ ./boot $ ./configure $ make sdist $ mkdir tmp; cd tmp $ ls ../sdistprep/ghc-*-src.tar.xz | xargs -n1 tar -xf $ cd ghc-* $ ./boot $ ./configure $ make -j9 $ make test TEST=T10638 ... =====> T10638(normal) 1 of 1 [0, 0, 0] cd "./th/T10638.run" && "/mnt/work/ghc/ghc- testing/temp/ghc-8.3.20170927/inplace/bin/ghc-stage2" -c T10638.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed- specialisations -fshow-warning-groups -fdiagnostics-color=never -fno- diagnostics-show-caret -dno-debug-output -XTemplateHaskell -package template-haskell -v0 =====> T10638(ext-interp) 1 of 1 [0, 0, 0] cd "./th/T10638.run" && "/mnt/work/ghc/ghc- testing/temp/ghc-8.3.20170927/inplace/bin/ghc-stage2" -c T10638.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed- specialisations -fshow-warning-groups -fdiagnostics-color=never -fno- diagnostics-show-caret -dno-debug-output -XTemplateHaskell -package template-haskell -fexternal-interpreter -v0 Actual stderr output differs from expected: diff -uw "./th/T10638.run/T10638.stderr.normalised" "./th/T10638.run/T10638.comp.stderr.normalised" --- ./th/T10638.run/T10638.stderr.normalised 2017-09-27 12:18:45.737974039 -0400 +++ ./th/T10638.run/T10638.comp.stderr.normalised 2017-09-27 12:18:45.737974039 -0400 @@ -1,5 +1,18 @@ +ghc-iserv.bin: internal evacuate(static): strange closure type 16476 + (GHC version 8.3.20170927 for x86_64_unknown_linux) + Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
-T10638.hs:26:11: - ‘static test2’ is not a valid C identifier - When checking declaration: - foreign import prim safe "static test2" cmm_test2 :: Int# -> Int# +T10638.hs:26:9: + Exception when trying to run compile-time code: + {handle:
}: GHCi.Message.remoteCall: end of file + Code: do t <- [t| Int# -> Int# |] + cmm_test2 <- newName "cmm_test2" + addTopDecls + [ForeignD (ImportF Prim Safe "static test2" cmm_test2 t)] + .... + In the untyped splice: + $(do t <- [t| Int# -> Int# |] + cmm_test2 <- newName "cmm_test2" + addTopDecls + [ForeignD (ImportF Prim Safe "static test2" cmm_test2 t)] + [| test1 |]) *** unexpected failure for T10638(ext-interp) Unexpected results from: TEST="T10638" ... }}}
The crashes are generally RTS panics or segmentation faults.
New description:
One issue I've noticed while working on #13716 is that most (if not all)
of the tests runs in the `ext-interp` way fail when run with a compiler
built with `SplitSections=YES`.
{{{
$ git clone git://git.haskell.org/ghc
$ cd ghc
$ git submodule update --init
$ mk/get-win32-tarballs.sh download all
$ ./boot
$ ./configure
$ make sdist
$ mkdir tmp; cd tmp
$ ls ../sdistprep/ghc-*-src.tar.xz | xargs -n1 tar -xf
$ cd ghc-*
$ ./boot
$ ./configure
$ make -j9
$ make test TEST=T10638
...
=====> T10638(normal) 1 of 1 [0, 0, 0]
cd "./th/T10638.run" && "/mnt/work/ghc/ghc-
testing/temp/ghc-8.3.20170927/inplace/bin/ghc-stage2" -c T10638.hs -dcore-
lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-
specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-
diagnostics-show-caret -dno-debug-output -XTemplateHaskell -package
template-haskell -v0
=====> T10638(ext-interp) 1 of 1 [0, 0, 0]
cd "./th/T10638.run" && "/mnt/work/ghc/ghc-
testing/temp/ghc-8.3.20170927/inplace/bin/ghc-stage2" -c T10638.hs -dcore-
lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-
specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-
diagnostics-show-caret -dno-debug-output -XTemplateHaskell -package
template-haskell -fexternal-interpreter -v0
Actual stderr output differs from expected:
diff -uw "./th/T10638.run/T10638.stderr.normalised"
"./th/T10638.run/T10638.comp.stderr.normalised"
--- ./th/T10638.run/T10638.stderr.normalised 2017-09-27
12:18:45.737974039 -0400
+++ ./th/T10638.run/T10638.comp.stderr.normalised 2017-09-27
12:18:45.737974039 -0400
@@ -1,5 +1,18 @@
+ghc-iserv.bin: internal evacuate(static): strange closure type 16476
+ (GHC version 8.3.20170927 for x86_64_unknown_linux)
+ Please report this as a GHC bug:
http://www.haskell.org/ghc/reportabug
-T10638.hs:26:11:
- ‘static test2’ is not a valid C identifier
- When checking declaration:
- foreign import prim safe "static test2" cmm_test2 :: Int# -> Int#
+T10638.hs:26:9:
+ Exception when trying to run compile-time code:
+ {handle:
#14291: Tests tend to fail in the ext-interp way when split sections is enabled -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 13716 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Bisection log within `rts/`, {{{ $ git bisect log git bisect start 'rts' # bad: [4364f1e7543b6803cfaef321105d253e0bdf08a4] Typofixes git bisect bad 4364f1e7543b6803cfaef321105d253e0bdf08a4 # good: [2b5b9dc69e5d0af20b6e7be31638c2e3a1bb765f] Fix typo in base changelog git bisect good 2b5b9dc69e5d0af20b6e7be31638c2e3a1bb765f # good: [bea18a0e9ea5ff2063ca4900acad9995f40276eb] Fix GCC 7 warning in the RTS git bisect good bea18a0e9ea5ff2063ca4900acad9995f40276eb # bad: [ee2e9ece388e75ac433097ac726a555a07ae0830] Correct incorrect free in PE linker git bisect bad ee2e9ece388e75ac433097ac726a555a07ae0830 # bad: [3eeb55e9578f6eaebccf27170eb1324990affb51] rts/sm/Storage.c: tweak __clear_cache proto for clang git bisect bad 3eeb55e9578f6eaebccf27170eb1324990affb51 # good: [1e471265c1ea9b2c4e9709adc182c36d0635f071] rts: Clarify whitehole logic in threadPaused git bisect good 1e471265c1ea9b2c4e9709adc182c36d0635f071 # bad: [a6f3d1b00e9c37a56cd4db9e519309e94a65d181] rts: Fix isByteArrayPinned#'s treatment of large arrays git bisect bad a6f3d1b00e9c37a56cd4db9e519309e94a65d181 # bad: [f9c6d53fe997f1c560cda6f346f4b201711df37c] Tag the FUN before making a PAP (#13767) git bisect bad f9c6d53fe997f1c560cda6f346f4b201711df37c # bad: [9b514dedf090c5e21e3be38d174cf1390e21879f] rts/RetainerProfile: Const-correctness fixes git bisect bad 9b514dedf090c5e21e3be38d174cf1390e21879f # first bad commit: [9b514dedf090c5e21e3be38d174cf1390e21879f] rts/RetainerProfile: Const-correctness fixes }}} Unfortunately it looks like the problem isn't in `rts/`. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14291#comment:6 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#14291: Tests tend to fail in the ext-interp way when split sections is enabled -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 13716 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Here is another bisection, this time over the whole tree. Sadly the result is just as non-sensical, {{{ git bisect start # bad: [4364f1e7543b6803cfaef321105d253e0bdf08a4] Typofixes git bisect bad 4364f1e7543b6803cfaef321105d253e0bdf08a4 # good: [2b5b9dc69e5d0af20b6e7be31638c2e3a1bb765f] Fix typo in base changelog git bisect good 2b5b9dc69e5d0af20b6e7be31638c2e3a1bb765f # good: [af9612bf862daaa99384eefa3059054053ecbee8] Make -w less aggressive (Trac #12056) git bisect good af9612bf862daaa99384eefa3059054053ecbee8 # good: [b0285d1fa76769d59e69cb9bf97675868d90a028] Bump nofib submodule git bisect good b0285d1fa76769d59e69cb9bf97675868d90a028 # bad: [dab0e515eadecaee3e9e9f5f8eee3159fa39bb27] Canonicalise Monoid instances in GHC git bisect bad dab0e515eadecaee3e9e9f5f8eee3159fa39bb27 # good: [29da01e0a023eea4bbbfd69dd5d854db721233e6] Make parsed AST dump output lazily git bisect good 29da01e0a023eea4bbbfd69dd5d854db721233e6 # bad: [8a1de424143f5b75e12976ca739e58fe04ae04d6] Add testcase for #14178 git bisect bad 8a1de424143f5b75e12976ca739e58fe04ae04d6 # bad: [a27bb1bd6206bdd5e6004ec1f7e95144a0fcc4d4] base: Add support for file unlocking git bisect bad a27bb1bd6206bdd5e6004ec1f7e95144a0fcc4d4 # good: [a6c448b403dbe8720178ca82100f34baedb1f47e] Small refactor of getRuntimeRep git bisect good a6c448b403dbe8720178ca82100f34baedb1f47e # good: [5266ab9059dffa741b172636f50f1fbfd491dbb4] Remove dll-split. git bisect good 5266ab9059dffa741b172636f50f1fbfd491dbb4 # good: [3c6b2fc3b5ca11a5410405664e4640767ef941dd] Fix decomposition error on Windows git bisect good 3c6b2fc3b5ca11a5410405664e4640767ef941dd # good: [f86de44dac0a6ca40c5fcd65f3a1944c45fa6011] ghc-pkg: Try opening lockfiles in read-write mode first git bisect good f86de44dac0a6ca40c5fcd65f3a1944c45fa6011 # first bad commit: [a27bb1bd6206bdd5e6004ec1f7e95144a0fcc4d4] base: Add support for file unlocking }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14291#comment:7 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#14291: Tests tend to fail in the ext-interp way when split sections is enabled -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 13716 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Huh, well this is unfortunate: It looks like a27bb1bd6206bdd5e6004ec1f7e95144a0fcc4d4 really is bad and f86de44dac0a6ca40c5fcd65f3a1944c45fa6011 is in fact good. I still have a hard time seeing how a27bb1bd6206bdd5e6004ec1f7e95144a0fcc4d4 is directly the cause. It's look more and more like this isn't entirely reproducible. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14291#comment:8 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#14291: Tests tend to fail in the ext-interp way when split sections is enabled
-------------------------------------+-------------------------------------
Reporter: bgamari | Owner: (none)
Type: bug | Status: new
Priority: normal | Milestone: 8.4.1
Component: Compiler | Version: 8.2.1
Resolution: | Keywords:
Operating System: Unknown/Multiple | Architecture:
| Unknown/Multiple
Type of failure: None/Unknown | Test Case:
Blocked By: | Blocking: 13716
Related Tickets: | Differential Rev(s):
Wiki Page: |
-------------------------------------+-------------------------------------
Comment (by bgamari):
So I plugged away at this a bit today. I'm increasingly suspicious of
1c83fd814b12754be8af211a387cec906ca198b3 which touches a large amount of
ELF linker logic. Unfortunately it's not terribly easy to revert.
In particular, I've traced one failure down to what appears to be a
section-name relocation. Namely,
{{{#!objdump
00000000001ee308
#14291: Tests tend to fail in the ext-interp way when split sections is enabled -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 13716 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Hmm, this is quite suspicious. The `ObjectCode` corresponding to the `HSbase` object has `oc->n_sections == 19` yet the section header according to `objdump` looks like, {{{ Sections: Idx Name Size VMA LMA File off Algn 0 .text 004786ba 0000000000000000 0000000000000000 00000040 2**4 CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE 1 .data 00082138 000000000002a030 000000000002a030 00478700 2**3 CONTENTS, ALLOC, LOAD, RELOC, DATA 2 .bss 00000000 0000000000000000 0000000000000000 004fa838 2**0 ALLOC 3 .rodata 0000f62a 00000000004786c0 00000000004786c0 004fa840 2**4 CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA 4 .data.rel.ro 0002a030 0000000000000000 0000000000000000 00509e80 2**5 CONTENTS, ALLOC, LOAD, RELOC, DATA 5 .init_array 00000008 0000000000000000 0000000000000000 00533eb0 2**3 CONTENTS, ALLOC, LOAD, RELOC, DATA 6 .eh_frame 00000bd0 0000000000000000 0000000000000000 00533eb8 2**3 CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA 7 .comment 00000038 0000000000000000 0000000000000000 00534a88 2**0 CONTENTS, READONLY 8 .note.GNU-stack 00000000 0000000000000000 0000000000000000 00a42a80 2**0 CONTENTS, READONLY }}} `oc->sections[*].size` looks like, {{{
python for i in range(19): print(i, hex(gdb.parse_and_eval('objects->sections[%d].size' % i))) 0 0x0 1 0x4786ba 2 0x82138 3 0x0 4 0xf62a 5 0x2a030 6 0x8 7 0xbd0 8 0x38 9 0x108048 10 0x39bfd0 11 0x64770 12 0x18 13 0xb40 14 0x4ce0 15 0x0 16 0x1fa5e0 17 0x202de8 18 0x8e }}}
-- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14291#comment:10 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#14291: Tests tend to fail in the ext-interp way when split sections is enabled -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 13716 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Well this is peculiar, {{{ 0x00000000013e100c in addSection (s=0x17d1e30, kind=SECTIONKIND_OTHER, alloc=SECTION_NOMEM, start=0x7f0d68b99000, size=0, mapped_offset=0, mapped_start=0x0, mapped_size=0) at rts/Linker.c:1763 1763 s->start = start; /* actual start of section in memory */
bt #0 0x00000000013e100c in addSection (s=0x17d1e30, kind=SECTIONKIND_OTHER, alloc=SECTION_NOMEM, start=0x7f0d68b99000, size=0, mapped_offset=0, mapped_start=0x0, mapped_size=0) at rts/Linker.c:1763 #1 0x0000000001400499 in ocGetNames_ELF (oc=0x17d1b90) at rts/linker/Elf.c:795 #2 0x00000000013e092e in loadOc (oc=0x17d1b90) at rts/Linker.c:1514 #3 0x00000000013e07c5 in loadObj_ (path=0x420001b730 "/mnt/work/ghc/ghc- compare-2/libraries/base/dist-install/build/HSbase-4.10.0.0.o") at rts/Linker.c:1450 #4 0x00000000013e0850 in loadObj (path=0x420001b730 "/mnt/work/ghc/ghc- compare-2/libraries/base/dist-install/build/HSbase-4.10.0.0.o") at rts/Linker.c:1466 #5 0x0000000000b3a4a6 in s5az_info () #6 0x0000000000000000 in ?? () up #1 0x0000000001400499 in ocGetNames_ELF (oc=0x17d1b90) at rts/linker/Elf.c:795 795 addSection(&oc->sections[i], kind, alloc, oc->image+offset, size, print shdr[0] $16 = { sh_name = 0, sh_type = 0, sh_flags = 0, sh_addr = 0, sh_offset = 0, sh_size = 0, sh_link = 0, sh_info = 0, sh_addralign = 0, sh_entsize = 0 } print ehdr[0] $17 = { e_ident = "\177ELF\002\001\001\000\000\000\000\000\000\000\000", e_type = 1, e_machine = 62, e_version = 1, e_entry = 0, e_phoff = 0, e_shoff = 14941912, e_flags = 0, e_ehsize = 64, e_phentsize = 0, e_phnum = 0, e_shentsize = 64, e_shnum = 19, e_shstrndx = 18 } }}}
The RTS really does seem to be under the impression that there are 19 sections, despite what `objdump` claims. Hmmm, someone is clearly lying. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14291#comment:11 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#14291: Tests tend to fail in the ext-interp way when split sections is enabled -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 13716 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Alright, well `readelf -S` appears to agree with GHC. I think `objdump` is just lying. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14291#comment:12 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#14291: Tests tend to fail in the ext-interp way when split sections is enabled -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 13716 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I think the issue may not be in the RTS linker; rather, I suspect the issue is that the system linker is rearranging our sections. In `Data/Data.o` I see {{{ $ readelf -W -s /mnt/work/ghc/ghc-compare-2/libraries/base/dist- install/build/Data/Data.o | grep DataAnyzuzdcgunfold 14326: 0000000000000000 0 OBJECT GLOBAL DEFAULT 5790 base_DataziData_zdfDataAnyzuzdcgunfold_closure 14327: 0000000000000020 68 OBJECT GLOBAL DEFAULT 5794 base_DataziData_zdfDataAnyzuzdcgunfold_info }}} With the sections 5790 and 5794 being {{{ [5790] .data.base_DataziData_zdfDataAnyzuzdcgunfold_closure PROGBITS 0000000000000000 033940 000010 00 WA 0 0 8 [5794] .text.base_DataziData_zdfDataAnyzuzdcgunfold_info PROGBITS 0000000000000000 033990 000064 00 AX 0 0 8 }}} Whereas in the merged object file I see, {{{ $ readelf -W -s /mnt/work/ghc/ghc-compare-2/libraries/base/dist- install/build/HSbase-4.10.0.0.o | grep DataAnyzuzdcgunfold 81410: 0000000000076338 68 OBJECT GLOBAL DEFAULT 1 base_DataziData_zdfDataAnyzuzdcgunfold_info 81411: 000000000000e6d0 0 OBJECT GLOBAL DEFAULT 2 base_DataziData_zdfDataAnyzuzdcgunfold_closure }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14291#comment:13 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#14291: Tests tend to fail in the ext-interp way when split sections is enabled -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 13716 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by angerman): @bgamari, could you note down which linker your system linker is, and what version? And maybe also the command how it merges the final object file? Reordering in itself (as long as the relocations are properly adjusted) shouldn't be an issue I would assume. The RTS Linker might still be at fault. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14291#comment:14 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#14291: Tests tend to fail in the ext-interp way when split sections is enabled -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 13716 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): After a bit more investigation I think my conclusion from comment:13 was utterly wrong. I had misinterpreted the symbols involved. I am using `GNU gold (GNU Binutils for Debian 2.28) 1.14`. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14291#comment:15 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#14291: Tests tend to fail in the ext-interp way when split sections is enabled -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 13716 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): For the record, both `HSbase-4.10.0.0.o` and `Data.o` are available at http://home.smart-cactus.org/~ben/. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14291#comment:16 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#14291: Tests tend to fail in the ext-interp way when split sections is enabled
-------------------------------------+-------------------------------------
Reporter: bgamari | Owner: (none)
Type: bug | Status: new
Priority: normal | Milestone: 8.4.1
Component: Compiler | Version: 8.2.1
Resolution: | Keywords:
Operating System: Unknown/Multiple | Architecture:
| Unknown/Multiple
Type of failure: None/Unknown | Test Case:
Blocked By: | Blocking: 13716
Related Tickets: | Differential Rev(s):
Wiki Page: |
-------------------------------------+-------------------------------------
Comment (by bgamari):
So, to recap, it appears that my theory from comment:13 is wrong: the
relocation in `s1MQ_info` (see comment:9) appears to be consistent with
what `objdump` says the target should be and with where the RTS says it
mapped the target section.
However, it occurred to me that maybe I'm focusing on the wrong
relocation: the crash occurs when we attempt a `jmpq *($rbx)` where `$rbx`
was computed (through quite a long chain) from the bits mentioned in
comment:9. Perhaps instead it is a relocation at the address `*($rbx)`
(which resolves to `base_DataziData_zdfDataAnyzuzdcgfoldl_closure`) that
is the at fault.
`objdump` says the following about this symbol,
{{{
00000000000386f0
x/8i 0x41453420 0x41453420: add $0x18,%r12 0x41453424: cmp 0x358(%r13),%r12 0x4145342b: ja 0x41453450 0x4145342d: movq $0x414533d0,-0x10(%r12) 0x41453436: mov %rsi,(%r12) }}} This is precisely the code that I would expect given the object file. I don't know why my previous watchpoint didn't catch this being mapped (oh,
#14291: Tests tend to fail in the ext-interp way when split sections is enabled -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 13716 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Actually, the data at `0x41453420` is valid: it is code, {{{ perhaps gdb doesn't catch changes due to `mmap` events; that would explain it). Anyways, in this case I'm quite confused: the relocations all appear to be correct but we appear to be doing an indirect jump through `0x41453420`, clearly expecting it to be an address where in fact it is code. This suggests that things went awry quite a bit earlier. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14291#comment:18 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#14291: Tests tend to fail in the ext-interp way when split sections is enabled -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 13716 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): In fact, the instruction that we crash on, `0x41755b3f`, resolves to `base_GHCziStackziTypes_getCallStack_info`. Furthermore, the few addresses on the Haskell stack are `base_GHCziException_prettyCallStack_info` and `base_GHCziException_zdfExceptionSomeExceptionzuzdctoException_info`, which suggests that something has gone awry (although in a rather graceful way). -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14291#comment:19 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#14291: Tests tend to fail in the ext-interp way when split sections is enabled -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 13716 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I'm now looking specifically at the crashing function (`getCallStack`): I can confirm that the argument is completely crazy: {{{
ghc closure $r14 off-heap(0x400c5dd8) ghc symbol 0x400c5dd8 8 bytes into base_DataziData_zdfDataAnyzuzdcgunfold_closure (starts at 0x400c5dd0) }}} That is, the argument is an off-heap value that doesn't even begin on defined symbol. Sheer madness. Let's try to see why.
-- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14291#comment:20 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#14291: Tests tend to fail in the ext-interp way when split sections is enabled -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 13716 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Prior we pass through `base_GHCziException_zdfShowErrorCallzuzdcshowsPrec_info`, {{{#!hs GHC.Exception.$fShowErrorCall_$cshowsPrec [InlPrag=INLINE[0]] :: GHC.Types.Int -> GHC.Exception.ErrorCall -> GHC.Show.ShowS }}} In this case the second argument is somewhat reasonable, {{{
ghc closure $rsi constr(base:GHC.Exception.ErrorCallWithLocation) }}} The first argument also looks fine, {{{ x/2a $r14 0x154dcf8: 0x13c2fa8
0x0 }}}
-- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14291#comment:21 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
ghc symbol 0x415cbd00 152 bytes into
#14291: Tests tend to fail in the ext-interp way when split sections is enabled
-------------------------------------+-------------------------------------
Reporter: bgamari | Owner: (none)
Type: bug | Status: new
Priority: normal | Milestone: 8.4.1
Component: Compiler | Version: 8.2.1
Resolution: | Keywords:
Operating System: Unknown/Multiple | Architecture:
| Unknown/Multiple
Type of failure: None/Unknown | Test Case:
Blocked By: | Blocking: 13716
Related Tickets: | Differential Rev(s):
Wiki Page: |
-------------------------------------+-------------------------------------
Comment (by bgamari):
Indeed there is some weird stuff that happens before we leave
`base_GHCziException_zdfShowErrorCallzuzdcshowsPrec_info`:
We encounter this instruction sequence,
{{{
0x00000000415cbdf8 ? mov 0xf(%rbx),%rsi
0x00000000415cbdfc ? mov 0x7(%rbx),%r14
0x00000000415cbe00 ? add $0x8,%rbp
0x00000000415cbe04 ? jmpq 0x415cbd00
}}}
Where
{{{
base_GHCziException_zdfExceptionSomeExceptionzuzdctoException_info (starts
at 0x415cbc68)
}}}
There are a few things that are odd about this:
1. we are jumping into the middle of a procedure
2. the procedure seems to have nothing to do with showing an `ErrorCall`
The Haskell this is derived from is,
{{{#!hs
instance Show ErrorCall where
showsPrec _ (ErrorCallWithLocation err "") = showString err
showsPrec _ (ErrorCallWithLocation err loc) = showString (err ++ '\n' :
loc)
}}}
And the assembler that GHC produces for this particular block is,
{{{
block_c4mu_info:
_c4mu:
movq 15(%rbx),%rsi
movq 7(%rbx),%r14
addq $8,%rbp
jmp GHC.Exception.$w$cshowsPrec1_info
.size GHC.Exception.$fShowErrorCall_$cshowsPrec_info,
.-GHC.Exception.$fShowErrorCall_$cshowsPrec_info
}}}
Strangely enough I can't find `GHC.Exception.$w$cshowsPrec1_info` in the
RTS symbol table.
According to `objdump` the relocation of the `jmp` looks like,
{{{
1eedc4: e9 00 00 00 00 jmpq 1eedc9
#14291: Tests tend to fail in the ext-interp way when split sections is enabled -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 13716 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Hmm, or perhaps not: it looks like the assembler at `0x415cbd00` matches what `objdump` says I should expect in `base_GHCziException_zdwzdcshowsPrec1_info`. It turns out I had a sign error in the [[https://github.com/bgamari/ghc- utils/commit/21f7c7f967f7a51bf3081617896225284116f9a6|Python code]] I was using to extract symbols out of the RTS. Silly silly me. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14291#comment:23 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#14291: Tests tend to fail in the ext-interp way when split sections is enabled -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 13716 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Alright, so let's recap, When we enter `base_GHCziException_zdfShowErrorCallzuzdcshowsPrec_info` we have two perfectly valid looking arguments (an `I# 0` and a `ErrorCallWithLocation` constructor carrying a `:` constructor). From there we eventually jump to `base_GHCziException_zdwzdcshowsPrec1_info`, {{{#!hs GHC.Exception.$w$cshowsPrec1 [InlPrag=[0]] :: GHC.Base.String -> GHC.Base.String -> GHC.Show.ShowS }}} Here we have a reasonable-looking cons cell as the first argument. The second argument looked a bit suspicious at first but seems to check out {{{
ghc closure $rsi THUNK (0x415cf708) Ptr: off-heap(0x0) Ptr: off-heap(0x400c5ddb) ghc sym 0x415cf708 1216 bytes into base_GHCziException_prettyCallStack_info (starts at 0x415cf248) }}} This address appears to correspond to a certain `sat_s4i3 [Occ=Once] :: GHC.Base.String`
We eventually end up entering this thunk. In this thunk we perform a call to `base_GHCziStackziTypes_getCallStack_info` {{{ GHC.Stack.Types.getCallStack [Occ=LoopBreaker] :: GHC.Stack.Types.CallStack -> [([GHC.Types.Char], GHC.Stack.Types.SrcLoc)] }}} which is given a rather odd looking argument, {{{
print/a $r14 $13 = 0x400c5ddb x/8a $r14 & ~7 0x400c5dd8: 0x0 0x41453420 0x400c5de8: 0x0 0x414534c8 0x400c5df8: 0x0 0x41453520 }}} It looks like **this** is the first real sign of trouble.
which eventually leads to the crash when it we attempt an indirect jump to -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14291#comment:24 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#14291: Tests tend to fail in the ext-interp way when split sections is enabled -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 13716 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by hsyl20): Replying to [comment:9 bgamari]:
So I plugged away at this a bit today. I'm increasingly suspicious of 1c83fd814b12754be8af211a387cec906ca198b3 which touches a large amount of ELF linker logic. Unfortunately it's not terribly easy to revert.
I don't know if it is related to this bug but the patch you mention has introduced the [https://git.haskell.org/ghc.git/blob/1c83fd814b12754be8af211a387cec906ca198b... following line]: {{{#!hs oc->info->sectionHeaderStrtab = (char*)((uint8_t*)oc->image + oc->info->sectionHeader[oc->info->elfHeader->e_shstrndx].sh_offset); }}} which may be wrong when there are too many sections (splitSections...). Could you try replacing `oc->info->elfHeader->e_shstrndx` with `elf_shstrndx(oc->info->elfHeader)`? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14291#comment:25 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#14291: Tests tend to fail in the ext-interp way when split sections is enabled -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 13716 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): hsyl20, that is a fair observation; unfortunately it's almost certainly not the cause of this issue as we are loading merged object files which have only around two dozen sections each. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14291#comment:26 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#14291: Tests tend to fail in the ext-interp way when split sections is enabled -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 13716 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I've confirmed that the fix suggested in comment:25 has no effect on the issue at hand. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14291#comment:27 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#14291: Tests tend to fail in the ext-interp way when split sections is enabled -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 13716 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): For the record, building both Stage2 and the libraries with `-fwhole- archive-hs-libs` seems to make no difference. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14291#comment:28 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#14291: Tests tend to fail in the ext-interp way when split sections is enabled -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 13716 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Well, as noted in the conclusion of comment:25 it looks like this is a bug in `ld.gold` which decides to mangle our object files while merging. I don't yet know what in particular triggers the issue, however. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14291#comment:29 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#14291: Tests tend to fail in the ext-interp way when split sections is enabled -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 13716 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Well, at least `ld.gold` does slightly better than `ld.lld` (version 5.0), which simply segfaults. I hate linkers. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14291#comment:30 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#14291: Tests tend to fail in the ext-interp way when split sections is enabled -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 13716 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Alright, the `ld.gold` issue is still present as of `binutils` commit 2fd9d7ca17539ce983862b25e0abc27cfb706189. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14291#comment:31 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#14291: Tests tend to fail in the ext-interp way when split sections is enabled -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 13716 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Hmmm, so it seems to have something to do with our `merge-sections.ld` linker script. I've reduced this down to a rather minimal [[https://github.com/bgamari/T14291-repro|reproduction case]] which still fails under `ld.gold` and `ld.lld`. Curiously, removing any of the remaining linker script sections in this testcase seems to prevent the issue. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14291#comment:32 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#14291: Tests tend to fail in the ext-interp way when split sections is enabled -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 13716 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * blockedby: 14328 => Comment: I have opened #14328 to track the `ld.gold` brokenness since this really isn't a GHC issue. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14291#comment:34 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#14291: Tests tend to fail in the ext-interp way when split sections is enabled -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 14328 | Blocking: 13716 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * blockedby: => 14328 -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14291#comment:35 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#14291: Tests tend to fail in the ext-interp way when split sections is enabled -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 14328 | Blocking: 13716 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Of the linkers * `ld.gold` has this bug; produces valid-looking object code that simply doesn't work. Ben has filed [https://sourceware.org/bugzilla/show_bug.cgi?id=22266 this bug report]. * `ld.lld` crashes on the same repro case. And `gcc` doesn't support `lld`. * `ld.bfd` is OK on this, but it is slow see #13739. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14291#comment:36 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#14291: Tests tend to fail in the ext-interp way when split sections is enabled -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 14328 | Blocking: 13716 Related Tickets: | Differential Rev(s): Phab:D4431 Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonmar): * differential: => Phab:D4431 -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14291#comment:38 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#14291: Tests tend to fail in the ext-interp way when split sections is enabled
-------------------------------------+-------------------------------------
Reporter: bgamari | Owner: (none)
Type: bug | Status: new
Priority: normal | Milestone: 8.6.1
Component: Compiler | Version: 8.2.1
Resolution: | Keywords:
Operating System: Unknown/Multiple | Architecture:
| Unknown/Multiple
Type of failure: None/Unknown | Test Case:
Blocked By: 14328 | Blocking: 13716
Related Tickets: | Differential Rev(s): Phab:D4431
Wiki Page: |
-------------------------------------+-------------------------------------
Comment (by Simon Marlow
#14291: Tests tend to fail in the ext-interp way when split sections is enabled -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 14328 | Blocking: 13716 Related Tickets: | Differential Rev(s): Phab:D4431 Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonmar): * status: new => merge -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14291#comment:40 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#14291: Tests tend to fail in the ext-interp way when split sections is enabled -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 14328 | Blocking: 13716 Related Tickets: | Differential Rev(s): Phab:D4431 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed * milestone: 8.6.1 => 8.4.1 Comment: Merged with b4e32780a976193208eebbddf789eeb80351ac95. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14291#comment:41 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
participants (1)
-
GHC