Demangling dem470.exe not working on variable name

I suspect a bug somewhere in the tool chain.  Usually, the DW_AT_name attribute shows you the demangled name.  Thus, using the demangler on ofd470 output is not normally needed.  But even after running dem470 both the DW_AT_name and DW_AT_TI_symbol_name attribute look wrong.

Please submit a test case so we can investigate.  We would be pleased to get your .out file.  However, if you are reluctant to do that, an object file (not linked) which contains the definition of the problem variable should be enough.  We also need to know how the name appears in the original source.

Thanks and regards,

-George

Hi George,

I managed to create an "empty" project derived form my own that still has this issue.

6622.Test TI.rar

You should be able to compile it and access the .out file. I add a command in the post-build in order to execute the DT.bat file that extract the Dwarf from the .out and then demangle the result file. You will be able to compare both files, Application.xml and AppDemangle.xml), in order to view the demangling result. If you search the __b_ string you will see that some DW_AT_TI_symbol_name have not been demangled.

Thank you.

David

Occasionally the compiler generates mangled names which are only used internally.  Such names are never demangled.  A derived class can refer to a data member of the base class without any special syntax.

class base {
   int data_in_base;
   ...
};

class derived : public base {
   int data_in_derived;
   ...
};

class derived d_obj;
...

     // Refer to base class data
     d_obj.data_in_base = 10;  

But the type information stored for class derived must include the fact that all the public data members in base are available.  So, it looks like this ...

class derived {
   class base __b_mangled_name_here;
   int data_in_derived;
   ...
};

See how the mangled name is used?  There is no reason to expose that name at user level.  But it is maintained internally, among other places, in the Dwarf type information.  There are other such mangled names which are ignored by the demangler.

Thanks and regards,

-George

Hi George,

I understand what you explained and to a certain point it makes sense. However, it would be appreciate if this behaviour is documented because it tends to be confusing since the dem470.exe application is supposed to demangle every mangled name (which is clearly not the case). I still don't see why the demangling of these variables was not included in the dem470 application in the beginning, why not demangling everything and that's it. Inmy case this information would have been interresting especially when the base class is a template. But I may have found another way to extract the information of the base members using other data in the dwarf.

Thanks for the answer. I appreciate your time.

David.

David Henri said:

I still don't see why the demangling of these variables was not included in the dem470 application

If the source of a mangled name is some entity defined by the user, then dem470 will demangle it.  But internal names like the one in the example above, despite their similarity to user mangled names, are not mangled.  The name you see is the internal name auto-generated by the compiler.  Thus, there is nothing for dem470 to do.

Thanks and regards,

-George