public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: "Sharma, Alok Kumar" <AlokKumar.Sharma@amd.com>
To: Tom Tromey <tom@tromey.com>,
	"Sharma, Alok Kumar via Gdb-patches" <gdb-patches@sourceware.org>
Cc: "George, Jini Susan" <JiniSusan.George@amd.com>
Subject: RE: [PATCH] Accept functions with DW_AT_linkage_name present
Date: Tue, 19 Apr 2022 05:47:29 +0000	[thread overview]
Message-ID: <CO6PR12MB5491711D57C258444C71FC769EF29@CO6PR12MB5491.namprd12.prod.outlook.com> (raw)
In-Reply-To: <87pmley07s.fsf@tromey.com>

[-- Attachment #1: Type: text/plain, Size: 3230 bytes --]

Thanks Tom for your review comments. Attached is the updated patch to exclude DW_TAG_subroutine_type.

> Yes, but why?  Would there be something bad about using the linkage name for a variable?

Actually initially I tried without this conditions but that failed few gdb tests. Let me share the short testcase to explain.
-----------
#cat test.cxx
typedef enum
{
 DD, EE, FF
} anon_enum_t;

typedef anon_enum_t nested_anon_enum_t;
volatile nested_anon_enum_t var_s;

int
main ()
{
  asm ("" ::: "memory");
  return 0;
}
# g++ -g test.cxx -o test
---------------
I tried below command with the tag check and output matches what was there without this complete patch.
----------
# gdb -q test -ex "pt var_s" -ex "info types"
Reading symbols from test...
type = volatile enum : unsigned int {DD, EE, FF}
All defined types:

File test.cxx:
4:      typedef enum {...} anon_enum_t;
        int
6:      typedef enum {...} nested_anon_enum_t;
        unsigned int
-----------
When we remove that tag condition it looks like below
----------- 
/gdb -q test -ex "pt var_s" -ex "info types"
Reading symbols from test...
type = volatile enum 11anon_enum_t : unsigned int {DD, EE, FF}
All defined types:

File test.cxx:
2:      11anon_enum_t;
4:      typedef 11anon_enum_t anon_enum_t;
        int
6:      typedef 11anon_enum_t nested_anon_enum_t;
        unsigned int
---------- 

Please note the name "11anon_enum_t", which is linkage name (internal name) not exposed to user and showing that probably is not good. This linkage name is present only in case for C++ compilation only, in case the same code is in c and compile with gcc this linkage name is not present. So probably it is better to keep the output same as we get in C and not expose this linkage name for enums and keep it exposed only for functions. Please let me know if you differ, I shall change the testcases to suite the new output.

Regards,
Alok 

-----Original Message-----
From: Tom Tromey <tom@tromey.com> 
Sent: Monday, April 18, 2022 7:15 PM
To: Sharma, Alok Kumar via Gdb-patches <gdb-patches@sourceware.org>
Cc: Tom Tromey <tom@tromey.com>; Sharma, Alok Kumar <AlokKumar.Sharma@amd.com>; George, Jini Susan <JiniSusan.George@amd.com>
Subject: Re: [PATCH] Accept functions with DW_AT_linkage_name present

[CAUTION: External Email]

>>>>> Sharma, Alok Kumar via Gdb-patches <gdb-patches@sourceware.org> writes:

>> is this tag check really needed?

> I want to keep this limited to functions.

Yes, but why?  Would there be something bad about using the linkage name for a variable?

>    name = dwarf2_name (die, cu);
>    if (name == nullptr)
>      name = dw2_linkage_name (die, cu);

I guess if we avoided the tag check, this could just be done in dwarf2_name itself.

> +  if (name == nullptr && (die->tag == DW_TAG_subprogram
> +                          || die->tag == DW_TAG_subroutine_type
> +                          || die->tag == DW_TAG_inlined_subroutine
> +                          || die->tag == DW_TAG_entry_point))

If there is a reason to only check functions then you should remove DW_TAG_subroutine_type here, because that is a type, not a function.

Tom

[-- Attachment #2: 0001-PATCH-Accept-functions-with-DW_AT_linkage_name-prese.patch --]
[-- Type: application/octet-stream, Size: 5233 bytes --]

From 3887e4f9fa0097a3e58725d187305c6e4d281095 Mon Sep 17 00:00:00 2001
From: Alok Kumar Sharma <AlokKumar.Sharma@amd.com>
Date: Sun, 10 Apr 2022 18:50:01 +0530
Subject: [PATCH] [PATCH] Accept functions with DW_AT_linkage_name present

Currently GDB is not able to debug (Binary generated with Clang) variables
present in shared/private clause of OpenMP Task construct. Please note that
LLVM debugger LLDB is able to debug.

In case of OpenMP, compilers generate artificial functions which are not
present in actual program. This is done to apply parallelism to block of
code.

For non-artifical functions, DW_AT_name attribute should contains the name
exactly as present in actual program.
(Ref# http://wiki.dwarfstd.org/index.php?title=Best_Practices)
Since artificial functions are not present in actual program they not having
DW_AT_name and having DW_AT_linkage_name instead should be fine.

Currently GDB is invalidating any function not havnig DW_AT_name which is why
it is not able to debug OpenMP (Clang).

It should be fair to fallback to check DW_AT_linkage_name in case DW_AT_name
is absent.

Change-Id: I5048af6c0d07c227be762241da02582918ab66b8
---
 gdb/dwarf2/read.c                      |  7 ++++
 gdb/testsuite/gdb.threads/omp-task.c   | 28 ++++++++++++++
 gdb/testsuite/gdb.threads/omp-task.exp | 51 ++++++++++++++++++++++++++
 3 files changed, 86 insertions(+)
 create mode 100644 gdb/testsuite/gdb.threads/omp-task.c
 create mode 100644 gdb/testsuite/gdb.threads/omp-task.exp

diff --git a/gdb/dwarf2/read.c b/gdb/dwarf2/read.c
index 6dcd446e5f4..4014aa770e8 100644
--- a/gdb/dwarf2/read.c
+++ b/gdb/dwarf2/read.c
@@ -12000,6 +12000,8 @@ read_func_scope (struct die_info *die, struct dwarf2_cu *cu)
   baseaddr = objfile->text_section_offset ();
 
   name = dwarf2_name (die, cu);
+  if (name == nullptr)
+    name = dw2_linkage_name (die, cu);
 
   /* Ignore functions with missing or empty names.  These are actually
      illegal according to the DWARF standard.  */
@@ -20657,6 +20659,11 @@ new_symbol (struct die_info *die, struct type *type, struct dwarf2_cu *cu,
   baseaddr = objfile->text_section_offset ();
 
   name = dwarf2_name (die, cu);
+  if (name == nullptr && (die->tag == DW_TAG_subprogram
+                          || die->tag == DW_TAG_inlined_subroutine
+                          || die->tag == DW_TAG_entry_point))
+    name = dw2_linkage_name (die, cu);
+
   if (name)
     {
       int suppress_add = 0;
diff --git a/gdb/testsuite/gdb.threads/omp-task.c b/gdb/testsuite/gdb.threads/omp-task.c
new file mode 100644
index 00000000000..27aa3e805dc
--- /dev/null
+++ b/gdb/testsuite/gdb.threads/omp-task.c
@@ -0,0 +1,28 @@
+#include <stdio.h>
+#include <omp.h>
+
+int foo(int n) {
+  int share1 = 9, share2 = 11, share3 = 13, priv1, priv2, fpriv;
+  fpriv = n + 4;
+
+  if (n < 2)
+    return n;
+  else {
+#pragma omp task shared(share1, share2) private(priv1, priv2) firstprivate(fpriv) shared(share3)
+    {
+      priv1 = n;
+      priv2 = n + 2;
+      share2 += share3;
+      printf("share1 = %d, share2 = %d, share3 = %d\n", share1, share2, share3);
+      share1 = priv1 + priv2 + fpriv + foo(n - 1) + share2 + share3;
+    }
+#pragma omp taskwait
+    return share1 + share2 + share3;
+  }
+}
+
+int main() {
+  int n = 10;
+  printf("foo(%d) = %d\n", n, foo(n));
+  return 0;
+}
diff --git a/gdb/testsuite/gdb.threads/omp-task.exp b/gdb/testsuite/gdb.threads/omp-task.exp
new file mode 100644
index 00000000000..8f46658fe0d
--- /dev/null
+++ b/gdb/testsuite/gdb.threads/omp-task.exp
@@ -0,0 +1,51 @@
+# Copyright 2022 Free Software Foundation, Inc.
+
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 3 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program.  If not, see <http://www.gnu.org/licenses/>.
+
+# This file is part of the gdb testsuite.
+
+# Tests which verify (or not) that GDB can access shared and private
+# clauses of OpenMP task construct.
+
+standard_testfile
+
+set have_nested_function_support 0
+set opts {openmp debug}
+
+if {[prepare_for_testing "failed to prepare" $testfile $srcfile $opts]} {
+    return -1
+}
+
+if {[info procs gdb_openmp_setup] != ""} {
+    if {[gdb_openmp_setup $binfile] != ""} {
+	untested "could not set up OpenMP environment"
+	return -1
+    }
+}
+
+if {![runto_main]} {
+    return -1
+}
+
+gdb_breakpoint [gdb_get_line_number "omp task shared"]
+gdb_test "continue" ".*Breakpoint 2.*" "continue 1"
+gdb_test "print share1" "= 9"
+gdb_test "print share2" "= 11"
+gdb_test "print share3" "= 13"
+gdb_test "disable 2" ".*"
+gdb_breakpoint [gdb_get_line_number "share1 = priv1"]
+gdb_test "continue" ".*Breakpoint 3.*" "continue 2"
+gdb_test "print priv1" "= 10"
+gdb_test "print priv2" "= 12"
+gdb_test "print fpriv" "= 14"
-- 
2.25.1


  reply	other threads:[~2022-04-19  5:47 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-11  6:30 Sharma, Alok Kumar
2022-04-15 16:30 ` Tom Tromey
2022-04-18  8:07   ` Sharma, Alok Kumar
2022-04-18 13:45     ` Tom Tromey
2022-04-19  5:47       ` Sharma, Alok Kumar [this message]
2022-05-04  8:56         ` Sharma, Alok Kumar
2022-05-12  8:06           ` Sharma, Alok Kumar
2022-05-19  5:02             ` Sharma, Alok Kumar
2022-05-20 16:12         ` Tom Tromey
2022-05-22 16:10           ` Sharma, Alok Kumar

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CO6PR12MB5491711D57C258444C71FC769EF29@CO6PR12MB5491.namprd12.prod.outlook.com \
    --to=alokkumar.sharma@amd.com \
    --cc=JiniSusan.George@amd.com \
    --cc=gdb-patches@sourceware.org \
    --cc=tom@tromey.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).