ThinLTO generates bad DWARF for libtest

[philipc]

nightly-2017-10-24 contains a libtest with bad DWARF:

$ /usr/bin/dwarfdump -i ~/.rustup/toolchains/nightly-2017-10-24-x86_64-unknown-linux-gnu/lib/libtest-f00235123717627d.so > /dev/null

/usr/bin/dwarfdump ERROR:  reference form with no valid local ref?!, offset=<0x00003085>:  DW_DLE_ATTR_FORM_OFFSET_BAD (119)

I can reproduce this if I recompile libtest locally:

$ cd src/libtest
$ RUSTFLAGS="-g -Ccodegen-units=16 -Zthinlto" cargo +nightly-2017-10-24 build --release
   Compiling term v0.0.0
   Compiling getopts v0.2.15
   Compiling test v0.0.0
    Finished release [optimized] target(s) in 8.77 secs
$ /usr/bin/dwarfdump -i ../target/release/libtest.so > /dev/null

/usr/bin/dwarfdump ERROR:  reference form with no valid local ref?!, offset=<0x0001b758>:  DW_DLE_ATTR_FORM_OFFSET_BAD (119)

The problem can be fixed by disabling thinlto (and keeping the codegen units is ok).

I noticed this with nightly-2017-10-24 because it is the first nightly compiled with thinlto, but the problem also occurs if I compile libtest with thinlto enabled using earlier compilers (eg nightly-2017-10-17).

Inspecting the DWARF, a DIE at that local ref offset does exist in another codegen unit, so the problem seems to be that we should be using a global ref instead.

[michaelwoerister]

cc'ing @tromey since he's been poking around in LLVM's DWARF generation code recently.

[nikomatsakis]

Sorta smells like an LLVM bug -- but hard to say. Who should investigate?

[nikomatsakis]

triage: P-medium

@alexcrichton if you are able to investigate as part of ThinLTO work would be great.

[alexcrichton]

It's likely that this is the cause of #45731, which even if the underlying segfault were fixed would likely prevent backtraces from happening on OSX.

[alexcrichton]

This is unfortunately not "automagically fixed" if we upgrade to LLVM 5

[alexcrichton]

Making progress.

First up, minimized Rust source code via creduce to get:

$ cat foo.rs
pub fn foo(a: &mut Vec<String>) {
    a.clone();
}
$ rustc +nightly --version
rustc 1.23.0-nightly (f0fe716db 2017-10-30)
$ rustc +nightly --crate-name test -g -Z thinlto --crate-type dylib foo.rs -O -C codegen-units=16
$ dwarfdump -i libtest.so > /dev/null
dwarfdump ERROR:  reference form with no valid local ref?!, offset=<0x0000131c>:  DW_DLE_ATTR_FORM_OFFSET_BAD (119)

Next up let's see if we can reduce it to one object file:

$ rustc +nightly --crate-name test -g -Z thinlto --crate-type dylib foo.rs -O -C codegen-units=16 --emit obj
$ for x in *.o; do echo $x; dwarfdump -i $x > /dev/null; done
test.test0-8787f43e282added376259c1adb08b80.rs.rust-cgu.o

dwarfdump ERROR:  reference form with no valid local ref?!, offset=<0x0000131c>:  DW_DLE_ATTR_FORM_OFFSET_BAD (119)
test.test1-8787f43e282added376259c1adb08b80.rs.rust-cgu.o
test.test2-8787f43e282added376259c1adb08b80.rs.rust-cgu.o
test.test3-8787f43e282added376259c1adb08b80.rs.rust-cgu.o
test.test4-8787f43e282added376259c1adb08b80.rs.rust-cgu.o
test.test5-8787f43e282added376259c1adb08b80.rs.rust-cgu.o
test.test6-8787f43e282added376259c1adb08b80.rs.rust-cgu.o
test.test7-8787f43e282added376259c1adb08b80.rs.rust-cgu.o
test.test8-8787f43e282added376259c1adb08b80.rs.rust-cgu.o
test.test9-8787f43e282added376259c1adb08b80.rs.rust-cgu.o

Ok looks like only one object file is invalid!

Let's take a look the LLVM IR:

$ rustc +nightly --crate-name test -g -Z thinlto --crate-type dylib foo.rs -O -C codegen-units=16 --emit llvm-ir
$ llc test.test0-*.ll -filetype=obj -O0 -o foo.o
$ dwarfdump -i foo.o > /dev/null

dwarfdump ERROR:  reference form with no valid local ref?!, offset=<0x00001496>:  DW_DLE_ATTR_FORM_OFFSET_BAD (119)

Ok let's see what's happening by minimizing the LLVM IR:

$ cat test.sh
#!/bin/bash

set -ex
llc \
  -filetype=obj \
   -O0 \
   $1 \
   -o foo.o

set +ex

dwarfdump -i foo.o &> foo.tmp

set -ex

if grep -q 'dwarfdump ERROR:  reference form with no valid local ref' foo.tmp; then
  echo interesting
  exit 1
fi
exit 0
$ chmod +x test.sh
$ bugpoint -compile-custom -compile-command=./test.sh ./test.test0-*.ll
...
$ llvm-dis bugpoint-reduced-simplified.bc

yielding this IR which I cleaned up a bit.

I checked out LLVM trunk, frobbed the IR a bit, and looks like the error is still on LLVM trunk.