https://bugs.kde.org/show_bug.cgi?id=497723
--- Comment #5 from Paul Floyd <pjfl...@wanadoo.fr> --- (In reply to Philippe Waroquiers from comment #4) > I am wondering what happens when we have a multi-language executable (e.g. > mixing Ada and C++). > When callgrind is used on such a mixed executable and the demangle is set to > "no" due when Ada is recognised, > will that not change the kcachegrind visualisation for C++, if kcachegrind > used to have demangled c++ names ? C++ (and other non-Ada language) demangling shouldn't be affected. It's only the global VG_(lang_is_ada) that controls Ada demangling that now gets turned off for callgrind. > Another question I have (not related to this bug but related to the Ada > demangling) is: > Ada demangling is enabled based on presence of __gnat_ada_main_program_name. > We can however have Ada libraries linked with a non Ada main program. > See e.g. > https://gcc.gnu.org/onlinedocs/gcc-14.2.0/gnat_ugn/Binding-with-Non-Ada-Main- > Programs.html > I have never done that myself but likely this main program name symbol will > not be present in such a case. > > Likely the (only?) safe way to do Ada demangling is to check the debug info > for the symbol and get the language from the dwarf information. I did think of that but it won't work for binaries without dwarf whereas the other demangling is based only on the command line option and the symbols themselves. We could add dwarf detection. Another possibility would be to extend --demangle to accept one or more languages in a list e.g., --demangle=ada,cxx -- You are receiving this mail because: You are watching all bug changes.
