Re: [PATCH RFA] Zap EXTRA_FRAME_INFO for ARM target

[Kevin Buettner <kevinb@redhat.com>]

On Jan 20,  6:15pm, Andrew Cagney wrote:

> > The patch below represents a small step on the way to multiarching the
> > ARM target.  It eliminates the use of the deprecated EXTRA_FRAME_INFO
> > macro for describing a frame.  Instead, it now uses the ``extra_info''
> > and ``saved_regs'' members in the frame_info struct.
> 
> Jason Thorpe (I assume unintentionally) set a precident by treating as 
> obvious the patch transforming EXTRA_FRAME_INFO as part of multi-arching 
> the alpha.
> 
> Thinking about it Jason was correct in taking this aproach (I suspect 
> I've done this with other targets).  A patch making the single 
> independant change of eliminating EXTRA_FRAME_INFO is mechanical, and as 
> such, can be treated as obvious.

I think it depends upon the target.  For ARM, nearly all of the
changes were mechanical, but the ARM target has some pecularities
which required some care.  I think it would have been better for a
responsive maintainer to have looked over these changes and approved
them.

I do agree, however, that Jason was correct in his approach for the
alpha since the alpha target doesn't have any listed maintainers.

> Clearly it is assumed that the person 
> committing the change is performing before/after testing to ensure no 
> regressions occure.  A person looking to commit such a change is also, 
> obviously, strongly advised, to not try and make the change somehow 
> dependant on other changes, doing that will just bog down the process.

Ah.  Perhaps you're referring to the fact that my patch had some
dependencies on other patches (which are now approved).  I had
considered removing these dependencies before submitting my patch,
but that would've meant more work for me when it wasn't at all clear
that there would be any benefit.

> If GDB doesn't take this approach it is very quickly going to find that 
> the multi-arch task gets bogged down waiting on approval of trivial changes.

I don't entirely agree with this.  If the target in question has no
maintainers, then I am in complete agreement.  If the target in
question has active maintainers, then I think the maintainers should
have a chance to comment on the proposed changes before they go in.
If Fernando and Scott no longer have the time or motivation to be
active maintainers, then they should step aside so that development
of the ARM target can proceed more rapidly.

Kevin