From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id ukihMoZMj18pfQAAWB0awg (envelope-from ) for ; Tue, 20 Oct 2020 16:45:58 -0400 Received: by simark.ca (Postfix, from userid 112) id C09E51EFC3; Tue, 20 Oct 2020 16:45:58 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=0.4 required=5.0 tests=DKIM_SIGNED,MAILING_LIST_MULTI, RCVD_IN_BL_SPAMCOP_NET,T_DKIM_INVALID,URIBL_BLOCKED autolearn=no 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 553021EFBF for ; Tue, 20 Oct 2020 16:45:58 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 8E3443851C0C; Tue, 20 Oct 2020 20:45:57 +0000 (GMT) Received: from gateway34.websitewelcome.com (gateway34.websitewelcome.com [192.185.149.101]) by sourceware.org (Postfix) with ESMTPS id EA22B3857C7D for ; Tue, 20 Oct 2020 20:45:53 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org EA22B3857C7D Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=tromey.com Authentication-Results: sourceware.org; spf=fail smtp.mailfrom=tom@tromey.com Received: from cm12.websitewelcome.com (cm12.websitewelcome.com [100.42.49.8]) by gateway34.websitewelcome.com (Postfix) with ESMTP id 1021016BA31 for ; Tue, 20 Oct 2020 15:45:50 -0500 (CDT) Received: from box5379.bluehost.com ([162.241.216.53]) by cmsmtp with SMTP id UyVykKOJzn9FWUyVyk5BcW; Tue, 20 Oct 2020 15:45:50 -0500 X-Authority-Reason: nr=8 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tromey.com; s=default; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=YkAO2I70FdEZ+PGSOYYnZe5yiibZpADSncTLU3+J8ms=; b=ZgTdqLkWkfHAdLAI6SYoN6wnMv OWwX1g/Kg+8xC80leGRPxym1tHVmiZs7XOnxQhC3tWbKDvzwVzQ8o/TTiaV/6RYggvWNeDtGZD6OJ K4BgdO2FHsADdELUmZufN8Ig6; Received: from 75-166-102-113.hlrn.qwest.net ([75.166.102.113]:54516 helo=murgatroyd) by box5379.bluehost.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1kUyVx-000fhI-Rf; Tue, 20 Oct 2020 14:45:49 -0600 From: Tom Tromey To: Andrew Burgess Subject: Re: [PATCHv5 4/4] gdb/fortran: Add support for Fortran array slices at the GDB prompt References: <7832c05de858cfc8bf4b6abba4332523d0547805.1602439661.git.andrew.burgess@embecosm.com> X-Attribution: Tom Date: Tue, 20 Oct 2020 14:45:49 -0600 In-Reply-To: <7832c05de858cfc8bf4b6abba4332523d0547805.1602439661.git.andrew.burgess@embecosm.com> (Andrew Burgess's message of "Sun, 11 Oct 2020 19:12:13 +0100") Message-ID: <87pn5ciq2q.fsf@tromey.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box5379.bluehost.com X-AntiAbuse: Original Domain - sourceware.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - tromey.com X-BWhitelist: no X-Source-IP: 75.166.102.113 X-Source-L: No X-Exim-ID: 1kUyVx-000fhI-Rf X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: 75-166-102-113.hlrn.qwest.net (murgatroyd) [75.166.102.113]:54516 X-Source-Auth: tom+tromey.com X-Email-Count: 12 X-Source-Cap: ZWx5bnJvYmk7ZWx5bnJvYmk7Ym94NTM3OS5ibHVlaG9zdC5jb20= X-Local-Domain: yes 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: gdb-patches@sourceware.org Errors-To: gdb-patches-bounces@sourceware.org Sender: "Gdb-patches" >>>>> "Andrew" == Andrew Burgess writes: Andrew> The problem is that, as I see it, the current value contents model Andrew> assumes that an object base address will be the lowest address within Andrew> that object, and that the contents of the object start at this base Andrew> address and occupy the TYPE_LENGTH bytes after that. Andrew> ( We do have the embedded_offset, which is used for C++ sub-classes, Andrew> such that an object can start at some offset from the content buffer, Andrew> however, the assumption that the object then occupies the next Andrew> TYPE_LENGTH bytes is still true within GDB. ) Relatedly, we had a bug for a while where the Python val-print code could be given just a virtual base of an object, and it would then try to examine memory outside this buffer. I've also considered separating values from memory in some ways. Here's something weird in gdb... debug this program: #include char b[] = "hello"; struct x { char *x; }; int main() { struct x val; val.x = b; printf("%s\n", val.x); b[1] = 'q'; printf("%s\n", val.x); return 0; } If you stop at the first printf and "print val" you get: (gdb) p val $1 = { x = 0x40200c "hello" } Then at the second you can see: (gdb) p val $2 = { x = 0x40200c "hqllo" } (gdb) p $1 $3 = { x = 0x40200c "hqllo" } That is, the apparent value of the string in "$1" changed. This happens because the value only holds the pointer, the contents are read during printing. So, sometimes I've wondered if we want to fix that, by say attaching more memory to the value, say as it is printed. Another thing I've considered is maybe letting multiple values share some memory (to avoid duplicating large arrays); or maybe going the other way and lazily populating arrays when they are used purely as intermediate values. Kind of random thoughts, though I suppose the lazy array thing is similar to something you've done in this patch. Andrew> Where this hack will show through to the user is if they ask for the Andrew> address of an array in their program with a negative array stride, the Andrew> address they get from GDB will not match the address that would be Andrew> computed within the Fortran program. Calls for a second hack ;) FWIW I don't think I really have a problem with your proposed hack. Andrew> + /* Create a new offset calculator for TYPE, which is either an array or a Andrew> + string. */ Andrew> + fortran_array_offset_calculator (struct type *type) Single-argument constructors should normally be explicit. Andrew> +/* A base class used by fortran_array_walker. */ Andrew> +class fortran_array_walker_base_impl Andrew> +{ Andrew> +public: A class with only public methods (and no data) can just be a "struct". Andrew> + /* Constructor. */ Andrew> + explicit fortran_array_walker_base_impl () Andrew> + { /* Nothing. */ } Doesn't need the constructor. Andrew> +/* A class to wrap up the process of iterating over a multi-dimensional Andrew> + Fortran array. IMPL is used to specialise what happens as we walk over Andrew> + the array. See class FORTRAN_ARRAY_WALKER_BASE_IMPL (above) for the Andrew> + methods than can be used to customise the array walk. */ Andrew> +template Andrew> +class fortran_array_walker This seems to mix compile-time- and runtime- polymorphism. Maybe the idea was not to have virtual methods? But in that case this: Andrew> + /* Ensure that Impl is derived from the required base class. This just Andrew> + ensures that all of the required API methods are available and have a Andrew> + sensible default implementation. */ Andrew> + gdb_static_assert ((std::is_base_of::value)); ... seems weird. I guess the idea is to use method hiding as a kind of static overriding? But if any method is missing, compilation will just fail anyway. Tom