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

[Daniel Jacobowitz <drow@mvista.com>]

On Wed, Oct 17, 2001 at 03:34:31PM -0400, Andrew Cagney wrote:
> >
> >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.

Well, I don't really consider this to be a ``fix''; it does not change
interfaces at all.  The only functions exported by low-linux-* are
used only directly by low-linux.c; they are num_regs (specifically,
number readable by ptrace), regmap, and cannot_{fetch,store}_register. 
In other words, it doesn't leave any old code around.

Note that there is an "old code left around" problem here - but it's
with the register cache code rather than the low-linux-* breakup.  I
can convert the other targets to that without much difficulty, I think;
just a little well-earned tedium.

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

Right.  Each of these low-* files is only compiled on the native
architecture for which it is written.  I'll scrap the lnx-* stuff.

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

Which part are you referring to?  The low-linux.c breakup?  I can do
that; I can also test it on 80% of the affected targets, and I'd
consider such a patch ``obvious''.

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

I don't really see the point.  It's no more (in fact probably less)
broken than all the other targets, which make the same or worse
assumptions.  I'm trying to fix them, not delete them :)  I'm open to
marking it obsolete, certainly.

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

For Solaris?  I'm not motivated in the slightest.  In fact, I'm tempted
to mark all non-Linux gdbserver targets as obsolete, and repair them
one at a time as volunteers, or at least testers, pop their heads up.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer