gdbserver/{,,}.c?; Was: [rfa] gdbserver overhaul

Andrew Cagney
2001-10-17T12:34:00Z

>
> 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