gdb source tests are failing in Ubuntu 15.04

Bug #1420556 reported by bugproxy
14
This bug affects 3 people
Affects Status Importance Assigned to Milestone
gdb (Ubuntu)
Confirmed
High
Matthias Klose

Bug Description

---Problem Description---
gdb source tests are failing in Ubuntu 15.04

---uname output---
Linux ubuntu 3.18.0-12-generic #13-Ubuntu SMP Thu Jan 29 13:44:26 UTC 2015 ppc64le ppc64le ppc64le GNU/Linux

Machine Type = P8

---Steps to Reproduce---
Install a Power VM LPAR with Ubuntu 15.04 ISO.
Then install gdb source and build and execute the same.

root@ubuntu:~# apt-get source gdb
root@ubuntu:~# cd gdb-7.8.2/
root@ubuntu:~/gdb-7.8.2# dpkg-buildpackage -b

                === gdb Summary ===

# of expected passes 25147
# of unexpected failures 280
# of unexpected successes 2
# of expected failures 66
# of unknown successes 1
# of known failures 59
# of unresolved testcases 11
# of untested testcases 21
# of unsupported tests 99
/root/gdb-7.8.2/build/objdir/gdb/testsuite/../../gdb/gdb version 7.8.2-0ubuntu1) -nw -nx -data-directory /root/gdb-7.8.2/build/objdir/gdb/testsuite/../data-directory

Package: gdb-7.8.2-0ubuntu1

I've reproduced the tests and looking at gdb.log, noticed that for some reason breakpoints for main() are being hit in an unexpected place and this is causing a lot of testcase failures. Also, this problem happens only when using gcc 4.9 (Ubuntu 15.04 default); it's not reproducible on gcc 4.8 or 5. This is still being investigated.

Moreover, in the gdb.python/python.exp specifically, there is this commit 55cfb2c4c8accd5031fd7c8167988fc4624e847c from upstream gdb that fixes the testcase, removing 19 of the unexpected failures.

I've created this testcase that exemplifies the issue with the 'breakpoint main' hit the unexpected place:

ubuntu@ubuntu:~$ cat array.c
int main (void)
{
  int array[1];

  return 0;
}
ubuntu@ubuntu:~$ gcc array.c -g -o array-4.9
ubuntu@ubuntu:~$ gdb -q ./array-4.9 -ex 'break main' -ex run
Reading symbols from ./array-4.9...done.
Breakpoint 1 at 0x1000060c: file array.c, line 3.
Starting program: /home/ubuntu/array-4.9

Breakpoint 1, main () at array.c:3
3 {
(gdb)

While with gcc-4.8, gdb stops at the expected place:

ubuntu@ubuntu:~$ gcc-4.8 array.c -g -o array-4.8
ubuntu@ubuntu:~$ gdb -q ./array-4.8 -ex 'break main' -ex run
Reading symbols from ./array-4.8...done.
Breakpoint 1 at 0x100005a0: file array.c, line 6.
Starting program: /home/ubuntu/array-4.8

Breakpoint 1, main () at array.c:6
6 return 0;
(gdb)

Comparing the assembly output generated by both gcc's, we can also notice a repeated '.loc 1 3 0' in the code that seems to cause this misplaced breakpoint:

ubuntu@ubuntu:~$ gcc array.c -g -o array-4.9.s -S
ubuntu@ubuntu:~$ cat array-4.9.s
(...)
main:
.LFB0:
        .file 1 "array.c"
        .loc 1 3 0
        .cfi_startproc
0: addis 2,12,.TOC.-0b@ha
        addi 2,2,.TOC.-0b@l
        .localentry main,.-main
        mflr 0
        std 0,16(1)
        std 31,-8(1)
        stdu 1,-64(1)
        .cfi_def_cfa_offset 64
        .cfi_offset 65, 16
        .cfi_offset 31, -8
        mr 31,1
        .cfi_def_cfa_register 31
        .loc 1 3 0 <-- repeated .loc
        ld 9,-28688(13)
        std 9,40(31)
        li 9,0
        .loc 1 6 0
        li 9,0
        .loc 1 7 0
        mr 3,9
        ld 10,40(31)
        ld 9,-28688(13)
        cmpld 7,10,9
        li 10,0
        li 9,0
        beq 7,.L3
        bl __stack_chk_fail
        nop
.L3:
(...)

If this additional .loc is removed, gdb is able to hit the breakpoint at the correct place.
Moreover, it might be worth mentioning that this additional .loc doesn't appear on gcc-5 output too, where this breakpoint issue is not reproducible as well.

bugproxy (bugproxy)
tags: added: architecture-ppc64le bugnameltc-121304 severity-high targetmilestone-inin1504
Revision history for this message
Ubuntu Foundations Team Bug Bot (crichton) wrote :

Thank you for taking the time to report this bug and helping to make Ubuntu better. It seems that your bug report is not filed about a specific source package though, rather it is just filed against Ubuntu in general. It is important that bug reports be filed about source packages so that people interested in the package can find the bugs about it. You can find some hints about determining what package your bug might be about at https://wiki.ubuntu.com/Bugs/FindRightPackage. You might also ask for help in the #ubuntu-bugs irc channel on Freenode.

To change the source package that this bug is filed about visit https://bugs.launchpad.net/ubuntu/+bug/1420556/+editstatus and add the package name in the text box next to the word Package.

[This is an automated message. I apologize if it reached you inappropriately; please just reply to this message indicating so.]

tags: added: bot-comment
affects: ubuntu → gdb (Ubuntu)
Revision history for this message
Steve Langasek (vorlon) wrote :

The gdb 7.9 test suite shows a large number of unexpected failures, but not the same number of them. It's probably safe to assume that this bug is still present, since from the description it's believed to be a toolchain issue (specific to Ubuntu gcc-4.9) and not a bug in gdb itself.

  === gdb Summary ===

# of expected passes 29093
# of unexpected failures 720
# of unexpected successes 2
# of expected failures 58
# of unknown successes 1
# of known failures 57
# of untested testcases 47
# of unresolved testcases 4
# of unsupported tests 198
/build/buildd/gdb-7.9/build/objdir/gdb/testsuite/../../gdb/gdb version 7.9-0ubuntu1) -nw -nx -data-directory /build/buildd/gdb-7.9/build/objdir/gdb/testsuite/../data-directory

