Ada demangling has been enabled in 27fe47bd8a. Ada allows to overload function and procedures such as e.g. package P is procedure Proc (I : Integer); procedure Proc (B : Boolean); procedure Proc; end P; Such procedure will get mangled names such as P_Proc, P__Proc__1 and P__Proc__2. Demangled names will all be be P.Proc. When running an executable calling the above 3 procedures, kcachegrind then shows the calls to the 3 procedures as being calls to one single procedure P.Proc. In other words, it glues all the procedures, their calls and their costs in one single procedure. Using --demangle=no goes back to the 3.23 behaviour as it disables the Ada demangling (and not only the C++ demangling as wrongly indicated by the --help). Wondering if this callgrind behaviour is specific to Ada or if some other languages supporting overloading have the same behaviour. It might then be worth investigating if there is a solution to that and/or indicate in the user manual that using --demangle=no might be a good idea when using callgrind. Alternatively, callgrind should automatically disable demangling and kcachegrind and similar visualisation tools should do the demangling. In any case, the --help and likely user manual should indicate --demangle impact Ada, C++ and likely other demangling.
A small test program: ith P; use P; procedure T is begin for I in 1 .. 10_000_000 loop Proc (I); end loop; for I in 1 .. 5_000_000 loop Proc (I mod 2 = 0); end loop; for I in 1 .. 1_000_000 loop Proc; end loop; end T; package P is procedure Proc (I : Integer); procedure Proc (B : Boolean); procedure Proc; end P; package body P is Sum : Integer := 0; procedure Proc (I : Integer) is begin Sum := Sum + I; if Sum > Integer'Last / 2 then Sum := 0; end if; end Proc; Val : Boolean := False; procedure Proc (B : Boolean) is begin Val := Val or B; end Proc; N : Natural := 0; procedure Proc is begin N := N + 1; end Proc; end P;
(In reply to Philippe Waroquiers from comment #1) > A small test program: > > ith P; use P; Missing the leading w of the 'with P'.
I've unconditionally turned off Ada demangling with callgrind. Also added the bug497723 testcase to callgrind/tests with a grep for functions containing ada_ that should detect the mangled names. I tried the testcase that you provided, Philippe, and it seems to work as before. commit 2e029beff537aab841ea7a3b4207b8b5ff33c86f (HEAD -> master, origin/master, origin/HEAD) Author: Paul Floyd <pjfloyd@wanadoo.fr> Date: Sat Dec 21 20:46:40 2024 +0100 Bug 497723 - Enabling Ada demangling breaks callgrind differentiation between overloaded functions and procedures
(In reply to Paul Floyd from comment #3) > I've unconditionally turned off Ada demangling with callgrind. > Also added the bug497723 testcase to callgrind/tests with a grep for > functions containing ada_ that should detect the mangled names. > > I tried the testcase that you provided, Philippe, and it seems to work as > before. > > commit 2e029beff537aab841ea7a3b4207b8b5ff33c86f (HEAD -> master, > origin/master, origin/HEAD) > Author: Paul Floyd <pjfloyd@wanadoo.fr> > Date: Sat Dec 21 20:46:40 2024 +0100 > > Bug 497723 - Enabling Ada demangling breaks callgrind differentiation > between overloaded functions and procedures 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 ? 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.
(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
commit 2e029beff537aab841ea7a3b4207b8b5ff33c86f Author: Paul Floyd <pjfloyd@wanadoo.fr> Date: Sat Dec 21 20:46:40 2024 +0100 Bug 497723 - Enabling Ada demangling breaks callgrind differentiation between overloaded functions and procedures
I pushed 2 minor demangling related changes in the user manual and in some code comments.