This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
[PATCH] Do emit certain artificial names into DW_AT_name in debug info
- From: Jakub Jelinek <jakub at redhat dot com>
- To: gcc-patches at gcc dot gnu dot org
- Cc: Roland McGrath <mcgrathr at google dot com>, Tom Tromey <tromey at redhat dot com>, Jan Kratochvil <jkratoch at redhat dot com>
- Date: Tue, 15 Jul 2014 10:32:30 +0200
- Subject: [PATCH] Do emit certain artificial names into DW_AT_name in debug info
- Authentication-results: sourceware.org; auth=none
- References: <20100722162552 dot GA18378 at tyan-ft48-01 dot lab dot bos dot redhat dot com> <20100722191935 dot 2EBF3400B8 at magilla dot sf dot frob dot com> <20100723120011 dot GH18378 at tyan-ft48-01 dot lab dot bos dot redhat dot com>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Fri, Jul 23, 2010 at 02:00:11PM +0200, Jakub Jelinek wrote:
> On Thu, Jul 22, 2010 at 12:19:35PM -0700, Roland McGrath wrote:
> > Similarly:
> >
> > <formal_parameter name=".omp_data_i" type="#ref1" artificial=1 location={locexpr}/>
> >
> > Should that really have a name? As it stands, the debugger is going to
> > present ".omp_data_i" as a resolvable identifier in this scope, as it
> > would for any other artifical parameter (such as C++ "this").
> >
> > Next:
> >
> > <structure_type ref="ref4" name=".omp_data_s.10" byte_size=0x8>
> >
> > This needs artificial=true too. Again, it seems quite questionable
> > whether the non-source name should appear at all. AIUI, this sort of
> > thing is exactly what DW_AT_description is for.
>
> This patch attempts to deal with the artificial names of DW_AT_artificial
> DIEs in debug info, as discussed yesterday on IRC.
>
> We can't just avoid emitting DW_AT_name for DECL_ARTIFICIAL decls,
> because e.g. for `this' we want to emit the name. And, there are also types
> for which we don't want to emit the made up names.
> The names are useful in dumps though, so instead of clearing them this patch
> steals one free bit and uses it to say that DECL_NAME resp. TYPE_NAME
> shouldn't be added into debug info.
> In the debug info names like array3_integer(kind=4), a.0, .omp_data_i
> etc. are undesirable though, they show up when listing variables, stand in
> in tab completion, etc.
>
> Tested on a short fortran array testcase as well as OpenMP C testcase,
> bootstrapped/regtested on x86_64-linux and i686-linux. Ok for trunk?
>
> 2010-07-23 Jakub Jelinek <jakub@redhat.com>
>
> * tree.h (struct tree_base): Add nameless_flag bitfield.
> (TYPE_NAMELESS, DECL_NAMELESS): Define.
> * omp-low.c (create_omp_child_function, scan_omp_parallel,
> scan_omp_task, lower_omp_taskreg): Set DECL_NAMELESS and/or
> DECL_ARTIFICIAL where needed.
...
Unfortunately, as mentioned in
https://bugzilla.redhat.com/show_bug.cgi?id=844959
it seems that GDB now (not sure since when) relies on DW_AT_name being
present on DW_TAG_subprogram (indeed in the DWARF standard there is "has
DW_AT_name", not "may have" wording) and that seems to be the reason why
almost nothing is debuggable in the outlined parallel or task regions.
Until we have some better attribute for this, I'd like to partially revert
this (i.e. restore the artificial name on DW_TAG_subprogram, keep
DECL_NAMELESS on all the other entities).
Bootstrapped/regtested on x86_64-linux and i686-linux, any objections
from checking this into trunk/4.8 (and 4.9.2 once 4.9.1 is out)?
2014-07-15 Jakub Jelinek <jakub@redhat.com>
* omp-low.c (create_omp_child_function): Don't set DECL_NAMELESS
on the FUNCTION_DECL.
--- gcc/omp-low.c.jj 2014-07-09 10:41:12.000000000 +0200
+++ gcc/omp-low.c 2014-07-14 16:49:41.950235683 +0200
@@ -1872,7 +1872,6 @@ create_omp_child_function (omp_context *
TREE_STATIC (decl) = 1;
TREE_USED (decl) = 1;
DECL_ARTIFICIAL (decl) = 1;
- DECL_NAMELESS (decl) = 1;
DECL_IGNORED_P (decl) = 0;
TREE_PUBLIC (decl) = 0;
DECL_UNINLINABLE (decl) = 1;
Jakub