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: Yao Qi <yao at codesourcery dot com>
- To: Omair Javaid <omair dot javaid at linaro dot org>
- 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: Thu, 28 Nov 2013 20:19:15 +0800
- 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>
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 (éå)