gdbserver/{<foo>,<os>,<bar>}.c?; Was: [rfa] gdbserver overhaul

[Andrew Cagney <ac131313 at cygnus dot com>]

> 
> As far as that goes, I can't reliably break the others apart.  It's
> very tricky to do without a platform to compile them on.  That changes
> interfaces only within low-linux itself, though, so I'm not terribly
> concerned.  And, as I've mentioned, most of those other targets are
> really just myths nowadays.

There is a trade off here.

On the right we have ``fix'' linux and ignore everything else; while on 
the left we have ``fix'' and have ``working'' all targets.

I am reluctant to approve the option on the right since this that would 
result in a gdbserver with N different ways of implementing the same 
thing.  Since gdbserver is a small program there shouldn't be a need for 
this.  The GDB sources hopefully illustrate how leaving old code around 
can so easily comes back and bite you.

As for the option on the left, real world experience suggests this just 
isn't practical.

That leaves the usual pragmatic compromise: ``fix'' all targets knowing 
that some of the fixes probably didn't ``work''.  People motivated in 
advancing gdbserver for their target (and hence GDB) will soon step 
forward and help with the task of testing patches.

> I used lnx-, because they needed to be 8.3 unique - isn't that
> preferred to an entry in fnmatch.* (?)?  They were originally
> low-linux-*.c instead, which was much more logical to me.  I'll go back
> to that if the 8.3 conflicts are not a concern.

I think the ``keep it consistent and call it linux'' concern overrides 
the 8.3 concern.

A s/linux/lnx/ change is separate and independant.  Per the above, it 
should be done all at once.

Hmm, just one thing on the naming schema.  gdbserver can't be made to 
work on dos or if it did it couldn't use any of these low-* files right?

--

Can I suggest posting a patch that does just this part of the 
re-structuring.  People so motivated can then apply/test it. For targets 
that don't get tested will bit rot :-/

Can I also suggest posting a separate patch that deletes the sim target. 
  That has what I would consider a technical flaw.  The libsim.a 
interface doesn't specify the layout and consequently there is an 
incorrect assumptioin that GDB / gdbserver / libsim.a have a common 
layout.  Once your re-structure has gone through I think it will be 
possible to fix this.

With respect to sparc, if it really doesn't even build, then well, how 
motivated are you? :-)  You could fix it, obsolete it or transform it 
(still broken).

enjoy,
Andrew