Re: [PATCH 0/4 v2] Refactor shared code in i386-{nat,low}.[ch]

[Pedro Alves <palves at redhat dot com>]

On 06/18/2014 06:48 PM, Mark Kettenis wrote:
>> Date: Wed, 18 Jun 2014 17:10:16 +0100
>> From: Pedro Alves <palves@redhat.com>
>>
>> On 06/18/2014 05:06 PM, Mark Kettenis wrote:
>>
>>> What is the whole point about this excercise?
>>
>> Reduce duplication and thus reduce maintenance burden.  The same code is
>> implemented twice, both in GDB and in GDBserver.
>> We've had to patch both sides of the fence several times in the
>> past years.  If we had already had this, it would have saved effort.
>> Can't rewrite history now, but we can avoid similar duplicate effort
>> in the future.  This specific bit is mentioned explicitly in:
>>
>>   https://sourceware.org/gdb/wiki/Common#Arch-specific_bits_of_the_target_backends
> 
> But common code lives in common/, and this diff moves things into
> nat/.  How does that unduplicate things?

Well, nat/ is a shared subdirectory, just like common/.  Both GDB and
GDBserver compile things from nat/, just like from common/.

Roughly:

 gdb/i386-nat.c + gdb/gdbserver/i386-low.c -> gdb/nat/i386-dregs.c

The little that remains in gdb/i386-nat.c and gdb/gdbserver/i386-low.c
is bits that glue GDB and GDBserver target_ops vectors to the
shared i386-dregs.c.

(The "common" moniker was a not-to-great idea that we're moving away from.
"common" suggests that what we put there is necessarily "common" between more
than one thing, instead of suggesting what the code is supposed to do.
If some change in GDB or GDBserver makes it so that some code in common/ is
no longer used in one of GDB or GDBserver's, then what to do?
Thus, "nat/" -- it holds native target specific code.  From GDBserver's
perspective, it's target backends are native targets.  This was all
previously discussed before, months ago, but we haven't updated the wiki
yet.  We should.)

-- 
Pedro Alves