-dead_strip is now the default on Darwin
Concern Raised0a6c257de5c2

Authored by DemiMarie on Jan 5 2017, 4:06 PM.

Description

-dead_strip is now the default on Darwin

This enables subsections-via-symbols (-dead_strip) by default on Darwin.
The Static Reference Table (SRT) needs to be split in order for
-dead_strip to be helpful, so this commit always splits it on Darwin
systems.

Test Plan: GHC CI on Darwin

Reviewers: erikd, austin, bgamari

Reviewed By: erikd, bgamari

Subscribers: erikd, thomie

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

GHC Trac Issues: Trac #11040, Trac #13049

angerman raised a concern with this commit.Mar 6 2017, 12:06 AM
angerman added a subscriber: angerman.

After a few hours of bisecting ghc, this is the final commit that broken
building on macOS with llvm. (flavor quick-llvm on macOS).

git bisect bad
0a6c257de5c217436ec61fdf4b06bca059181f83 is the first bad commit
commit 0a6c257de5c217436ec61fdf4b06bca059181f83
Author: Demi Obenour <demiobenour@gmail.com>
Date:   Thu Jan 5 17:06:26 2017 -0500

    -dead_strip is now the default on Darwin

    This enables subsections-via-symbols (-dead_strip) by default on Darwin.
    The Static Reference Table (SRT) needs to be split in order for
    -dead_strip to be helpful, so this commit always splits it on Darwin
    systems.

    Test Plan: GHC CI on Darwin

    Reviewers: erikd, austin, bgamari

    Reviewed By: erikd, bgamari

    Subscribers: erikd, thomie

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

    GHC Trac Issues: #11040, #13049

The underlying problem is (at least that's my current working hypothesis):
In D206, I fixed -dead_strip, however that was later lost in subsequent
changes to the llvm backend. Therefore -dead_strip must not be used
with any code ghc produces with -fllvm, as that will result in the stripping
of info tables, as they are not visibly reachable to the linker. And hence this
commit enabling -dead_strip, effectively produces a stage2 compiler that
that misses all the info tables, and subsequently is dead on arrival.

The relevant trac issue is: Trac #13378

This commit now has outstanding concerns.Mar 6 2017, 12:06 AM

Alright, I believe this needs quite a bit more work.

Take the following test.ll.

; Lets have some global int x = 4
@x = global i32 10, align 4
; and two strings "p = %d\n" for the prefix data,
; as well as "x = %d\n" to print the (global) x value.
@.str = private unnamed_addr constant [8 x i8] c"x = %d\0A\00", align 1
@.str2 = private unnamed_addr constant [8 x i8] c"p = %d\0A\00", align 1

; declare printf, we'll use this later for printf style debugging.
declare i32 @printf(i8*, ...)

; define a main function.
define i32 @main() prefix i32 123 {
  ; obtain a i32 pointer to the main function.
  ; the prefix data is right before that pointer.
  %main = bitcast i32 ()* @main to i32*

  ; use the gep, to cmpute the start of the prefix data.
  %prefix_ptr = getelementptr inbounds i32, i32* %main, i32 -1
  ; and load it.
  %prefix_val = load i32, i32* %prefix_ptr

  ; print that value.
  %ret = call i32 (i8*, ...) @printf(i8* getelementptr inbounds ([8 x i8], [8 x i8]* @.str2, i32 0, i32 0), i32 %prefix_val)

  ; similarly let's do the same with the global x.
  %1 = alloca i32, align 4
  store i32 0, i32* %1, align 4
  %2 = load i32, i32* @x, align 4
  %3 = call i32 (i8*, ...) @printf(i8* getelementptr inbounds ([8 x i8], [8 x i8]* @.str, i32 0, i32 0), i32 %2)
  ret i32 0
}

Now:
clang test.ll && ./a.out will print:

p = 123
x = 10

However,
clang test.ll -dead_strip && ./a.out will print:

p = 0
x = 10

In conclusion, -dead_strip does not seem to respect prefix data. (llvm 3.9 that is.)

I currently have no idea how to fix this. And would therefore recommend to revert this commit,
however painful this may be, or at least ensure it's disabled for the llvm backend.

Friends, I'd really like to bring this to your attention. Please let me know where my debugging is faulty. I'd be glad if this can be resolved some other way.

rwbarton accepted this commit.May 1 2017, 12:06 AM
rwbarton added a subscriber: rwbarton.

See ensuing discussion at Trac #13378.