debuginfo/evec-in-struct.rs fails on master

[bkoropoff]

Relevant output:

    error: line not found in debugger output: $2 = {x = {6, 7, 8}, y = {{9, 10}, {11, 12}}}

...

    $2 = {x = {6, 7, 8}, y = {{9, 10}, {12, 0}}}

GDB version:

GNU gdb (GDB) Fedora 7.7.1-19.fc20

I'm not sure why this fails on my system and not on the build bots.

[bkoropoff]

This seems to have started occuring after upgrading llvm

[brson]

cc @michaelwoerister

[michaelwoerister]

Interesting. I'll look into it.

[michaelwoerister]

I can't reproduce that. Are you doing anything special in your build? Any special configure-flags for example? Also, can you post the whole output from the test?

[bkoropoff]

I removed my rust installation and built from a clean build directory with no configure options and still reproduced it. Full output:

$ make check-stage1-debuginfo-gdb TESTNAME=evec-in-struct
cfg: build triple x86_64-unknown-linux-gnu
cfg: host triples x86_64-unknown-linux-gnu
cfg: target triples x86_64-unknown-linux-gnu
cfg: enabling more debugging (CFG_ENABLE_DEBUG)
cfg: host for x86_64-unknown-linux-gnu is x86_64
cfg: os for x86_64-unknown-linux-gnu is unknown-linux-gnu
cfg: using CC=gcc (CFG_CC)
cfg: no lualatex found, deferring to xelatex
cfg: no xelatex found, deferring to pdflatex
cfg: no pdflatex found, disabling LaTeX docs
cfg: no pandoc found, omitting PDF and EPUB docs
cfg: no llnextgen found, omitting grammar-verification
cfg: including test rules
cfg: antlr4 not available, skipping lexer test...
run debuginfo-gdb [x86_64-unknown-linux-gnu]: x86_64-unknown-linux-gnu/stage1/bin/compiletest

running 1 test
test [debuginfo-gdb] debuginfo/evec-in-struct.rs ... FAILED

using metrics ratchet: tmp/check-stage1-T-x86_64-unknown-linux-gnu-H-x86_64-unknown-linux-gnu-debuginfo-gdb-metrics.json
result of ratchet: 0 metrics added, 0 removed, 0 improved, 0 regressed, 0 noise
updated ratchet file

failures:

---- [debuginfo-gdb] debuginfo/evec-in-struct.rs stdout ----
    NOTE: compiletest thinks it is using GDB version 7.7

    error: line not found in debugger output: $2 = {x = {6, 7, 8}, y = {{9, 10}, {11, 12}}}

    status: exit code: 0
    command: gdb -quiet -batch -nx -command=x86_64-unknown-linux-gnu/test/debuginfo-gdb/evec-in-struct.debugger.script
    stdout:
    ------------------------------------------
    GNU gdb (GDB) Fedora 7.7.1-19.fc20
    Copyright (C) 2014 Free Software Foundation, Inc.
    License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
    This is free software: you are free to change and redistribute it.
    There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
    and "show warranty" for details.
    This GDB was configured as "x86_64-redhat-linux-gnu".
    Type "show configuration" for configuration details.
    For bug reporting instructions, please see:
    <http://www.gnu.org/software/gdb/bugs/>.
    Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.
    For help, type "help".
    Type "apropos word" to search for commands related to "word".
    Breakpoint 1 at 0xa80: file /home/bkoropoff/Source/rust/src/test/debuginfo/evec-in-struct.rs, line 112.
    static void evec-in-struct::zzz(void);
    [Thread debugging using libthread_db enabled]
    Using host libthread_db library "/lib64/libthread_db.so.1".

    Breakpoint 1, evec-in-struct::zzz () at /home/bkoropoff/Source/rust/src/test/debuginfo/evec-in-struct.rs:112
    112 fn zzz() { () }
    evec-in-struct::main () at /home/bkoropoff/Source/rust/src/test/debuginfo/evec-in-struct.rs:110
    110 }
    $1 = {x = {0, 1, 2}, y = -3, z = {4.5, 5.5}}
    $2 = {x = {6, 7, 8}, y = {{9, 10}, {12, 0}}}
    $3 = {x = {13, 14}, y = {15, 16}}
    $4 = {x = {17, 18, 19, 20, 21}}
    $5 = {x = {22, 23}, y = {24, 25}}
    A debugging session is active.

        Inferior 1 [process 27683] will be killed.

    Quit anyway? (y or n) [answered Y; input not from terminal]

    ------------------------------------------
    stderr:
    ------------------------------------------

    ------------------------------------------

    task '[debuginfo-gdb] debuginfo/evec-in-struct.rs' failed at 'explicit failure', /home/bkoropoff/Source/rust/src/compiletest/runtest.rs:1431



failures:
    [debuginfo-gdb] debuginfo/evec-in-struct.rs

test result: FAILED. 0 passed; 1 failed; 0 ignored; 0 measured

task '<main>' failed at 'Some tests failed', /home/bkoropoff/Source/rust/src/compiletest/compiletest.rs:255
make: *** [tmp/check-stage1-T-x86_64-unknown-linux-gnu-H-x86_64-unknown-linux-gnu-debuginfo-gdb.ok] Error 101

[bkoropoff]

Reduced test case:

fn main() {
    let _foo = [[1u],[1]];
}

gdb output:

(gdb) p _foo
$1 = {{1}, {140737488347040}}

[michaelwoerister]

Thanks a lot for the detailed information. I'll try to reproduce it again today. I wasn't able to do so so far, although you seem to have a very standard setup (Linux x86_64, recent GDB, no custom LLVM, ...)

[michaelwoerister]

So, I installed Fedora 20 in a VM and wouldn't you believe it, I can reproduce the bug exactly as you describe it. This is going to be interesting :)

[michaelwoerister]

LLVM has changed the way it encodes fixed-size arrays a few weeks back (llvm-mirror/llvm@06c1373) and for some reason GDB can't handle that on Fedora. I'm not sure yet how to deal with this problem since it doesn't seem to occur anywhere else and LLVM's new encoding is just as legal as the old one...

[bkoropoff]

GDB seems to think the inner [uint, ..1] has padding that doesn't exist:

(gdb) p sizeof(_foo[0])
$1 = 16
(gdb) p sizeof(_foo[0][0])
$2 = 8

So it's simply reading from the wrong offset when displaying the second element of the outer array. LLDB works fine.

[bkoropoff]

I just tested with stock gdb 7.7.1 built from source, and it worked! This suggests the issue is with a patch applied by Fedora. I'll grab the srpm and try to track it down.

[bkoropoff]

I imported the entire patch stack into git and bisected down to gdb-archer.patch, which makes extensive changes to DWARF handling. It seems to be from a gdb development branch: https://sourceware.org/gdb/wiki/ProjectArcher

[michaelwoerister]

Maybe Tom @tromey can help us out here?

tl;dr for Tom: LLVM changed the DWARF encoding of DW_TAG_subrange_type DIEs to use DW_AT_count instead of DW_AT_upper_bound. Most GDB versions can deal with this just fine but the one on Fedora, which contains patches from Project Archer, has problems handling this.

Do you have any suggestions on how to deal with this? Should we just report this in GDB's normal bug tracker? Any pointers from you would be much appreciated.