Re: Lets talk to each other...

[Kevin Buettner <kevinb at cygnus dot com>]

On Sep 27,  3:13pm, J. Kean Johnston wrote:

> Recently, several changes were committed to the tree which has
> broken existing target support. All of the changes to the
> i386-tdep.c file for floating point stuff for Linux has broken
> all other i386 targets.  Changing existing, working code that
> more than one target depends on should be done a bit more
> cautiosly (IMHO). Linux is not the only OS that runs on a
> 386, and this code just broke compiles for both UnixWare
> and OpenServer, two targets that previously worked. If changes
> are going to affect more than one target, either the person
> making the change should be prepared to go and change the
> target dependant stuff or at least make folks aware of the
> incompatibile changes.
> 
> If this was done and I missed the messages, please ignore
> this message :-) If not, please, lets talk to each other
> before we stand on each other's toes.

I must admit that I'm a bit confused.

I did check in some changes that did indeed cause breakage on some of
the other i386 targets.  But about a week later, I backed out the most
problematic of these changes and ifdef'd some of the smaller changes
so that we *should* be able to build on other i386 targets again.

Hence my confusion... are you using the current snapshot?  Or
one from two to three weeks back?

.....

I think it's time to try to clear the air on another (related)
matter as well...

H.J. has shown us that it is possible to ifdef the changes that I
reverted so that we can build gdb on other (non-linux) targets.

So why didn't we do this?

I don't have a great answer for this.  Personally, I would've prefered
to have some admittedly linux-specific code in i386-tdep.c that would
add some missing functionality with the understanding that it would be
cleaned up later on.  (In other words, HJ's ifdefs would've been fine
with me.)

However, I do understand the other point of view too.  The argument
goes like this:  One of our goals is to unify the floating point
support among the various i386 targets.  There was a thread on
gdb-patches earlier this year in which two competing approaches were
discussed.  The first approach would be to define a common set of
symbols and have each i386 target map these symbols as appropriate.
The second approach is to define a register layout which would be
common to all of the i386 targets.

As I see it, the first approach, that of defining a common set of
symbols, would work very nicely with the changes that I reverted. 
(Though there still are some problems with it though).  However, it
was decided that it would be much cleaner to use the second approach
of defining a common register layout.  Yes, it probably is more work,
but it is the "right" way to do things.

So, rather than clutter up i386-tdep.c with some code which would
either be ripped out or substantially rewritten, the choice was made
to temporarily forgo the additional functionality in favor of doing it
right.

In my opinion, this is an acceptable decision so long as we do the
necessary unification and add the missing functionality before the
next release.  The snapshots available from sourceware.cygnus.com are
just that, snapshots, not releases.  As such they may contain missing
features, not build on all targets, etc.  (OTOH, it would be nice if
they were as close to release quality as possible in order to
encourage people to use them and provide us with feedback.)

Those of us (me included) who are new to the i386 FP support
unification discussion can read more about it starting at

    http://sourceware.cygnus.com/ml/gdb-patches/1999-q3/msg00021.html

and also at

    http://sourceware.cygnus.com/ml/gdb-patches/1999-q3/msg00002.html

for the precursors to the later discussion.

If you go to the index at

    http://sourceware.cygnus.com/ml/gdb-patches/1999-q3/

the relevant subjects are:

    Re: [eliz@is.elta.co.il: GDB: fine print in 387 info]
and
    Unifying i387 support

Kevin

-- 
Kevin Buettner
kev@primenet.com, kevinb@cygnus.com