#12147 closed bug (fixed)

GHC's Linker Should Support Relocation Type 42

Reported by: gershomb Owned by:
Priority: high Milestone: 8.0.2
Component: Runtime System (Linker) Version: 8.0.1
Keywords: Cc:
Operating System: Linux Architecture: Unknown/Multiple
Type of failure: None/Unknown Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s): Phab:D2303
Wiki Page:

Description

As per: https://github.com/DanielG/ghc-mod/issues/762#issuecomment-213743585

"gas >= 2.26 uses some new relocation types (in particular type 42, aka R_X86_64_REX_GOTPCRELX), which are not supported by ghc's linker."

This causes problems when linking in libs with certain sorts of c bits via the GHC API (at the very least).

Support should be added.

Change History (19)

comment:1 Changed 15 months ago by thomie

Component: CompilerRuntime System (Linker)

comment:2 Changed 15 months ago by Phyx-

Owner: set to Phyx-

Thanks for the report, this should be simple enough to fix

comment:3 Changed 15 months ago by Phyx-

Differential Rev(s): Phab:D2303
Status: newpatch

comment:4 Changed 15 months ago by thoughtpolice

Milestone: 8.0.2
Priority: normalhigh

I'm bumping the priority for this to 'high' (as GHC is technically broken on a new binutils in the static linker configuration) and moving it to 8.0.2.

comment:5 Changed 15 months ago by erikd

I have "GNU assembler (GNU Binutils for Debian) 2.26" on my Debian system. but have not yet hit this issue. Is there a test case?

comment:6 Changed 15 months ago by erikd

Tried this:

$ cabal get cipher-aes
$ cd cipher-aes-0.2.11
$ cabal sandbox init
$ cabal install --dependencies-only --enable-tests
$ cabal install
$ cabal exec -- ghci -i:Tests Tests/Tests.hs 
ghci > main
GHCi, version 7.10.3: http://www.haskell.org/ghc/  :? for help
Ok, modules loaded: Crypto.Cipher.AES, Main, KATECB, KATCBC, KATXTS, KATGCM,
KATOCB3.
ghci > main
ghc: panic! (the 'impossible' happened)
  (GHC version 7.10.3 for x86_64-unknown-linux):
    Loading temp shared object failed: /tmp/ghcc0a8_0/libghc_9.so: undefined
    symbol: aes_decrypt_ecb

Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug

That doesn't seem to be quite the same problem.

comment:7 Changed 15 months ago by Phyx-

I haven't written a testcase since you need binutils-2.26 for it to trigger and I don't think I can force the test only then.

In any case, simplest case to reproduce this is to compile GHC with DYNAMIC_GHC_PROGRAMS=NO

I use this assembly file as input:

# x86_64
# as as_test.s -o as_test.o && objdump -Dr as_test.o
# ghc --interactive hs_test as_test.o

.text
.globl foo

foo:
	push %rbp
	mov %rsp, %rbp

	mov msg@GOTPCREL(%rip), %rdi
	call puts@PLT

	pop %rbp
	ret

.data
msg:
	.ascii "Hello World!\0"
	len = . - msg

Which with

[phyx@localhost ~]$ as --version
GNU assembler (GNU Binutils) 2.26.20160125

returns the expected relocation

[phyx@localhost ~]$ as as_test.s -o as_test.o && objdump -Dr as_test.o

as_test.o:     file format elf64-x86-64


Disassembly of section .text:

0000000000000000 <foo>:
   0:   55                      push   %rbp
   1:   48 89 e5                mov    %rsp,%rbp
   4:   48 8b 3d 00 00 00 00    mov    0x0(%rip),%rdi        # b <foo+0xb>
                        7: R_X86_64_REX_GOTPCRELX       msg-0x4
   b:   e8 00 00 00 00          callq  10 <foo+0x10>
                        c: R_X86_64_PLT32       puts-0x4
  10:   5d                      pop    %rbp
  11:   c3                      retq

Disassembly of section .data:

0000000000000000 <msg>:
   0:   48                      rex.W
   1:   65 6c                   gs insb (%dx),%es:(%rdi)
   3:   6c                      insb   (%dx),%es:(%rdi)
   4:   6f                      outsl  %ds:(%rsi),(%dx)
   5:   20 57 6f                and    %dl,0x6f(%rdi)
   8:   72 6c                   jb     76 <len+0x69>
   a:   64 21 00                and    %eax,%fs:(%rax)

