Re: Interpretation of DW_AT_external

[Sami Wagiaalla <swagiaal at redhat dot com>]

Daniel Jacobowitz wrote:
> On Mon, Aug 25, 2008 at 11:50:14AM -0400, Sami Wagiaalla wrote:
> > > The name in GDB's symbol table will be "A::a".
> > Is this because the linkage_name is used ?.. I am trying to not depend on 
> > linkage_name. There are situations where A::a is visible as just a, or if 
> > it was enclosed in another namespace B it would be B::A::a.
>
> Yes, this is because linkage names are used in the symbol table.  As I
> said last week (the week before?) I have patches to avoid relying on
> DW_AT_MIPS_linkage_name; they also happen to work around the GCC bug
> that causes namespace.exp failures.  I hope I can post them tonight
> unless they end up depending on something in our internal tree.

Awesome... I didnt know that the namespace thing was going to lead me 
right back to the linkage_name issue, but I learned a ton by chasing 
this down.

> But after the patch we still use it if it's available and still store
> symbols with fully qualified names; 

Yeah that's cool... I am not opposed to using linkage_name as fall back.

> we just build up the names ourselves instead of by the demangler.

Gotcha... Are there mechanisms in place to handling the following situation:

namespace A{
  namespace B{
    int ab;
  }

  void func1{
    B::ab;
  }
}

void func2{
  A::B::ab;
}

If the user types print B::ab in func1 and A::B::ab in func2 will both 
be work correctly ?

> I agree that doing it block-wise would be superior.

Should I continue with the block quest then ?.. Do you think that we 
will run into issues in the future with storing the fully qualified names ?


Thanks
  Sami