Re: [try 2nd, patch] Move common macros to i386-dbg-reg.h

[Yao Qi <yao at codesourcery dot com>]

On 04/14/2011 01:05 AM, Joel Brobecker wrote:
>> "a fully featured native GDB replacement or a lightweight remote
>> protocol stub" is *not* related to this patch at all.  I am unable to do
>> such choice.  This patch (and other patches of mine in this area) is to
>> reduce source code duplication as much as possible.  No matter what
>> model we choose for gdbserver, this patch still makes sense, IMO.
> 
> It does, but before we do so, I think it's important to know how
> we are going to reduce this duplication. I haven't looked at the patch,

In general, the "how" is reading the source code, and identifying the
duplication between gdb and gdbserver.  Once duplication is found, try
to move them to common/ dir.  Removing duplication in *-nat.c and
*-low.c is a low-hang-fruit at that moment, and much duplications are
from this.

There are also some duplications in proc_service, and we can fix them
without much effort.

Of course, regcache and event-loop may have some duplications, but my
first impression is that it is not easy to reduce duplications there.
That is the same case to tracepoint.c as well.  I am not familiar with
them, so have no idea.

> so I can't comment on it, but I think we just need a plan of what and
> how we're going to avoid that.
> 

I guess your last "that" means "duplication".  I was keeping my eyes on
how to _reduce_ duplication, instead of how to avoid.  Think of it
shortly, something comes up in my mind,
1.  When adding a new port, common code, such as macros, register name,
and accessing method can be moved to common/, and gdb/gdbserver code use
it respectively.
2.  When adding a new functionality/feature, evaluate whether this new
feature can be done in both gdb and gdbserver.  If yes, move common part
to common/ dir, otherwise, implement this new feature in either gdb or
gdbserver.

These two rules apply to most of development works, and should be
helpful on avoiding duplications to some extent.

Finally, I don't think duplication can be avoided completely, so we need
change/refactor code periodically or continuously, even sometimes
changes are painful. :)

-- 
Yao (éå)