From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 67596 invoked by alias); 19 Oct 2017 13:27:16 -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 67584 invoked by uid 89); 19 Oct 2017 13:27:15 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-8.9 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_3,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=remembering, reflection, burgess, Burgess X-HELO: mail-wr0-f180.google.com Received: from mail-wr0-f180.google.com (HELO mail-wr0-f180.google.com) (209.85.128.180) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 19 Oct 2017 13:27:14 +0000 Received: by mail-wr0-f180.google.com with SMTP id u40so2464226wrf.10 for ; Thu, 19 Oct 2017 06:27:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=Qa+ww5oxCfJ0mIVFXg3G7PZGvnt8IzXQjS/A9JoeMfY=; b=UpPY3YLCD1gtifSXt1IQJVrUUPXLyvuiZQK6816S3thZ4ryyOWD+1jIUn7zi8E/69o 8LxD4TaDAXE74nYWDQV2gOlButkQtr7oHRWQ8ft0xtLIoO5jGycP71U64F/t44dfrp91 kQdeyNDCni9pGBSEhwi7BQt+Kiet30BMhve88R0UY1x0QUzHEtYLvBFu+XLxC2Y3eY37 BOYY1iW1voblP3w6wpQ9UeeqmGtT3V7uDorGsZd7RPEQ+0Efh9sDaoLlTUf6F8SzfsGk q5ppCCFAZ9vm2AY8kt1Rh/SF1LeW0KbvkFyhYXrIw/Ug2xNXLs73TBA+HmB5M1IWSh1V /9pA== X-Gm-Message-State: AMCzsaUZNU2M9o3YGdM59iampZlm+m/QEj29Dhr8ceTFJjVDhoNxJBCW rzSjItpU4anEfKIu5j8xBZUVgxI8 X-Google-Smtp-Source: ABhQp+SQC3/2Gfh95fUJX3dRzERqS+IkI7iTDgn7effRctPanVGZtg6ZC02lyzHMOZav8uVfLX1J9w== X-Received: by 10.223.187.79 with SMTP id x15mr1591615wrg.146.1508419631959; Thu, 19 Oct 2017 06:27:11 -0700 (PDT) Received: from localhost (host86-135-253-165.range86-135.btcentralplus.com. [86.135.253.165]) by smtp.gmail.com with ESMTPSA id x185sm777418wmx.35.2017.10.19.06.27.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 19 Oct 2017 06:27:11 -0700 (PDT) From: Andrew Burgess To: gdb-patches@sourceware.org Cc: donb@codesourcery.com, Andrew Burgess Subject: [PATCHv4 0/5] Fix -var-update for registers in frames 1 and up Date: Thu, 19 Oct 2017 13:27:00 -0000 Message-Id: X-IsSubscribed: yes X-SW-Source: 2017-10/txt/msg00609.txt.bz2 This patch revives a patch series that was first discussed here: https://sourceware.org/ml/gdb-patches/2016-06/msg00145.html with v3 being posted here: https://sourceware.org/ml/gdb-patches/2016-10/msg00069.html On reflection I worried that the approach taken in patch v3 might not cover all the cases, specifically, it would only spot cases where the register was the first operand in the expression. So something like this would not get the correct results: (gdb) -var-create - * "(void*) $sp" The more I thought about it, the more I wanted to revisit this suggestion: https://sourceware.org/ml/gdb-patches/2016-06/msg00159.html In this patch I extend the expression parser to log the innermost block when parsing a register expression, however, Don pointed out at the time, that this causes some test failures, as in some cases we don't want to log the innermost block for registers. The solution I'm proposing is to make the expression parser smarter, or rather, the innermost block tracking aspect of the expression parser. Previously the innermost block was a simple global pointer, which we set to NULL before parsing an expression, and read out afterwards. Now, the innermost block is an object, we reset the object before parsing an expression, and tell the object which types of innermost block we care about. During expression parsing all blocks are mentioned to the innermost block object, and it takes care of remembering the correct, innermost block. After the expression parse we query the innermost block object to find the correct answer. There's also a very related fix thrown in at the end of the series, in patch #5. There are new tests added, and results updated in the few places where things need to change, which is mainly as a result of the fix in patch #5. Tested on x86-64 Linux native and with native-gdbserver, no regressions. Thanks, Andrew --- Andrew Burgess (5): gdb: Remove duplicate declaration of a function gdb: New API for tracking innermost block gdb: PR mi/20395: Fix -var-update for registers in frames 1 and up gdb: Remove out of date comment gdb: Don't store a thread-id for floating varobj gdb/ChangeLog | 54 ++++++++ gdb/ada-exp.y | 6 +- gdb/ada-lang.c | 8 +- gdb/breakpoint.c | 12 +- gdb/c-exp.y | 20 +-- gdb/d-exp.y | 11 +- gdb/expression.h | 5 - gdb/f-exp.y | 7 +- gdb/go-exp.y | 7 +- gdb/m2-exp.y | 14 +-- gdb/objfiles.c | 2 +- gdb/p-exp.y | 12 +- gdb/parse.c | 18 ++- gdb/parser-defs.h | 54 +++++++- gdb/printcmd.c | 8 +- gdb/rust-exp.y | 8 +- gdb/symfile.c | 2 +- gdb/testsuite/ChangeLog | 14 +++ gdb/testsuite/gdb.mi/basics.c | 2 + gdb/testsuite/gdb.mi/mi-frame-regs.exp | 187 ++++++++++++++++++++++++++++ gdb/testsuite/gdb.mi/mi-var-create-rtti.exp | 5 +- gdb/testsuite/gdb.python/py-mi.exp | 12 +- gdb/varobj.c | 10 +- 23 files changed, 372 insertions(+), 106 deletions(-) create mode 100644 gdb/testsuite/gdb.mi/mi-frame-regs.exp -- 2.12.2