From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9958 invoked by alias); 17 Dec 2013 10:22:15 -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 9948 invoked by uid 89); 17 Dec 2013 10:22:14 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=0.2 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-wi0-f174.google.com Received: from mail-wi0-f174.google.com (HELO mail-wi0-f174.google.com) (209.85.212.174) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Tue, 17 Dec 2013 10:22:13 +0000 Received: by mail-wi0-f174.google.com with SMTP id z2so3443355wiv.7 for ; Tue, 17 Dec 2013 02:22:10 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=fryx+dMww3t8dHx1D7qTn27dtii8xIl8/qCADNIG7Pw=; b=KBwmDiWTDUN7xlPMXbMQUmC30tvqIK328iL5dZe1QE6MKX86660I3MY726xgkF7Iry YTFtJzwUsVri5onrkByNFNp9P7fJfl26MyuHN9AeK6dQbv7y/KQ3qgk7h1X7v+B5tjgi k6HrXylBBOctdIcNuem2w9e9BHAsKJM3F2T7EA8GlXC85M0FO48d7f0S/KFMjvu19xTj ifv/DaCjZ7TT39qaphK7IZMC2acgLo3m03cGMkgnOs4dWq3mSZnsaLJW0qWchYOCg46q c4xqJX0MXACHRmWGi4akoVid3aAyu2GG7i0YiFOQSV8lpuRlNqCZEAUk+y51nm6pRN/K DyQQ== X-Gm-Message-State: ALoCoQkRuvmxAHcHN8VWJSvJM/+1RcGelee3nlooPkdWclckegYwN5KRCMktIm5S0kEdas7NcwN0 X-Received: by 10.194.240.129 with SMTP id wa1mr18506957wjc.31.1387275730483; Tue, 17 Dec 2013 02:22:10 -0800 (PST) Received: from [192.168.1.104] ([182.185.199.248]) by mx.google.com with ESMTPSA id el8sm17237287wic.8.2013.12.17.02.22.07 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 17 Dec 2013 02:22:09 -0800 (PST) Message-ID: <52B025CC.5020209@linaro.org> Date: Tue, 17 Dec 2013 10:22:00 -0000 From: Omair Javaid User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Yao Qi CC: Oza Pawandeep , "gdb-patches@sourceware.org" , Patch Tracking Subject: Re: [PATCH 1/2] GDB process record and reverse debugging improvements for arm*-linux* References: <526884D5.309@codesourcery.com> <527C5856.50500@linaro.org> <5280ACE9.9050308@codesourcery.com> <52929080.1030304@linaro.org> <52966C69.3080506@linaro.org> <529734C3.3080506@codesourcery.com> In-Reply-To: <529734C3.3080506@codesourcery.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2013-12/txt/msg00617.txt.bz2 On Thu 28 Nov 2013 05:19:15 PM PKT, Yao Qi wrote: > On 11/28/2013 06:04 AM, Omair Javaid wrote: >>> gdb is for user space; and use space is not allowed to use SPSR >>>> directly using MSR instruction. >>>> so old code base + new code base whereever we have got SPSR getting >>>> modified we need to remove the same. >>>> >> I agree with you that we have to do a lot of rework of previous process record code. But I am not sure it would be productive for us to get working code out and loose the functionality or delay its submission. As Record/Replay is pretty much functional with this set of patches I am hoping that we can do a complete rework if required later on. >> > > If there is something broken related to the submissions, the common > practise could be one of them below: > > 1. Fix them first, > 2. Document the existing limitations/problems or write a test case to > kfail it. In this way, people are aware of this. > 3. Continue the submission and revisit the problems later. > > Personally, I choose one of them, depending on the complexity of fixing > the existing problems. This patch series is a large one, and based on > some existing code. I would like to fix existing problems first, before > doing something new, if it doesn't take much time on fixing existing > problems. These patches are preparatory, and usually simple. so they > have more chances to be reviewed in a timely manner. These preparatory > patches set up a context for your large patch series, and the context is > helpful to understanding your patch series. As a result, the review > process may be shortened. > > I don't want you to fix existing problems first, or take other actions. > Just let you know something submitters can do to help maintainers to > approve patches. > Ping! Looking for maintainer's approval for arm process record/replay improvement patches.