This is the mail archive of the
mailing list for the Archer project.
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
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:
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 ?