This is the mail archive of the
gdb-prs@sourceware.org
mailing list for the GDB project.
[Bug c++/15502] New: DW_AT_decl_line ignored in DW_TAG_imported_declaration
- From: "dblaikie at gmail dot com" <sourceware-bugzilla at sourceware dot org>
- To: gdb-prs at sourceware dot org
- Date: Mon, 20 May 2013 16:56:29 +0000
- Subject: [Bug c++/15502] New: DW_AT_decl_line ignored in DW_TAG_imported_declaration
- Auto-submitted: auto-generated
http://sourceware.org/bugzilla/show_bug.cgi?id=15502
Bug #: 15502
Summary: DW_AT_decl_line ignored in DW_TAG_imported_declaration
Product: gdb
Version: 7.6
Status: NEW
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned@sourceware.org
ReportedBy: dblaikie@gmail.com
Classification: Unclassified
The final test ("print x (from M::x)") in gdb.cp/nsusing.cc appears to be
passing by coincidence rather than design.
While testing GDB with Clang I discovered this bug as Clang fails this test
while its debug info looks wholely correct.
Given this:
namespace M
{
int x = 911;
}
namespace N
{
int x = 912;
}
int marker10 ()
{
using namespace M;
int y = x + 1; // marker10 stop
using namespace N;
return y;
}
GCC outputs two DW_TAG_imported_modules:
DW_TAG_imported_module
DW_AT_decl_file [DW_FORM_data1] (0x01)
DW_AT_decl_line [DW_FORM_data1] (0x11)
DW_AT_import [DW_FORM_ref4] ("N")
DW_TAG_imported_module
DW_AT_decl_file [DW_FORM_data1] (0x01)
DW_AT_decl_line [DW_FORM_data1] (0x11)
DW_AT_import [DW_FORM_ref4] ("M")
Notice that their line numbers are identical (that of the function) and
incorrect, and that they're in the reverse order of their appearance in the
source - leaving "M" second.
If you break at "return y" and print x with GCC's debug info you still print
M::x - it seems GDB is just taking the imported_modules in order & so the last
one "wins"
With Clang's debug info:
DW_TAG_imported_module
DW_AT_decl_file [DW_FORM_data1] (0x01)
DW_AT_decl_line [DW_FORM_data1] (0x0d)
DW_AT_import [DW_FORM_ref4] ("M")
DW_TAG_imported_module
DW_AT_decl_file [DW_FORM_data1] (0x01)
DW_AT_decl_line [DW_FORM_data1] (0x0f)
DW_AT_import [DW_FORM_ref4] ("N")
GDB, breaking at either marker10 stop or the return, print x finds N::x in both
cases - supporting the theory that GDB is just taking the "last" (or searching
in reverse order until it finds a successful lookup, presumably) rather than
using the source line information to correctly resolve these constructs.
--
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.