From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23171 invoked by alias); 28 Nov 2013 12:21:14 -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 23160 invoked by uid 89); 28 Nov 2013 12:21:13 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=2.8 required=5.0 tests=AWL,BAYES_40,GARBLED_BODY,RDNS_NONE autolearn=no version=3.3.2 X-HELO: relay1.mentorg.com Received: from Unknown (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 28 Nov 2013 12:21:12 +0000 Received: from svr-orw-exc-10.mgc.mentorg.com ([147.34.98.58]) by relay1.mentorg.com with esmtp id 1Vm0aW-0005oU-0n from Yao_Qi@mentor.com ; Thu, 28 Nov 2013 04:20:56 -0800 Received: from SVR-ORW-FEM-04.mgc.mentorg.com ([147.34.97.41]) by SVR-ORW-EXC-10.mgc.mentorg.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 28 Nov 2013 04:20:55 -0800 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.2.247.3; Thu, 28 Nov 2013 04:20:55 -0800 Message-ID: <529734C3.3080506@codesourcery.com> Date: Thu, 28 Nov 2013 12:30:00 -0000 From: Yao Qi User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130110 Thunderbird/17.0.2 MIME-Version: 1.0 To: Omair Javaid 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> In-Reply-To: <52966C69.3080506@linaro.org> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2013-11/txt/msg00880.txt.bz2 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. -- Yao (齐尧)