This is the mail archive of the mailing list for the Archer project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Interpretation of DW_AT_external

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{

void func2{

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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]