From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 101328 invoked by alias); 8 Dec 2019 18:30:24 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 101082 invoked by uid 89); 8 Dec 2019 18:30:14 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-8.2 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS autolearn=ham version=3.3.1 spammy=practical, doubt, HX-HELO:sk:gateway, HX-Spam-Relays-External:sk:gateway X-HELO: gateway34.websitewelcome.com Received: from gateway34.websitewelcome.com (HELO gateway34.websitewelcome.com) (192.185.150.114) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sun, 08 Dec 2019 18:30:03 +0000 Received: from cm13.websitewelcome.com (cm13.websitewelcome.com [100.42.49.6]) by gateway34.websitewelcome.com (Postfix) with ESMTP id 1C3E41D101 for ; Sun, 8 Dec 2019 12:30:01 -0600 (CST) Received: from box5379.bluehost.com ([162.241.216.53]) by cmsmtp with SMTP id e1JgiQsmX3Qi0e1JgifHvR; Sun, 08 Dec 2019 12:30:01 -0600 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tromey.com; s=default; h=Message-Id:Date:Subject:To:From:Sender:Reply-To:Cc:MIME-Version :Content-Type:Content-Transfer-Encoding:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=eE7vYIUK35CQ8bdrm6ZpkchA241xhxfy34P1shR8dSM=; b=OFCdcN5Iv7FYbFo9bTrVCLQ1rP gRjhpB1azp42Ohhpm0aEklkZcYAMcwdg6Xmj3/8S64xgQcWwSFJyEbkPomx+lDPt8LJ6neN38JHAz /kzhb1DEL/Hlv06lJQrl8nLHD; Received: from 75-166-123-50.hlrn.qwest.net ([75.166.123.50]:53618 helo=bapiya.Home) by box5379.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1ie1Jg-00456j-FM for gdb-patches@sourceware.org; Sun, 08 Dec 2019 11:30:00 -0700 From: Tom Tromey To: gdb-patches@sourceware.org Subject: [PATCH 00/55] Remove val_print Date: Sun, 08 Dec 2019 18:30:00 -0000 Message-Id: <20191208182958.10181-1-tom@tromey.com> X-SW-Source: 2019-12/txt/msg00275.txt.bz2 I've long wanted to remove the val_print API. It is used for the lowest level of value printing, and works by passing around an "exploded" value -- the type, offset, content, and address are passed as separate parameters. However, at some point we also had to start passing around the original outer-most value as well (to check content validity), which made the entire exercise a bit of a travesty. I had put off this refactoring because I couldn't think of a reviewable way to do it. However, recently I realized I could temporarily duplicate a lot of the code, rewriting as it made sense, and then at the end flip a switch to enable the new paths, while deleting the old API. This is the approach taken by this series. This is mildly ugly in two ways. First, it duplicates code. Of course, this is temporary, because the duplication is entirely removed in the final patch. So, I don't consider it a big deal. Second, there are some spots in the middle of this series that introduce some regressions. I tried to prevent this, but it turned out to be difficult to do. I am hoping that others agree with me that this is ok in this case; but if not I can try again. Patch #3 might not strictly be required. It exists to preserve the output in one particular case, but it's not clear if this is intended behavior or just a historical accident. It's possible that this series could result in too much memory allocation when printing very large objects. If this is a problem, I think it's possible to implement content sharing in struct value -- one of the nice things about C++ is that it makes this sort of thing more practical. While this series eliminates most of the val_print code, a few vestiges remain. Some low-level printing routines for particular types still accept old-style parameters. This could be cleaned up, but I haven't done so because this series is already too long. There's a lot of duplication in the value-printing code. For example, the Pascal code seems to be a cut-and-paste of the C++ code; I doubt (but don't really know) whether Pascal even has virtual base classes to worry about. So, another possible future direction would be to share even more of this code across languages. Regression tested by the buildbot. I don't propose checking this in until after the 9.1 branch has been made. Let me know what you think. Tom