Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Yao Qi <yao@codesourcery.com>
To: Omair Javaid <omair.javaid@linaro.org>
Cc: Oza Pawandeep <oza.pawandeep@gmail.com>,
	"gdb-patches@sourceware.org"	<gdb-patches@sourceware.org>,
	Patch Tracking <patches@linaro.org>
Subject: Re: [PATCH 1/2] GDB process record and reverse debugging improvements for arm*-linux*
Date: Thu, 28 Nov 2013 12:30:00 -0000	[thread overview]
Message-ID: <529734C3.3080506@codesourcery.com> (raw)
In-Reply-To: <52966C69.3080506@linaro.org>

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 (齐尧)


  reply	other threads:[~2013-11-28 12:21 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-24  0:09 Omair Javaid
2013-10-24  2:25 ` Yao Qi
2013-11-08  3:20   ` Omair Javaid
2013-11-11 10:53     ` Yao Qi
2013-11-25  0:05       ` Omair Javaid
2013-11-25 14:23         ` Oza Pawandeep
2013-11-27 23:58           ` Omair Javaid
2013-11-28 12:30             ` Yao Qi [this message]
2013-12-17 10:22               ` Omair Javaid
2013-12-20 12:37         ` Pedro Alves

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=529734C3.3080506@codesourcery.com \
    --to=yao@codesourcery.com \
    --cc=gdb-patches@sourceware.org \
    --cc=omair.javaid@linaro.org \
    --cc=oza.pawandeep@gmail.com \
    --cc=patches@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox