This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH 1/2] GDB process record and reverse debugging improvements for arm*-linux*
- From: Omair Javaid <omair dot javaid at linaro dot org>
- To: Yao Qi <yao at codesourcery dot com>
- Cc: Oza Pawandeep <oza dot pawandeep at gmail dot com>, "gdb-patches at sourceware dot org" <gdb-patches at sourceware dot org>, Patch Tracking <patches at linaro dot org>
- Date: Tue, 17 Dec 2013 15:22:04 +0500
- Subject: Re: [PATCH 1/2] GDB process record and reverse debugging improvements for arm*-linux*
- Authentication-results: sourceware.org; auth=none
- References: <CANW4E-2g0ty_BP7EK2CHV1h9ZmDuKR_wBC5qsqWMNxHbZHAwSw at mail dot gmail dot com> <526884D5 dot 309 at codesourcery dot com> <527C5856 dot 50500 at linaro dot org> <5280ACE9 dot 9050308 at codesourcery dot com> <52929080 dot 1030304 at linaro dot org> <CAK1A=4zz7dr9mKSFYhny0VfimMAtQ7tQmskOSSmYbDPpRNkRxw at mail dot gmail dot com> <52966C69 dot 3080506 at linaro dot org> <529734C3 dot 3080506 at codesourcery dot com>
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.