From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21165 invoked by alias); 20 Aug 2012 20:19:54 -0000 Received: (qmail 21152 invoked by uid 22791); 20 Aug 2012 20:19:50 -0000 X-SWARE-Spam-Status: No, hits=-5.5 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,KHOP_RCVD_TRUST,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE,RP_MATCHES_RCVD,TW_EG X-Spam-Check-By: sourceware.org Received: from mail-vc0-f169.google.com (HELO mail-vc0-f169.google.com) (209.85.220.169) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 20 Aug 2012 20:19:37 +0000 Received: by vcbfl10 with SMTP id fl10so6236474vcb.0 for ; Mon, 20 Aug 2012 13:19:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=3PPNxF/IJ+q5gF5BgyTmF7ULDQ9zdKP24uOL+LsoTgg=; b=iryt+GQ1qWWdggU2v/h8JMs6X5ta+Ev/jPLMAcA8tIvtaTJz17G/3YhaIRKobw3DRs Tx6wwQa80YhDbVy+bs9zlKZsZN4dxGxXnPgWde/mr8BlM0KpuiQTZtUcGjvyHYouZynJ fVxxq+8ajVY2XAnbLxmlUyomgW6Unxd8VJ91zy6uT+zWtTsTXJber4IxU3dCVAXQLljJ AdLPvZiM2p4KWAjLoisrmPcB2gh21yOnfGBAZpW78aMIHchIzh0RvoQNQ7DKgEGl0W68 WUMubN6u9XddnzrTur4AC167YcxH64TzMmhYNCR904jYthPSl3wWagMHN5xOXKIXp0Hx YMPg== Received: by 10.52.73.5 with SMTP id h5mr9604136vdv.111.1345493976735; Mon, 20 Aug 2012 13:19:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.73.5 with SMTP id h5mr9604127vdv.111.1345493976631; Mon, 20 Aug 2012 13:19:36 -0700 (PDT) Received: by 10.52.27.11 with HTTP; Mon, 20 Aug 2012 13:19:36 -0700 (PDT) In-Reply-To: <1345170040-25959-1-git-send-email-yao@codesourcery.com> References: <1345170040-25959-1-git-send-email-yao@codesourcery.com> Date: Mon, 20 Aug 2012 20:19:00 -0000 Message-ID: Subject: Re: [RFC] Don't allow setting register in non-innermost frame From: Doug Evans To: Yao Qi Cc: gdb-patches@sourceware.org Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true X-Gm-Message-State: ALoCoQmx+GbfcUa4Xz6M/pryJV7sQV7Dz5DDjNaNwHuXOh86VwvdNGB+EswisJRU4isGY245zi276+BDx+1uzumrZbnz5DYou/yxQ872doVYQM8NZ544tEf3a1W4RLje6WVzY06xM9LpsVVeSkL4F3sDL80n1CeHXjcV1GYjcHJDEcx73KbmwdaG3uC8gDt2jhOwlqfaFqiHZqhGON8pZMO+5WNLPq+nmg== X-IsSubscribed: yes 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 X-SW-Source: 2012-08/txt/msg00558.txt.bz2 On Thu, Aug 16, 2012 at 7:20 PM, Yao Qi wrote: > Hi, > When playing with 'set $reg=0xXXX', I am thinking about the expected > behaviour of setting register when the frame is not innermost. Current > GDB will invalidate regcaches and reinit frache_caches for any register > changes (on innermost and non-innermost frame). However, the semantics > of 'setting register on non-innermost frame' is tricky. On innermost > frame, 'setting register' means writing something to register in cpu, > while on non-innermost frame, it means writing something to either > real register (regcache) or memory (frame). On the other head, I am > trying to figure out a situation that user has to set register on > non-innermost frame. Why does this user have to do that? > > Literally, IMO, 'set $reg=0xXXXX' means 'setting the cpu register $reg > to value 0xXXX', which is simple and clear. I propose to restrict > setting register in innermost frame only. WDYT? > > Regression tested on x86_64-linux. Surprisingly, we don't have a test > case for 'set register', so I add one. In the future, I plan to add > more tests here for 'set register', such as 'set some bits of a register' > and 'set multiple registers in one time', to cover the different > paths in value_assign for 'lval_register'. I wonder if there'll be a bit of a gnome vs kde battle here. :-) [the analogy isn't entirely accurate, but it's the best one I could think of] fwiw, I've been able to work around corrupt, or otherwise not completely useful, core files by setting registers in non-innermost frames. Granted, I knew what was happening underneath the covers, so to speak, and I could have done things differently, but I like this capability. If gdb had started out disallowing changing registers in non-innermost frames, we mightn't be thinking of restricting it now. "It's easier to relax restrictions than it is to impose them after the fact." I'd like to hear more justification for this change. I *could* accept a warning when changing a register in a non-innermost frame, fwiw.