gdb source tests are failing in Ubuntu 15.04
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 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-
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/
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/
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/
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
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_offset 65, 16
.cfi_offset 31, -8
mr 31,1
.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.
tags: | added: architecture-ppc64le bugnameltc-121304 severity-high targetmilestone-inin1504 |
affects: | ubuntu → gdb (Ubuntu) |
Changed in gcc-4.9 (Ubuntu): | |
importance: | Undecided → High |
tags: |
added: targetmilestone-inin1610 removed: targetmilestone-inin1504 |
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/ FindRightPackag e. 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.]