[Dwarf-Discuss] name lookup w/ using directives

[Kendrick Wong]

In my example, I've used a search method which would search the current 
scope, then the names introduced by using directive, then the enclosing 
scopes.  That's how A::B::a is arrived at.

> If the successively enclosing scopes are searched for "a", it is not
> found in "func", then a search within namespace "C" does find A::C::a.
> What search method would skip searching the enclosing namespace?
In your example, enclosing scopes are searched first, consider this:
int a = 1;
namespace A {
  namespace B {
    int a = 2;
  }
  namespace C {
    int fun () {
      using namespace B;
      return a;     // returns A::B::a
    }
  }
}

Searching successively enclosing scope would yield ::a, but compiler would 
yield A::B::a.

> There are a number of quirks in C++ name resolution.  But I thought
> that DWARF did provide the debugger with the same structural info that
> the compiler uses in this process.
Yes, DWARF does capture the same structural info, but it does not capture 
how compiler use this information to perform name searching.  Arguably, 
this logic can be embedded within the debugger, but then it would have to 
derive where the enclosing namespace and the using namespace intersect, to 
figure out the correct point to introduce the using directive.

Thanks,
Regards,

Kendrick Wong 
z/OS C/C++ Compiler 
Common Debug Architecture 
C2/YGK/8200/MKM 
kendrick at ca.ibm.com 
Office:905-413-2865 Fax:905-413-4839 Tie:313-2865 




From:
Michael Eager <eager at eagercon.com>
To:
Kendrick Wong/Toronto/IBM at IBMCA
Cc:
dwarf-discuss at lists.dwarfstd.org
Date:
20/08/2008 11:46 AM
Subject:
Re: [Dwarf-Discuss] name lookup w/ using directives



Kendrick Wong wrote:
> 
> While working with namespaces, I've ran into cases where there is no 
> good way to determine the correct name lookup:
> 
> scenario A:
> namespace A {
>   namespace B {
>     int a = 1;
>   }
>   namespace C {
>     int func () {
>       using namespace B;
>       return a;     // returns A::B::a
>     }
>   }
> }
> 
> Sample DWARF:
> 10$: DW_TAG_namespace
>        DW_AT_name("A")
> 20$:   DW_TAG_namespace
>          DW_AT_name("B")
> 30$:     DW_TAG_variable
>            DW_AT_name("a")
> 40$:   DW_TAG_namespace
>          DW_AT_name("C")
> 50$:     DW_TAG_subprogram
>            DW_AT_name("func")
> 60$:       DW_TAG_imported_module
>              DW_AT_import(reference to 20$)
> 
> If a debugger stops in func(), and asks to examine 'a'.  A debugger can 
> try to search for 'a' within func(), failing that, it would look inside 
> namespace B, and in this case, it finds A::B::a, which is the correct 
> 'a' to find.
> 
> scenario B:
> namespace A {
>   namespace B {
>     int a = 1;
>   }
>   namespace C {
> *    int a = 2;    // introduce A::C::a*
>     int func () {
>       using namespace B;
>       return a;     // returns A::C::a
>     }
>   }
> }
> 
> Sample DWARF:
> 10$: DW_TAG_namespace
>        DW_AT_name("A")
> 20$:   DW_TAG_namespace
>          DW_AT_name("B")
> 30$:     DW_TAG_variable
>            DW_AT_name("a")
> 40$:   DW_TAG_namespace
>          DW_AT_name("C")
> *45$:     DW_TAG_variable         // introduce A::C::a*
> *           DW_AT_name("a")*
> 50$:     DW_TAG_subprogram
>            DW_AT_name("func")
> 60$:       DW_TAG_imported_module
>              DW_AT_import(reference to 20$)
> 
> If a debugger use the same name lookup technique as in scenario A, it's 
> going to find A::B::a, which is incorrect.

How does this happen?

If the successively enclosing scopes are searched for "a", it is not
found in "func", then a search within namespace "C" does find A::C::a.
What search method would skip searching the enclosing namespace?

> I think debugger needs a little more help (in the form of additional 
> DWARF info) to be able to perform the same name lookup as the compiler. 

There are a number of quirks in C++ name resolution.  But I thought
that DWARF did provide the debugger with the same structural info that
the compiler uses in this process.

>  I do have a solution in my head to solve the problem as well, but I 
> will wait until I get a confirmation that this is indeed a problem worth 

> diving into.

-- 
Michael Eager             eager at eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dwarfstd.org/private.cgi/dwarf-discuss-dwarfstd.org/attachments/20080820/0df00886/attachment.htm>