This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug debug/54826] New: gdb test case failure (bs15503) due to gaps in lexical block
- From: "arnez at linux dot vnet.ibm.com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Fri, 05 Oct 2012 14:48:54 +0000
- Subject: [Bug debug/54826] New: gdb test case failure (bs15503) due to gaps in lexical block
- Auto-submitted: auto-generated
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54826
Bug #: 54826
Summary: gdb test case failure (bs15503) due to gaps in lexical
block
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: debug
AssignedTo: unassigned@gcc.gnu.org
ReportedBy: arnez@linux.vnet.ibm.com
Current upstream gcc causes a regression with the gdb test case
bs15503.exp:
FAIL: gdb.cp/bs15503.exp: print s.length()
FAIL: gdb.cp/bs15503.exp: print s[0]
FAIL: gdb.cp/bs15503.exp: print s[s.length()-1]
FAIL: gdb.cp/bs15503.exp: print (const char *) s
FAIL: gdb.cp/bs15503.exp: print (const char *) s.substr(0,4)
FAIL: gdb.cp/bs15503.exp: print (const char *) (s=s.substr(0,4))
What happens is that the DWARF output for bs15503.cc wraps the string
variable "s" from StringTest<wchar_t>::testFunction() in a lexical
block with spurious gaps. The test case happens to set a break point
into one of these gaps and tries to access the variable from there,
which gdb (correctly) refuses.
For reference, here's a link to the source code:
http://sourceware.org/cgi-bin/cvsweb.cgi/~checkout~/src/gdb/testsuite/gdb.cp/bs15503.cc?rev=1.11&cvsroot=src
I've verified the failure on x86_64 and s390x. The regression was
introduced by: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=191494