rustc puts zero-initalized structs in .data instead of .bss if they contain padding

[whitequark]

E.g.:

const DMA_BUFFER_SIZE: usize = 8 * 1024 * 1024;

struct DmaRecorder {
    active:   bool,
    buffer:   [u8; DMA_BUFFER_SIZE],
    data_len: usize
}

static mut DMA_RECORDER: DmaRecorder = DmaRecorder {
    active:   false,
    buffer:   [0; DMA_BUFFER_SIZE],
    data_len: 0
};

$ size -Ax libt.rlib
t.0.o   (ex libt.rlib):
section                                             size   addr
.text                                                0x0    0x0
.text._ZN4drop17h735fab7fd9067161E                   0x6    0x0
.data._ZN1t12DMA_RECORDER17h7409bdfe01c28df8E   0x800010    0x0
.note.GNU-stack                                      0x0    0x0
.eh_frame                                           0x30    0x0
Total                                           0x800046

(and this results in a 8MB file, etc).

Note that this works:

const DMA_BUFFER_SIZE: usize = 8 * 1024 * 1024;

struct DmaRecorder {
    buffer:   [u8; DMA_BUFFER_SIZE],
    data_len: usize
}

static mut DMA_RECORDER: DmaRecorder = DmaRecorder {
    buffer:   [0; DMA_BUFFER_SIZE],
    data_len: 0
};

[whitequark]

Looking at LLVM IR:

@_ZN1t12DMA_RECORDER17h7409bdfe01c28df8E = 
    internal global { i1, [8388608 x i8], [7 x i8], i64 } 
                    { i1 false, [8388608 x i8] zeroinitializer, [7 x i8] undef, i64 0 }, align 8

It looks like that the padding undef is troublesome.

[whitequark]

So I'm not sure what to do here. This is clearly also an LLVM issue, but with LLVM being supported down to 3.7, fixing just LLVM doesn't seem enough.

[rkruppe]

If it's indeed an LLVM bug, fixing LLVM and cherry-picking the patch into https://github.com/rust-lang/llvm/ may be the best we can do. This is often the case with LLVM issues, even with blatant miscompiles (e.g., #40593).

[nagisa]

I tagged this as I-slow in a sense that it generates an executable that is suboptimal (i.e. what is the spirit of the tag).

[rkruppe]

Relevant thread on llvm-dev: http://lists.llvm.org/pipermail/llvm-dev/2017-April/112305.html (well, not a thread just yet)

[jonas-schievink]

Still reproduces on 1.20 and nightly-2017-09-15 (1.22.0-nightly (5dfc84cfa 2017-09-14)). Did the patch ever happen?

[varkor]

I have a patch for this here. It's been accepted, so now it just needs to be merged and then we should be able to cherry-pick it.

[varkor]

This has now been merged in. Should be ready for cherry-picking!

[japaric]

This has now been merged in. Should be ready for cherry-picking!

Yay! Thanks @varkor!

If someone wants to drive this to the finish line the backporting process looks like this:

• Fork rust-lang/llvm. Make a new branch -- base it off the rust-llvm-release-6-0-0 branch. Cherry pick the changes (https://reviews.llvm.org/rL324424). Send a PR to rust-lang/llvm (target branch is rust-llvm-release-6-0-0).

• Once that PR is merged, fork rust-lang/rust. Make a new branch -- base it off the master branch. Update the src/llvm submodule to point to the new HEAD of the rust-llvm-release-6-0-0 branch. Send a PR with the updated submodule to rust-lang/rust (target branch is master).

• Cross your fingers and hope that bors likes the changes 🙂

Feel free to cc me on those PRs. I can only r+ the rust-lang/rust PR, though.

[varkor]

@japaric: thanks for laying out the steps! I always meant to follow up here, but never got around to it (and wasn't sure what the process was on the rust/llvm end). I've followed the first steps: hopefully we can soon get this fix in for good! :)