Re: [PATCH RFC] Make GNU/Linux/PPC port work again

[Andrew Cagney <ac131313 at cygnus dot com>]

Stan Shebs wrote:

> Let me take this opportunity to warn people of what usually happens
> when we do this.  You need a piece of functionality in an OS/ABI
> file, because contrary to what the original author thought, it's useful
> for more than one OS or ABI.  Since you can't/don't want to link in the
> inappropriate file just to get the one function, cut-n-paste rides into
> town to, ahem, save the day, and voila, two copies of the same function
> to maintain.  The next generation of maintainers hack one and not the
> other, and we end up with two functions that are different, but it's
> not clear why.

There are arguments for and against this.

One clear advantage of isolating OS specific code in OS specific files
is that the maintainer of that file/system can be given a greater level
of autonomy.  Provided they tow the party line and don't cross into
other areas (break tight clean interfaces) then a small amount of
duplication may help rather than hinder.

If a target function doesn't meet its contract then it can be fixed in
isolation by the maintainer without the risk of breaking anything else. 
If a target function tries to share functionality then the poor tester
is lost not knowing which of N different cases they might break. 
Eventually, the next generation of maintainers, get to remove the code
with a simple snip snip - no need to untangle it from anything else.

I suspect that the basic ISA and ABI are generic and can be shared (in
*-tdep.c).  A few more esoteric things - such as knowing that N
instructions after the _fork() entry point there is a trap intruction -
would be better separated out.  A chunck of code that includes
<minix/minix.h> and then starts grubing around in kernel structures
definitly deserves to be burried in its own little file.  Long term I
think there will be:

	o	create generic ISA/ABI

	o	refine ISA/ABI adding OS
		specific features

		I think OO people call this
		inheritance.

BTW, an example of how to not do things?  Look at
mips-tdep.c:mips_push-arguments().  It should have been separate
functions (in same or different files I don't care).  At present that
code can, in theory, handle 2^8 different cases - I test 32 of them.

	enjoy,
		Andrew

PS: With regard to re-aranging files and creating directories, I think
its time will come as soon as 5.1 goes out.  By then, a few more targets
will have been multi-arched so we will have a far better handle on the
issues.  In particular, the problems associated with trying to build a
GDB containing two orthogonal architectures will be clearer.