Re: [patch] Move common macros to i386-common.h

[Joel Brobecker <brobecker@adacore.com>]

> I'm particularly worried about changes I'll make myself.
[...]
> Sharing architecture-specific #define's is probably fine.  Sharing
> some simple basec support functions may also be ok.  But I don't think
> sharing more complicated code (such as the code manipulating the i386
> debug registers) is a good idea.

I think (hope!) that this would be a transitionary problem, and I am
willing to take on any breakage inadvertandly introduced - We do
gdbserver builds nightly and I update our sources every week or so.

But I think we should share the complicated code, simply because
it is getting increasingly complex, thanks to new features such as
non-stop, tracepoints, or older features such as threading support
which evolve as the kernel capabilities evolve. And while we're at it,
why would we want to continue writing the same code twice?

Right now, we have some bugs in GDB but not in GDBserver, some bugs in
GDBserver but not GDB, and some bugs in both.  Everytime we have a bug
in one of them, but not the other, we just look at how we deal with the
situation in the other, and back-port the idea. Or, when the bug is in
both, we have to fix the problem twice, except that the API is different,
and thus we do the work twice.

My view of the direction we should take is that we should have the
same API for doing all the target stuff: start inferior, next/step/cont,
read/write register/memory, get shared libraries, tracepoints,
watchpoints, etc. Once both use this API, then the remaining part
of GDBserver should be the common code that implements the stub-side
of the remote protocol, which should pretty much build out-of-the-box
on any OS. The consequence of that should be that, once you port GDB,
you pretty much get GDBserver for free.  And the other consequence is
if you decided to port GDBserver only as a first step, you wouldn't
have to do the work again when you decide to port GDB.

-- 
Joel