From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31593 invoked by alias); 21 Aug 2012 03:27:04 -0000 Received: (qmail 31577 invoked by uid 22791); 21 Aug 2012 03:27:00 -0000 X-SWARE-Spam-Status: No, hits=-4.4 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL X-Spam-Check-By: sourceware.org Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 21 Aug 2012 03:26:46 +0000 Received: from svr-orw-fem-01.mgc.mentorg.com ([147.34.98.93]) by relay1.mentorg.com with esmtp id 1T3f77-00019i-CU from Yao_Qi@mentor.com ; Mon, 20 Aug 2012 20:26:45 -0700 Received: from SVR-ORW-FEM-04.mgc.mentorg.com ([147.34.97.41]) by svr-orw-fem-01.mgc.mentorg.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 20 Aug 2012 20:26:45 -0700 Received: from qiyao.dyndns.org (147.34.91.1) by svr-orw-fem-04.mgc.mentorg.com (147.34.97.41) with Microsoft SMTP Server id 14.1.289.1; Mon, 20 Aug 2012 20:26:44 -0700 Message-ID: <5032FFE6.4050202@codesourcery.com> Date: Tue, 21 Aug 2012 03:27:00 -0000 From: Yao Qi User-Agent: Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20120717 Thunderbird/14.0 MIME-Version: 1.0 To: Doug Evans CC: Subject: Re: [RFC] Don't allow setting register in non-innermost frame References: <1345170040-25959-1-git-send-email-yao@codesourcery.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit 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/msg00559.txt.bz2 On 08/21/2012 04:19 AM, Doug Evans wrote: > 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. > Yeah, it is convenient, but sometimes it is misleading. People who are clear on what is happening underneath can modify the frame/memory directly where the registers are saved. > 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." Even if the fact is not clear or misleading sometimes? > I'd like to hear more justification for this change. Unfortunately, I don't have extra justification here. I am writing a new MI notification when register is modified by 'set $reg=FOO' in console, similar to the patches on 'command parameter change' notification. When the register is modified in innermost frame, a MI notification (with frame info) can be sent to MI frontend, and frontend can update its register contents, such as "register view". However, if register is modified in non-innermost frame, the notification is not useful to frontend. Then, I started to think of the meaning of 'setting register in non-innermost frame', and proposed this change finally. -- Yao