Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Tom de Vries <tdevries@suse.de>
To: Tom Tromey <tom@tromey.com>,
	Gary Benson via Gdb-patches <gdb-patches@sourceware.org>
Subject: [gdb/testsuite] Add clang xfail in gdb.base/vla-ptr.exp
Date: Sat, 21 Nov 2020 18:16:47 +0100	[thread overview]
Message-ID: <814b137a-2dfc-8ab7-a53d-a3ade27bfccd@suse.de> (raw)
In-Reply-To: <3fe3ebd1-835d-b603-5cb1-254364731ec2@suse.de>

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

[ was:  Re: [PATCH][gdb/symtab] Fix gdb.base/vla-optimized-out.exp with
clang ]

On 11/20/20 4:15 PM, Tom de Vries wrote:
> [ was: Re: [PATCH] KFAIL variable-length array tests which fail with Clang ]
> 
> On 11/19/20 11:53 PM, Tom de Vries wrote:
>> On 11/18/20 5:14 PM, Tom Tromey wrote:
>>>>>>>> "Gary" == Gary Benson via Gdb-patches <gdb-patches@sourceware.org> writes:
>>>
>>> Gary> Clang describes the upper bounds of variable length arrays using
>>> Gary> a DW_AT_count attribute which references the DIE of a synthetic
>>> Gary> variable whose value is specified using a DW_AT_location.  In
>>> Gary> some cases GDB correctly handles these, but in other cases GDB
>>> Gary> adds an extra dereference causing the test to fail.  This commit
>>> Gary> marks these failing tests as caused by PR gdb/26905 when the
>>> Gary> test executable was built using Clang.
>>>
>>> Shouldn't we just fix the gdb bug instead?
>>
>> This adhoc patch:
> 
> Here's the complete and tested patch.
> 
> Any comments?
> 

Given the comments elsewhere in the thread, for now committing the
trivial testsuite part of the patch.

Thanks,
- Tom

