[Bug c++/15502] New: DW_AT_decl_line ignored in DW_TAG_imported_declaration

["dblaikie at gmail dot com" <sourceware-bugzilla@sourceware.org>]

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.