From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id ffbuOhPvt19JawAAWB0awg (envelope-from ) for ; Fri, 20 Nov 2020 11:30:11 -0500 Received: by simark.ca (Postfix, from userid 112) id E45691F08B; Fri, 20 Nov 2020 11:30:11 -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, URIBL_BLOCKED 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 1345C1E58F for ; Fri, 20 Nov 2020 11:30:11 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 65AED384A02B; Fri, 20 Nov 2020 16:30:10 +0000 (GMT) Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by sourceware.org (Postfix) with ESMTPS id 34504384A02B for ; Fri, 20 Nov 2020 16:30:04 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 34504384A02B 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 3ED3AAE49; Fri, 20 Nov 2020 16:30:03 +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> From: Tom de Vries Subject: Re: [PATCH] KFAIL variable-length array tests which fail with Clang Message-ID: <55e92b95-8b3b-6c4f-a572-9d7f836a1758@suse.de> Date: Fri, 20 Nov 2020 17:30:02 +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: <87y2iwgh90.fsf@tromey.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit 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/20/20 4:50 PM, Tom Tromey wrote: >>>>>> "Tom" == Tom de Vries writes: > > Tom> + gdb_byte last = block->data[block->size - 1]; > Tom> + baton->locexpr.is_reference > Tom> + = !(last == DW_OP_stack_value || last == DW_OP_implicit_value); > > I don't really understand the is_reference stuff In case a dwarf expression is used for an DW_AT_location attribute, by default it represents an address, and needs to be dereferenced to get the value. > but my first reaction > is that it must be incorrect somehow. > > 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. So, I'm referring to this bit in the dwarf standard (v4): ... 2.6.1.1.3 Implicit Location Descriptions An implicit location description represents a piece or all of an object which has no actual location but whose contents are nonetheless either known or known to be undefined. The following DWARF operations may be used to specify a value that has no location in the program but is a known constant or is computed from other locations and values in the program. ... 2.DW_OP_stack_value The DW_OP_stack_value operation specifies that the object does not exist in memory but its value is nonetheless known and is at the top of the DWARF expression stack. In this form of location description, the DWARF expression represents the actual value of the object, rather than its location. The DW_OP_stack_value operation terminates the expression. ... AFAIU, the spec specifically says how to interpret a DW_OP_stack_value at the end of the dwarf expression which is used a location description, and the code in the patch follows that reasoning. So, for my understanding, can you give an example of the problem you're envisioning? Thanks, - Tom