[-- Attachment #2: 0001-gdb-testsuite-Add-clang-xfail-in-gdb.base-vla-ptr.exp.patch --]
[-- Type: text/x-patch, Size: 3179 bytes --]

[gdb/testsuite] Add clang xfail in gdb.base/vla-ptr.exp

When running gdb.base/vla-ptr.exp with clang-10, we run into this FAIL:
...
(gdb) print td_vla^M
$6 = 0x7fffffffd2b0^M
(gdb) FAIL: gdb.base/vla-ptr.exp: print td_vla
...

Clang 10.0.1 generates the following DWARF for td_vla.  A variable DIE:
...
 <2><19f>: Abbrev Number: 6 (DW_TAG_variable)
    <1a0>   DW_AT_location    : 0x39 (location list)
    <1a4>   DW_AT_name        : td_vla
    <1aa>   DW_AT_type        : <0x1ae>
....
with typedef type:
...
 <2><1ae>: Abbrev Number: 7 (DW_TAG_typedef)
    <1af>   DW_AT_type        : <0x1fc>
    <1b3>   DW_AT_name        : typedef_vla
...
pointing to:
...
 <1><1fc>: Abbrev Number: 11 (DW_TAG_array_type)
    <1fd>   DW_AT_type        : <0x1d3>
 <2><201>: Abbrev Number: 14 (DW_TAG_subrange_type)
    <202>   DW_AT_type        : <0x1f5>
...

The subrange type is missing the count attribute.  This was filed as
llvm PR48247 - "vla var with typedef'd type has incomplete debug info".

Mark this as xfail.

gdb/testsuite/ChangeLog:

2020-11-20  Tom de Vries  <tdevries@suse.de>

	* gdb.base/vla-ptr.exp: Add XFAIL.

---
 gdb/testsuite/gdb.base/vla-ptr.exp | 40 +++++++++++++++++++++++++++++++++++++-
 1 file changed, 39 insertions(+), 1 deletion(-)

diff --git a/gdb/testsuite/gdb.base/vla-ptr.exp b/gdb/testsuite/gdb.base/vla-ptr.exp
index 346ff00c524..23b3383903e 100644
--- a/gdb/testsuite/gdb.base/vla-ptr.exp
+++ b/gdb/testsuite/gdb.base/vla-ptr.exp
@@ -14,6 +14,7 @@
 # along with this program.  If not, see <http://www.gnu.org/licenses/>.
 
 standard_testfile
+set using_clang [test_compiler_info clang*]
 
 if { [prepare_for_testing "failed to prepare" ${testfile} ${srcfile}] } {
     return -1
@@ -38,4 +39,41 @@ gdb_test "print *vla_ptr" " = 2" "print *vla_ptr (bar)"
 
 gdb_breakpoint [gdb_get_line_number "vla_func_bp"]
 gdb_continue_to_breakpoint "vla_func_bp"
-gdb_test "print td_vla" " = \\\{4, 5, 6, 7, 8\\\}"
+
+gdb_test_multiple "print td_vla" "" {
+    -re -wrap " = \\\{4, 5, 6, 7, 8\\\}" {
+	pass $gdb_test_name
+    }
+    -re -wrap " = $hex" {
+	if { $using_clang } {
+	    # Clang 10.0.1 fails to generate complete type info, filed as
+	    # llvm PR48247 - "vla var with typedef'd type has incomplete
+	    # debug info".  See note below.
+	    xfail $gdb_test_name
+	    # Verify that despite the incomplete type info, the variable is
+	    # there and has the right value.
+	    gdb_test "p *td_vla@5" " = \\\{4, 5, 6, 7, 8\\\}"
+	} else {
+	    fail $gdb_test_name
+	}
+    }
+}
+
+# Clang 10.0.1 generates this DWARF for td_vla:
+#
+# A variable DIE:
+# <2><19f>: Abbrev Number: 6 (DW_TAG_variable)
+#    <1a0>   DW_AT_location    : 0x39 (location list)
+#    <1a4>   DW_AT_name        : td_vla
+#    <1aa>   DW_AT_type        : <0x1ae>
+# with type:
+# <2><1ae>: Abbrev Number: 7 (DW_TAG_typedef)
+#    <1af>   DW_AT_type        : <0x1fc>
+#    <1b3>   DW_AT_name        : typedef_vla
+# pointing to:
+# <1><1fc>: Abbrev Number: 11 (DW_TAG_array_type)
+#    <1fd>   DW_AT_type        : <0x1d3>
+# <2><201>: Abbrev Number: 14 (DW_TAG_subrange_type)
+#    <202>   DW_AT_type        : <0x1f5>
+#
+# The subrange type is missing the count attribute.

  reply	other threads:[~2020-11-21 17:16 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-16 17:17 [PATCH] KFAIL variable-length array tests which fail with Clang Gary Benson via Gdb-patches
2020-11-18 16:14 ` Tom Tromey
2020-11-19 22:53   ` Tom de Vries
2020-11-20 15:15     ` [PATCH][gdb/symtab] Fix gdb.base/vla-optimized-out.exp with clang Tom de Vries
2020-11-21 17:16       ` Tom de Vries [this message]
2020-11-20 15:50     ` [PATCH] KFAIL variable-length array tests which fail with Clang Tom Tromey
2020-11-20 16:30       ` Tom de Vries
2020-11-20 16:51         ` Tom Tromey
2020-11-23 10:34           ` [PATCH][gdb/symtab] Fix gdb.base/vla-optimized-out.exp with clang Tom de Vries
2020-11-25 14:50             ` Gary Benson via Gdb-patches
2020-11-25 15:25               ` Gary Benson via Gdb-patches
2020-11-25 20:05                 ` Tom de Vries
2020-11-26 10:10                   ` Gary Benson via Gdb-patches
2020-11-30 12:51             ` [committed][PATCH][gdb/symtab] " Tom de Vries

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=814b137a-2dfc-8ab7-a53d-a3ade27bfccd@suse.de \
    --to=tdevries@suse.de \
    --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