-
Notifications
You must be signed in to change notification settings - Fork 237
/
BUGLOG
86 lines (70 loc) · 5.51 KB
/
BUGLOG
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
This file contains bugs we find while working on haskell.nix. The format is as
follow:
<separator: 80 * '-'>
YYYY-MM-DD: nix-job name
<error>
<discussion>
--------------------------------------------------------------------------------
2024-04-09 x86_64-linux.R2305.ghc8107.mingwW64.ghc
/build/ghc62733_0/ghc_1.s:50:0: error:
Error: CFI instruction used without previous .cfi_startproc
|
50 | .cfi_escape 0x16, 0x07, 0x04, 0x77, 152, 65
| ^
`x86_64-w64-mingw32-cc' failed in phase `Assembler'. (Exit code: 1)
make[1]: *** [rts/ghc.mk:325: rts/dist/build/StgCRun.o] Error 1
The source for this is
> https://github.com/ghc/ghc/blob/1f02b7430b2fbab403d7ffdde9cfd006e884678e/rts/StgCRun.c#L433
It appears that GCC C17 12.2.0 does _not_ emit .cfi_startproc / .cfi_endprocs
whereas GCC C17 13.2.0 _does_. Specificall x86_64-w64-mingw32-cc. So this might
be a cross compilation issue.
The -g is hardcoded in
https://github.com/ghc/ghc/blob/1f02b7430b2fbab403d7ffdde9cfd006e884678e/mk/config.mk.in#L361
Turns out, this was disabled for anything but linux in https://github.com/ghc/ghc/commit/5b08e0c06e038448a63aa9bd7f163b23d824ba4b,
hence we backport that patch to GHC-8.10 when targeting windows (to prevent mass rebuilds for
other archs).
--------------------------------------------------------------------------------
2024-04-10 x86_64-linux.R2305.ghc902.mingwW64.ghc
make[1]: *** [utils/hsc2hs/ghc.mk:22: utils/hsc2hs/dist-install/build/tmp/hsc2hs.exe] Error 1
utils/runghc/dist-install/build/Main.o:fake:(.text+0x2a): relocation truncated to fit: R_X86_64_32S against `.text'
utils/runghc/dist-install/build/Main.o:fake:(.text+0x46): relocation truncated to fit: IMAGE_REL_AMD64_ADDR32 against `.data'
utils/runghc/dist-install/build/Main.o:fake:(.text+0x8b): relocation truncated to fit: R_X86_64_32S against symbol `stg_bh_upd_frame_info' defined in .text section in /build/ghc-9.0.2/rts/dist/build/libHSrts.a(Updates.o)
utils/runghc/dist-install/build/Main.o:fake:(.text+0x95): relocation truncated to fit: IMAGE_REL_AMD64_ADDR32 against `.rdata'
utils/runghc/dist-install/build/Main.o:fake:(.text+0xe3): relocation truncated to fit: R_X86_64_32S against symbol `stg_bh_upd_frame_info' defined in .text section in /build/ghc-9.0.2/rts/dist/build/libHSrts.a(Updates.o)
utils/runghc/dist-install/build/Main.o:fake:(.text+0xed): relocation truncated to fit: IMAGE_REL_AMD64_ADDR32 against `.rdata'
utils/runghc/dist-install/build/Main.o:fake:(.text+0x13b): relocation truncated to fit: R_X86_64_32S against symbol `stg_bh_upd_frame_info' defined in .text section in /build/ghc-9.0.2/rts/dist/build/libHSrts.a(Updates.o)
utils/runghc/dist-install/build/Main.o:fake:(.text+0x145): relocation truncated to fit: IMAGE_REL_AMD64_ADDR32 against `.rdata'
utils/runghc/dist-install/build/Main.o:fake:(.text+0x193): relocation truncated to fit: R_X86_64_32S against symbol `stg_bh_upd_frame_info' defined in .text section in /build/ghc-9.0.2/rts/dist/build/libHSrts.a(Updates.o)
utils/runghc/dist-install/build/Main.o:fake:(.text+0x19d): relocation truncated to fit: IMAGE_REL_AMD64_ADDR32 against `.rdata'
utils/runghc/dist-install/build/Main.o:fake:(.text+0x1eb): additional relocation overflows omitted from the output
We notice `fake`, which is GHC failing to provide .file identifier in the source.
We also see lots of R_X64_64_32S relocations, which are signed 32bit relocations.
These fall with ASLR and high entropy base images from later binutils.
The underlying issue is that GHC emits _absolute_ label loads (mov $... reg), instead
of %rpi or other relative loads. This then leads to the linker emitting 32bit
absolute relocation. With the final image being potentially loaded into high memory
(e.g. dynamic base, and the base image being set to some high address), the linker
starts falling over itself, because it simply can't resolve those absolute addresses
in the 32bit slots.
This was fixed in GHC upstream in https://gitlab.haskell.org/ghc/ghc/-/merge_requests/7449,
while the patch in haskell.nix is a bit more pedestrian and just sets PIC on windows to
always be on, and then uses the PIC pipeline.
--------------------------------------------------------------------------------
2024-06-18 x86_64-linux.unstable.ghc9101.ucrt64.tests.th-dlls-minimal.build
0024:err:seh:call_stack_handlers invalid frame 00007FFFFF68EF18 (0000000000022000-0000000000220000)
0024:err:seh:NtRaiseException Exception frame is not in stack limits => unable to dispatch exception.
iserv-proxy: {handle: <socket: 11>}: GHCi.Message.remoteCall: end of file
This is due to GHC mislinking GNU import libraries (dll.a). What happens is that
GHC ends up creating GOT entries for function calls instead of PLT entries. The
loader/linker in GHC for Windows has logic to lazy load .dll's as referenced. For
this symbols get a dependency symbol attached, this could be a symbol indicating
the DLL that needs to be loaded. While walking the dependencies to find the dll to
load (or in some cases just the dependent symbol, not the dll), we override the
symbol type with the one of the dependent symbol. This however means we'll
override the type of a symbol with the DATA type each time the symbol leads to a
dllInstance to be loaded. Subsequently we end up creating a GOT entry instead of
a PLT entry for the symbol, irrepsective of the original symbol being a code or
data symbol. If code symbols end up getting GOT stubs, we see the above crash as
the control flow jumps to the location of the stub, and instead of a PLT/jump
island just lands in the address of the target symbol, which is in most cases
non-sensical machine code.