emit DW_AT_name for DW_TAG_GNU_formal_parameter_pack

[ecatmur]

Per http://wiki.dwarfstd.org/index.php?title=C%2B%2B0x:_Variadic_templates DW_TAG_GNU_formal_parameter_pack should have a DW_AT_name:

17$: DW_TAG_formal_parameter_pack
DW_AT_name("args")
18$: DW_TAG_formal_parameter
! no DW_AT_name attribute
DW_AT_type(reference to 13$)
(...)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70536

Send command:

git send-email -1 --to gcc-patches@gcc.gnu.org --subject-prefix "PATCH v3"

[mistarro]

Hi, what is the status of this change? I have a lot of variadic templated code to debug and it seems this is part of the solution... Is there anything I could help with?

[ecatmur]

I submitted it upstream: https://gcc.gnu.org/pipermail/gcc-patches/2022-March/591678.html

Unfortunately I don't have the email to ping. I'll try submitting again.

[ecatmur]

Resent: https://gcc.gnu.org/pipermail/gcc-patches/2023-January/609659.html
If you want, you could join the ML and ping it occasionally: https://gcc.gnu.org/mailman/listinfo/gcc-patches

[mistarro]

Thanks for the quick reply. I'm wondering also about gdb part as per your answer in https://stackoverflow.com/questions/36407941/inspect-template-parameter-pack-in-gdb (and your patch attached to https://sourceware.org/bugzilla/show_bug.cgi?id=17272). Do you have github fork for that as well? I guess this is a bit harder to update as there are some changes to gdb code. I tried myself to "blindly" merge but it didn't work (g++ compiled with the patch emitted names properly but of course it needs proper handling on gdb side): gdb worked but the symbols were not visible so I guess I could have made something wrong.

I work on heavily templated C++20 based library and support for variadic templates would greatly improve debugging experience. For now I use workaround to step into std::forward part which is repeated when preparing arguments but this still involves guessing the order.

[ecatmur]

Do you have github fork for that as well? I guess this is a bit harder to update as there are some changes to gdb code. I tried myself to "blindly" merge but it didn't work (g++ compiled with the patch emitted names properly but of course it needs proper handling on gdb side): gdb worked but the symbols were not visible so I guess I could have made something wrong.

Yes, see ecatmur/binutils-gdb#1. It took a little perseverance to get the patch through the various changes that have been made, but it should work now.

[ecatmur]

Resubmitted: https://gcc.gnu.org/pipermail/gcc-patches/2023-February/611366.html
Hopefully this time I'll remember to save the email for pinging.

[mistarro]

I've investigated the issue a bit deeper recently as I discovered that the following code snippet is partially supported by the official GCC release (tested on 14.1 only):

template <typename ... Us>
struct A {
  static int f(Us ... us) {
    return 0; // breakpoint
  }
};

template <typename ... Ts>
int g(Ts ... ts) {
  return A<Ts ...>::f(ts ...);
}

int main() {
  return g(1, 2.5);
}

with (unpatched) GDB stacktrace for the breakpoint at line 4:

#0  A<int, double>::f (us#0=1, us#1=2.5) at vt.cpp:4
#1  0x0000555555555171 in g<int, double> () at vt.cpp:10
#2  0x0000555555555147 in main () at vt.cpp:14

It seems that the issue with variadic parameters is only for function templates (f is not one). After examining gimple output, it's clear that the names for parameters are already there, they are just not exported in respective DIEs:

main ()
{
  int D.2099;

  D.2099 = g<int, double> (1, 2.5e+0);
  return D.2099;
  D.2099 = 0;
  return D.2099;
}


g<int, double> (int ts#0, double ts#1)
{
  int D.2102;

  D.2102 = A<int, double>::f (ts#0, ts#1);
  return D.2102;
}


A<int, double>::f (int us#0, double us#1)
{
  int D.2104;

  D.2104 = 0;
  return D.2104;
}

It's tempting to just change false to true just below your change (to emit names) but the problem is that GDB does not support it (DW_TAG_formal_parameter DIEs should appear directly under the respective DW_TAG_subprogram DIE).
So instead, I modified while (generic_decl_parm || parm) loop at gcc/dwarf2out.cc:24103 to just export all the DW_TAG_formal_parameter DIEs and separately all the DW_TAG_GNU_formal_parameter_pack DIEs (separate loop) without exporting formal parameters again:

      // emit all formal parameter packs
      while (generic_decl_parm)
	{
	  if (lang_hooks.function_parameter_pack_p (generic_decl_parm))
	    gen_formal_parameter_pack_die (generic_decl_parm, NULL, subr_die,
					   NULL);
	  generic_decl_parm = DECL_CHAIN (generic_decl_parm);
	}

      // emit all formal parameters
      while (parm)
	{
	  dw_die_ref parm_die = gen_decl_die (parm, NULL, NULL, subr_die);

	  if (early_dwarf
	      && parm == DECL_ARGUMENTS (decl)
	      && TREE_CODE (TREE_TYPE (decl)) == METHOD_TYPE
	      && parm_die
	      && (dwarf_version >= 3 || !dwarf_strict))
	    add_AT_die_ref (subr_die, DW_AT_object_pointer, parm_die);

	  parm = DECL_CHAIN (parm);
	}

This seems to work as expected (also with mixed normal + variadic parameters) with official GDB.

[mistarro]

BTW, VSCode and Eclipse have a problem debugging when symbols contain # character (most probably they don't quote symbol strings) so I also changed # to $ when generating parameter names in function make_ith_pack_parameter_name in file gcc/cp/pt.cc (line 3599 for release 14.1.0). Do you think this change would break anything? The $ sign is allowed in symbols as opposed to #.