From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com [IPv6:2a00:1450:4864:20::336]) by sourceware.org (Postfix) with ESMTPS id DA0BC385801D; Sun, 13 Dec 2020 12:21:18 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org DA0BC385801D Received: by mail-wm1-x336.google.com with SMTP id 3so12722734wmg.4; Sun, 13 Dec 2020 04:21:18 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=1xV85gArXao2/lmDrRovyIE9Oz4VfMuJQmDCeDd4BO0=; b=fBZoG57eqVHa3+XjYaJsfr0NJOa41rnFaGhwq/czDDLOF8VwSRmhtG2QcnBRXdZlCR O2EHwHlXjF4kO6McJM72RM5NomIx6nyDdw92wnZYWGhYhlBGlSS5c6O5AtjwoGYp9C1i jnaTRWZb+8N4DVcsSySJ6S+m9p3V2No76/EGYBZNs+Di1eXQ6Hu73gSA+NMEWHdbCCN8 wXMcfdShflTLQe7nnqziHZE9oIO6/WImuJlDttjzs9f2yyCl+MUlxbNk4CcDRWWcyYpJ 7zVHn6Q9OmsowASlcI4XiFW8TTye2JYBaurMeZ1dEx7dRmFwUqHiYEVXxwgXejVu9rPj jgbQ== X-Gm-Message-State: AOAM530Kyiy2gKbuHl/xh6orj+xkyQZiJxR3tLB4ZWIj0bpuV4dCcy7B GV0y5bHHxtA2BWEQebrHnnQ= X-Google-Smtp-Source: ABdhPJwdKRt8V4tvs0hWaN/A5Uu3T1M0OdG2p1XPoN62eeHpa+h/GeMaw+ZrwEC1kAS9e47Q4c7oaw== X-Received: by 2002:a05:600c:224b:: with SMTP id a11mr22749584wmm.97.1607862077916; Sun, 13 Dec 2020 04:21:17 -0800 (PST) Received: from [192.168.1.212] (host81-138-1-83.in-addr.btopenworld.com. [81.138.1.83]) by smtp.googlemail.com with ESMTPSA id y68sm27685201wmc.0.2020.12.13.04.21.16 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 13 Dec 2020 04:21:17 -0800 (PST) Content-Type: text/plain; charset=utf-8; delsp=yes; format=flowed Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: [patch, fortran] Optionally improve debugging of auxiliary variables From: Iain Sandoe In-Reply-To: Date: Sun, 13 Dec 2020 12:21:16 +0000 Cc: Fortran List , gcc-patches Content-Transfer-Encoding: 8bit Message-Id: <51553200-43F3-4D21-8535-478C1D21EE5D@googlemail.com> References: To: Thomas Koenig X-Mailer: Apple Mail (2.3273) X-Spam-Status: No, score=-3.6 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: fortran@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Fortran mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Dec 2020 12:21:20 -0000 Thomas Koenig via Fortran wrote: > Hello world, > > I have struggled with debugging the GENERIC generated by the > Fortran front end because it is only possible to look at the > code via -fdump-tree-original, but it is not possible to > inspect the values; additionally, the D.3456 form makes it > hard to read which variable is which. > > This patch adds a flag which gives all variables generated by > Fortran a name and makes them visible to debuggers. As an > example, compiler-generated variables now look like this > (for a "Hello, world" program): > > { > struct __st_parameter_dt dt_parm:0; > > dt_parm:0.common.filename = &"hello.f90"[1]{lb: 1 sz: 1}; > dt_parm:0.common.line = 2; > dt_parm:0.common.flags = 128; > dt_parm:0.common.unit = 6; > _gfortran_st_write (&dt_parm:0); > _gfortran_transfer_character_write (&dt_parm:0, &"Hello, world"[1]{lb: 1 sz: 1}, 12); > _gfortran_st_write_done (&dt_parm:0); > } > > Note the colon in the variable name, which I chose because it is > not in the user's namespace, and gdb does not choke on it. If it’s part of a symbol used by the rest of the toolchain (assembler, linker debugger) then it’s also important to note that some OS/tool pairs might be more constrained than the one you’ve tested. In particular, some assemblers will not accept all characters in an identifier. > In order to inspect the variables, you usually have to step > a bit through the generated assembly code, but you can then > print the values, manipulate them etc (and sometimes also hit > an internal error in gdb). > --- a/gcc/fortran/trans.c > +++ b/gcc/fortran/trans.c > @@ -73,6 +73,40 @@ gfc_advance_chain (tree t, int n) > return t; > + /* We want debug info for it. */ > + DECL_IGNORED_P (t) = 0; > + /* It should not be nameless. */ > + DECL_NAMELESS (t) = 0; > tree > @@ -80,6 +114,9 @@ gfc_create_var_np (tree type, const char *prefix) > { > tree t; > > + if (flag_debug_aux_vars) > + return create_var_debug_raw (type, prefix); > + > t = create_tmp_var_raw (type, prefix); > You could take advantage of the understanding of assembler identifier rules built into create_var_debug_raw() .. perhaps (totally untested)…. if (flag_debug_aux_vars) prefix = prefix ? prefix : “gfc”; t = create_tmp_var_raw (type, prefix); if (flag_debug_aux_vars) { /* We want debug info for it. */ DECL_IGNORED_P (t) = false; /* It should not be nameless. */ DECL_NAMELESS (t) = false; } return t; … or doens’t this approach work for some reason? cheers Iain