Before the patch it crashes as expected

[phyx@localhost ~]$ ghc/inplace/bin/ghc-stage2 --interactive as_test.o hs_test.hs
GHCi, version 8.1.20160604: http://www.haskell.org/ghc/  :? for help
ghc-stage2: as_test.o: unhandled ELF relocation(RelA) type 42

linking extra libraries/objects failed

And after the patch

GHCi, version 8.1.20160604: http://www.haskell.org/ghc/  :? for help
[1 of 1] Compiling Main             ( hs_test.hs, interpreted )
Ok, modules loaded: Main.
*Main> main
Hello World!

comment:8 Changed 15 months ago by Tamar Christina <tamar@…>

In 0d963caf/ghc:

Add relocation type R_X86_64_REX_GOTPCRELX

Summary:
Adding support for the `R_X86_64_REX_GOTPCRELX` relocation type.
This relocation is treated by the linker the same as the `R_X86_64_GOTPCRELX` type
`G + GOT + A - P` to generate relative offsets to the GOT.
The `REX` prefix has no influence in this stage.

This is based on https://github.com/hjl-tools/x86-psABI/wiki/x86-64-psABI-r252.pdf

Test Plan: ./validate

Reviewers: erikd, austin, bgamari, simonmar

Reviewed By: erikd

Subscribers: thomie, #ghc_windows_task_force

Differential Revision: https://phabricator.haskell.org/D2303

GHC Trac Issues: #12147

comment:9 Changed 15 months ago by Phyx-

Resolution: fixed
Status: patchclosed

NOTE: The bindist for elf platforms need to be build using a system that has glibc >= 2.23 in order for elf.h to contain these constants and for GHC to then be able to use them.

comment:10 Changed 15 months ago by thomie

Owner: Phyx- deleted
Resolution: fixed
Status: closednew

comment:11 Changed 15 months ago by thomie

Status: newmerge

comment:12 Changed 15 months ago by erikd

@bgamari, is the a big enough issue to consider doing a 7.10.4 release?

comment:13 Changed 15 months ago by thomie

Quoting @erikd in https://phabricator.haskell.org/D2303#67070:

I'm pretty sure that will be handled by the Linux distros. They wouldn't ship an GNU as until their glibc handled these new relocations.

We have our first victim of this assumption: https://github.com/snowleopard/hadrian/issues/259#issuecomment-224618414.

comment:14 in reply to:  13 Changed 15 months ago by kaiha

Replying to thomie:

Quoting @erikd in https://phabricator.haskell.org/D2303#67070:

I'm pretty sure that will be handled by the Linux distros. They wouldn't ship an GNU as until their glibc handled these new relocations.

We have our first victim of this assumption: https://github.com/snowleopard/hadrian/issues/259#issuecomment-224618414.

This is the victim speaking. I experienced this problem on a Debian testing. So I think that the assumption of @erikd remains valid as long as we consider only stable Linux distributions.

comment:15 Changed 14 months ago by thomasjm

I'm another victim: this has been failing for me on Ubuntu 16.04 when trying to use IHaskell and IHaskell's display libraries--both the cryptonite package and the glib package are triggering this problem. (The stack resolver is lts-6.2.)

I think there are some workarounds I could use where I compile these packages with some stack settings like

ghc-options:

glib: -opta-Wa,-mrelax-relocations=no

rebuild-ghc-options: true

apply-ghc-options: everything

but I'd really appreciate if there were a 7.10.4 release that fixes this.

comment:16 Changed 14 months ago by rwbarton

Can you just build IHaskell as a dynamically linked executable? Then you would be off the dreaded ghci linker completely.

comment:17 Changed 14 months ago by thomie

Yes, what rwbarton says. I can reproduce the problem with a statically linked ihaskell, but --enable-executable-dynamic solves it:

$ cabal install -w ghc-7.10.3 ihaskell --enable-executable-dynamic
$ jupyter console --kernel haskell
Jupyter Console 4.1.1


In [1]:

You need to build all dependencies with --enabled-shared as well (set shared: True in .cabal/config).

Other things I had to install:

$ sudo apt-get install libzmq3-dev
$ pip install jupyter

comment:18 Changed 14 months ago by dkasak

I'm also affected on Arch Linux. If at all possible, please do release a 7.10.4 since there is no easy workaround.

comment:19 Changed 12 months ago by bgamari

Resolution: fixed
Status: mergeclosed
Note: See TracTickets for help on using tickets.