https://launchpad.net/ubuntu/+source/gdb/7.9-0ubuntu1/+build/7012625

Revision history for this message
Steve Langasek (vorlon) wrote :

This appears to be a code generation issue in gcc-4.9; reassigning.

affects: gdb (Ubuntu) → gcc-4.9 (Ubuntu)
Changed in gcc-4.9 (Ubuntu):
assignee: nobody → Matthias Klose (doko)
Steve Langasek (vorlon)
Changed in gcc-4.9 (Ubuntu):
importance: Undecided → High
Revision history for this message
Matthias Klose (doko) wrote :

still tracking as a gdb issue for now

affects: gcc-4.9 (Ubuntu) → gdb (Ubuntu)
Revision history for this message
bugproxy (bugproxy) wrote : Comment bridged from LTC Bugzilla

------- Comment From <email address hidden> 2015-03-16 14:58 EDT-------
Hi,

any news regarding this issue? Is there anything we can do from our side to help?

I managed to retest this using community gcc 4.9 and the aforementioned problem of the unexpected place where 'breakpoint main' hits is not reproducible, as well as the additional .loc directive is not included in the assembler code.

Thanks for your support.

Revision history for this message
bugproxy (bugproxy) wrote :

------- Comment From <email address hidden> 2015-03-19 04:55 EDT-------
This is interesting, as this is exactly the behavior you get when debugging in gdb, and you've made changes in your code, and your breakpoints are now out of sync with your code. (because you've added or removed lines) It seem like the problem almost certainly has to be that the testsuite has some hard-code breakpoints, and these are out of sync with one or more files of the actual source code.

Revision history for this message
bugproxy (bugproxy) wrote :

------- Comment From <email address hidden> 2015-03-19 12:59 EDT-------
(In reply to comment #14)
> This is interesting, as this is exactly the behavior you get when debugging
> in gdb, and you've made changes in your code, and your breakpoints are now
> out of sync with your code. (because you've added or removed lines) It
> seem like the problem almost certainly has to be that the testsuite has some
> hard-code breakpoints, and these are out of sync with one or more files of
> the actual source code.

Actually this can be seen with this simple testcase (which is not part of gdb testsuite):

ubuntu@ubuntu:~$ cat array.c
int main (void)
{
int array[1];

return 0;
}

When using gcc-4.9 from community or gcc-4.8 from Ubuntu, 'breakpoint main' stops at line 5 ('return 0'), which is the expected behavior, while using the default gcc (4.9) from Ubuntu 15.04, it stops at line 2.

Thus, I can't see how this can be a problem with hard-code breakpoints from the testsuite.

Revision history for this message
Ciro Santilli 六四事件 法轮功 (cirosantilli) wrote :

It is well known that GDB has many failing tests. The wiki says: https://sourceware.org/gdb/wiki/TestingGDB

> One unfortunate characteristic of the GDB testsuite is that, even if GDB is horribly broken, many tests will still pass. You can't have much confidence that things are basically working with 356 failures. You should look through gdb.log and work through a bunch of them to get a feel for the state of things.

See also this issue: https://sourceware.org/bugzilla/show_bug.cgi?id=18067

Revision history for this message
Ciro Santilli 六四事件 法轮功 (cirosantilli) wrote :
Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in gdb (Ubuntu):
status: New → Confirmed
Revision history for this message
bugproxy (bugproxy) wrote :

------- Comment From <email address hidden> 2015-08-31 05:37 EDT-------
The aforementioned issue of the additional .loc directive that causes a misplaced breakpoint appears again on Ubuntu 15.10 gcc (5.2.1-15ubuntu5), causing several unexpected failures on gdb testsuite.

As mentioned before, this problem is not reproducible when using Ubuntu gcc-4.8 or upstream community gcc.

bugproxy (bugproxy)
tags: added: targetmilestone-inin1610
removed: targetmilestone-inin1504
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.