http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54533
Bug #: 54533
Summary: breakpoint on C-style variadic function not hit at -O0
on amd64
Classification: Unclassified
Product: gcc
Version: 4.6.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: b.r.longb...@gmail.com
Created attachment 28156
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28156
nonreduced test case
I am continuing to make compilers fail in new and interesting ways :)
Problem:
If I set (in gdb) a breakpoint on a one of my C-style variadic functions, it
will not get hit. Other variadic functions are fine.
In addition, using gdb's 'step' command will cause the rest of the program to
run, instead of actually stepping (now that I think about it this is probably
an additional bug, in gdb)
This occurs only at optimization level zero. I have reproduced with g++ 4.6 and
4.7 from Debian and from Gentoo.
This likely only happens on amd64 because it is dependent on the way va_list is
implemented.
Analysis:
The problem is because the breakpoint gets set on the line after a jump that
happens to be taken. Someone who knows a lot more about debuginfo than I could
probably automate this and take gdb out of the picture.
=====
GNU gdb (GDB) 7.4.1-debian
Copyright (C) 2012 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-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /tmp/main...done.
(gdb) break cxxstdio::do_scanf
Breakpoint 1 at 0x401564: file src/common/cxxstdio.hpp, line 115.
(gdb) disassemble cxxstdio::do_scanf
Dump of assembler code for function cxxstdio::do_scanf(const_string, char
const*, ...):
0x0000000000401540 <+0>: push rbp
0x0000000000401541 <+1>: mov rbp,rsp
0x0000000000401544 <+4>: sub rsp,0xf0
0x000000000040154b <+11>: mov QWORD PTR [rbp-0x98],rcx
0x0000000000401552 <+18>: mov QWORD PTR [rbp-0x90],r8
0x0000000000401559 <+25>: mov QWORD PTR [rbp-0x88],r9
0x0000000000401560 <+32>: test al,al
0x0000000000401562 <+34>: je 0x401584
<cxxstdio::do_scanf(const_string, char const*, ...)+68>
0x0000000000401564 <+36>: movaps XMMWORD PTR [rbp-0x80],xmm0 // <--
breakpoint is here, not reached if the 'je' is taken, i.e. if al is 0
0x0000000000401568 <+40>: movaps XMMWORD PTR [rbp-0x70],xmm1
0x000000000040156c <+44>: movaps XMMWORD PTR [rbp-0x60],xmm2
0x0000000000401570 <+48>: movaps XMMWORD PTR [rbp-0x50],xmm3
0x0000000000401574 <+52>: movaps XMMWORD PTR [rbp-0x40],xmm4
0x0000000000401578 <+56>: movaps XMMWORD PTR [rbp-0x30],xmm5
0x000000000040157c <+60>: movaps XMMWORD PTR [rbp-0x20],xmm6
0x0000000000401580 <+64>: movaps XMMWORD PTR [rbp-0x10],xmm7
0x0000000000401584 <+68>: mov QWORD PTR [rbp-0xe8],rdx
0x000000000040158b <+75>: mov QWORD PTR [rbp-0xe0],rdi
0x0000000000401592 <+82>: mov QWORD PTR [rbp-0xd8],rsi
0x0000000000401599 <+89>: mov DWORD PTR [rbp-0xc8],0x18
0x00000000004015a3 <+99>: mov DWORD PTR [rbp-0xc4],0x30
0x00000000004015ad <+109>: lea rax,[rbp+0x10]
0x00000000004015b1 <+113>: mov QWORD PTR [rbp-0xc0],rax
0x00000000004015b8 <+120>: lea rax,[rbp-0xb0]
0x00000000004015bf <+127>: mov QWORD PTR [rbp-0xb8],rax
0x00000000004015c6 <+134>: lea rax,[rbp-0xe0]
0x00000000004015cd <+141>: mov rdi,rax
0x00000000004015d0 <+144>: call 0x401628 <const_array<char>::data()>
0x00000000004015d5 <+149>: lea rdx,[rbp-0xc8]
0x00000000004015dc <+156>: mov rcx,QWORD PTR [rbp-0xe8]
0x00000000004015e3 <+163>: mov rsi,rcx
0x00000000004015e6 <+166>: mov rdi,rax
0x00000000004015e9 <+169>: call 0x400c90 <vsscanf@plt>
0x00000000004015ee <+174>: leave
0x00000000004015ef <+175>: ret
End of assembler dump.
(gdb)
=====
The attached testcase is 500kB. I tried to reduce it, but changing what gets
fed to the preprocessor makes the bug sometimes go away (however any single
source is stable).
