From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id YSUcBE6Qu1/nRQAAWB0awg (envelope-from ) for ; Mon, 23 Nov 2020 05:34:54 -0500 Received: by simark.ca (Postfix, from userid 112) id DEAD41F0AB; Mon, 23 Nov 2020 05:34:53 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=MAILING_LIST_MULTI, URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 102DC1E552 for ; Mon, 23 Nov 2020 05:34:52 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 977283857C70; Mon, 23 Nov 2020 10:34:51 +0000 (GMT) Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by sourceware.org (Postfix) with ESMTPS id 84BAE3857C70 for ; Mon, 23 Nov 2020 10:34:49 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 84BAE3857C70 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=suse.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=tdevries@suse.de X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 77E86AC9A; Mon, 23 Nov 2020 10:34:48 +0000 (UTC) To: Tom Tromey References: <1605547055-25778-1-git-send-email-gbenson@redhat.com> <87mtzek5fv.fsf@tromey.com> <0a3f590c-2a76-e470-136f-e8f88aef1d17@suse.de> <87y2iwgh90.fsf@tromey.com> <55e92b95-8b3b-6c4f-a572-9d7f836a1758@suse.de> <874klkgeff.fsf@tromey.com> From: Tom de Vries Subject: [PATCH][gdb/symtab] Fix gdb.base/vla-optimized-out.exp with clang Message-ID: Date: Mon, 23 Nov 2020 11:34:47 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.4.0 MIME-Version: 1.0 In-Reply-To: <874klkgeff.fsf@tromey.com> Content-Type: multipart/mixed; boundary="------------8FC870F6C3AA30DEEBB61A31" Content-Language: en-US X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Gary Benson via Gdb-patches Errors-To: gdb-patches-bounces@sourceware.org Sender: "Gdb-patches" This is a multi-part message in MIME format. --------------8FC870F6C3AA30DEEBB61A31 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit [ was: Re: [PATCH] KFAIL variable-length array tests which fail with Clang ] On 11/20/20 5:51 PM, Tom Tromey wrote: >>> I don't really understand the is_reference stuff > > Tom> In case a dwarf expression is used for an DW_AT_location attribute, by > Tom> default it represents an address, and needs to be dereferenced to get > Tom> the value. > > Yeah, I guess I'd need to see some examples to understand why this > decision is made here and not at the point of use. > >>> Anyway, gdb can't do this sort of check. It will fail if the expression >>> has a different shape, which is completely allowed by the spec. > > Tom> AFAIU, the spec specifically says how to interpret a DW_OP_stack_value > Tom> at the end of the dwarf expression which is used a location description, > Tom> and the code in the patch follows that reasoning. > ... > Tom> So, for my understanding, can you give an example of the problem you're > Tom> envisioning? > > Nothing prevents an expression from ending with some other DW_OP_* with > 0x9f as an operand to the opcode. This would confuse this simple > checker. Or to put it another way, nothing guarantees that the last > byte of an expression is an opcode. I think it could even be both, > depending on a runtime condition, because AFAIK nothing prevents a DWARF > expression from branching to the middle of some other operation. Hmm, indeed, thanks for pointing this out. That means that this needs to be dealt with in the evaluator. AFAICT, DWARF_VALUE_STACK is used already to represent the DW_OP_stack_value op in the evaluator, it's just not used for this scenario. Another try below. Any more comments? Thanks, - Tom --------------8FC870F6C3AA30DEEBB61A31 Content-Type: text/x-patch; charset=UTF-8; name="0004-gdb-symtab-Fix-gdb.base-vla-optimized-out.exp-with-clang.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline; filename*0="0004-gdb-symtab-Fix-gdb.base-vla-optimized-out.exp-with-clan"; filename*1="g.patch" [gdb/symtab] Fix gdb.base/vla-optimized-out.exp with clang Consider test-case gdb.base/vla-optimized-out.exp, compiled using clang-1= 0. GDB fails to get the size of the vla a: =2E.. (gdb) p sizeof (a)^M Cannot access memory at address 0x6^M (gdb) FAIL: gdb.base/vla-optimized-out.exp: o1: printed size of \ optimized out vla =2E.. The relevant DWARF looks like this: the variable a: =2E.. <2><12b>: Abbrev Number: 5 (DW_TAG_variable) <12c> DW_AT_name : a <132> DW_AT_type : <0x189> =2E.. has type: =2E.. <1><189>: Abbrev Number: 10 (DW_TAG_array_type) <18a> DW_AT_type : <0x198> <2><18e>: Abbrev Number: 11 (DW_TAG_subrange_type) <18f> DW_AT_type : <0x19f> <193> DW_AT_count : <0x117> =2E.. with the count attribute equated to the value of this artificial variable= : =2E.. <2><117>: Abbrev Number: 4 (DW_TAG_variable) <118> DW_AT_location : 10 byte block: 75 1 10 ff ff ff ff f 1a 9= f \ (DW_OP_breg5 (rdi): 1; DW_OP_constu: 4294967295; DW_OP_and; DW_OP_stack_value) <123> DW_AT_name : __vla_expr0 <127> DW_AT_type : <0x182> <12b> DW_AT_artificial : 1 =2E.. The location description of the variable is terminated with DW_OP_stack_v= alue, which according to the DWARF spec means that "the DWARF expression repres= ents the actual value of the object, rather than its location". However, in attr_to_dynamic_prop, we set is_reference to true: =2E.. baton->locexpr.is_reference =3D true; =2E.. and use it in dwarf2_evaluate_property to dereference the value of the DW= ARF expression, which causes the access to memory at address 0x6. Fix this by ignoring the baton->locexpr.is_reference =3D=3D true setting = if the expression evaluation has ctx.location =3D=3D DWARF_VALUE_STACK, such= that we get: =2E.. (gdb) p sizeof (a)^M $2 =3D 6^M (gdb) PASS: gdb.base/vla-optimized-out.exp: o1: printed size of \ optimized out vla =2E.. Tested on x86_64-linux, with gcc. Tested the following test-cases (the ones mentioned in PR26905) on x86_64-linux with clang-10: - gdb.base/vla-optimized-out.exp - gdb.base/vla-ptr.exp - gdb.mi/mi-vla-c99 gdb/ChangeLog: 2020-11-20 Tom de Vries PR symtab/26905 * dwarf2/loc.c (dwarf2_locexpr_baton_eval): Add and handle is_reference parameter. (dwarf2_evaluate_property): Update dwarf2_locexpr_baton_eval call. gdb/testsuite/ChangeLog: 2020-11-22 Tom de Vries PR symtab/26905 * gdb.dwarf2/count.exp: Remove kfails. --- gdb/dwarf2/loc.c | 13 +++++++++---- gdb/testsuite/gdb.dwarf2/count.exp | 4 ---- 2 files changed, 9 insertions(+), 8 deletions(-) diff --git a/gdb/dwarf2/loc.c b/gdb/dwarf2/loc.c index 86d0ca496a2..fea49c340ff 100644 --- a/gdb/dwarf2/loc.c +++ b/gdb/dwarf2/loc.c @@ -2499,7 +2499,8 @@ dwarf2_locexpr_baton_eval (const struct dwarf2_loce= xpr_baton *dlbaton, struct frame_info *frame, const struct property_addr_info *addr_stack, CORE_ADDR *valp, - bool push_initial_value) + bool push_initial_value, + bool *is_reference) { if (dlbaton =3D=3D NULL || dlbaton->size =3D=3D 0) return 0; @@ -2546,9 +2547,12 @@ dwarf2_locexpr_baton_eval (const struct dwarf2_loc= expr_baton *dlbaton, =20 switch (ctx.location) { + case DWARF_VALUE_STACK: + *is_reference =3D false; + /* FALLTHROUGH */ + case DWARF_VALUE_REGISTER: case DWARF_VALUE_MEMORY: - case DWARF_VALUE_STACK: *valp =3D ctx.fetch_address (0); if (ctx.location =3D=3D DWARF_VALUE_REGISTER) *valp =3D ctx.read_addr_from_reg (*valp); @@ -2589,10 +2593,11 @@ dwarf2_evaluate_property (const struct dynamic_pr= op *prop, =3D (const struct dwarf2_property_baton *) prop->baton (); gdb_assert (baton->property_type !=3D NULL); =20 + bool is_reference =3D baton->locexpr.is_reference; if (dwarf2_locexpr_baton_eval (&baton->locexpr, frame, addr_stack, - value, push_initial_value)) + value, push_initial_value, &is_reference)) { - if (baton->locexpr.is_reference) + if (is_reference) { struct value *val =3D value_at (baton->property_type, *value); *value =3D value_as_address (val); diff --git a/gdb/testsuite/gdb.dwarf2/count.exp b/gdb/testsuite/gdb.dwarf= 2/count.exp index 6dcccb57409..ff11958827b 100644 --- a/gdb/testsuite/gdb.dwarf2/count.exp +++ b/gdb/testsuite/gdb.dwarf2/count.exp @@ -166,11 +166,7 @@ gdb_test "whatis static_array" "type =3D char \\\[5\= \\]" gdb_test "print static_array" " =3D \"world\"" gdb_test "print sizeof static_array" " =3D 5" =20 -setup_kfail "gdb/26905" *-*-* gdb_test "ptype vla_array" "type =3D char \\\[6\\\]" -setup_kfail "gdb/26905" *-*-* gdb_test "whatis vla_array" "type =3D char \\\[6\\\]" -setup_kfail "gdb/26905" *-*-* gdb_test "print vla_array" " =3D \"saluto\"" -setup_kfail "gdb/26905" *-*-* gdb_test "print sizeof vla_array" " =3D 6" --------------8FC870F6C3AA30DEEBB61A31--