From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id r8DhMsjqxF98JwAAWB0awg (envelope-from ) for ; Mon, 30 Nov 2020 07:51:20 -0500 Received: by simark.ca (Postfix, from userid 112) id C2CCF1F0AB; Mon, 30 Nov 2020 07:51:20 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=0.3 required=5.0 tests=MAILING_LIST_MULTI,RDNS_NONE autolearn=no autolearn_force=no version=3.4.2 Received: from sourceware.org (unknown [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 725CE1E58E for ; Mon, 30 Nov 2020 07:51:20 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id D8E51388187D; Mon, 30 Nov 2020 12:51:19 +0000 (GMT) Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by sourceware.org (Postfix) with ESMTPS id EE9F63887035 for ; Mon, 30 Nov 2020 12:51:16 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org EE9F63887035 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 EA2E1AC91; Mon, 30 Nov 2020 12:51:15 +0000 (UTC) Subject: [committed][PATCH][gdb/symtab] Fix gdb.base/vla-optimized-out.exp with clang From: Tom de Vries 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> Message-ID: <64abcab8-b84c-775e-3e77-cbc40510cc17@suse.de> Date: Mon, 30 Nov 2020 13:51:15 +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: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit 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" On 11/23/20 11:34 AM, Tom de Vries wrote: > [ 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? > Committed. Thanks, - Tom