Re: rs6000.c / PPc-EABI / VxWorks / varargs / 2.95.2 vs. 2.7.2

[Mike Stump <mrs at windriver dot com>]

> To: gcc@gcc.gnu.org
> Date: Wed, 15 Nov 2000 11:15:20 -0500
> From: David Edelsohn <dje@watson.ibm.com>

> The "newppc" branch work was performed long after gcc-2.95.2 was
> released.  I would suggest that you complain to VxWork that they
> cooperate better with the rest of the GCC development community --
> both contributing their changes and utilizing improvements in the
> FSF releases.  You are demonstrating the exact problem with forking
> a private copy.

[ I am confused, I've seen what appears to be the same problem by two
  different people and two different organizations and helped one of
  them directly, so I may be confusing people here ]

Why do you think having a private tree caused this problem?  Why would
contributing changes have solved this problem?  And, would would
utilizing a newer source base have prevented this problem?  I think I
may not understand the problem if what you say is true.

He ran into problems I believe because gcc changed the abi it
conformed to.  Any change of ABI is a serious event, and can cause all
sorts of unfortunate problems, even if that change is motivated by a
bug fix that increases compliance with a relevant standard (eabi).  If
the FSF didn't change the abi, then the problem would not have
existed.  If the FSF offered a way to mitigate the abi change, that
could have avoided the problem as well.

While it might be easy for you to invalidate a product in the field
and rev the abi, some people, and some customers of some people have a
slightly harder time of it than just telling them to `utilize
improvements in the FSF releases'.

Some of the code produced by the compiler is burned into ROMs in
devices that aren't going to be updated to contain new ROMs, no matter
what you say, but thanks for sharing.

I suspect on the horizon I will have to sort this problem out, as we
update our source base.  Now, if the powerpc maintainers know of abi
changes (in varargs mostly), this would help us greatly, as then we
can conditionalize them and be bug compatible with the old gcc.  If
you wish to try and convince all of our customers that instead they
should be forced to update all their products, you're welcome, but
this would be the wrong list to reach them.

Now, on a positive note, we have already have a much newer compiler
for the powerpc with the bug fix (to conform to the eabi) and that
will be shipping with our new product.  In our new product, we have
the luxury of changing the abi.  We still face a problem with deployed
code that cannot be `just recompiled with a newer compiler' and older
releases.

Disclaimer: I've not `seen' the problem the person describes, to know
exactly what problem they are having.  I'm taking it on faith there is
a problem, and that it is a due to a change of abi.


> From: David Korn <dkorn@pixelpower.com>
> To: "'David Edelsohn'" <dje@watson.ibm.com>, gcc@gcc.gnu.org
> Date: Wed, 15 Nov 2000 16:47:57 -0000

> rather than (as I have been assuming until now) that WRS stood still
> at 2.7.2 while gcc moved on to 2.95.2.

The abi of a product is set when the product is released (or when a
predecessor product that defines the abi is released).  In this case,
that abi was set by the Tornado 1.0.1 release, and this release
happened well before 2.95.2.  So, yes, we stand the abi still at 2.7.2
(as you put it) for the Tornado 1.x, 2.x line.  See above for a much
condensed version of why.

> FWIW, I fully agree with you that WRS should take their
> responsibilities to the FSF and GCC community seriously.

I find this fairly insulting.  Could you send insults to me privately
instead?  Thanks.  The FSF tree is made up of contributed code
submitted by people that aren't paid by the FSF, and generally
speaking, it is considered bad form to insult contributors, well,
unless they break the build, or cause regressions in the testsuite!

> OTOH, Mike Stump has been prominent on the lists recently, so I
> kind-of-assumed that WRS had gotten it's attitude sorted out. Is he
> acting independently as a maintainer, rather than being a serious
> liaison between GCC and WRS?

I contribute what I can, as I can, when I can.  That is what all the
FSF contributors do.  If you wish to contribute, I'd be happy to
supply you with all of our changes and have you help me sort them out
and get them contributed.  If you don't want to, I'll understand.

Assume I am a nice person what would love to see everything just work,
and someone that doesn't mind helping out as I am able to, then modify
as you see fit.

>   Anyway thanks for taking the time to inform me. And rest assured
> that any worthwhile hacks *I* can come up with *will* be submitted
> as patches.

Thanks a million, looking forward to whatever help you can offer.