Re: More code removal, mips ecoff support

Re: More code removal, mips ecoff support

[Bert De Knuydt]

I'd really regret removing ecoff.  It would mean the end of Ultrix/MIPS
support, as far as I understand ... 

Greetings,

Bert.

-- 
-------------- eMail Bert.Deknuydt@esat.kuleuven.ac.be ---------------
B.DeKnuydt, PSI-KULeuven                            Tel. +32-16-321880
Kasteelpark Arenberg 10          /|    | ||
B-3001 Leuven-Heverlee        _,_)|  4_|_||
FLANDERS, BELGIUM            / .                    Fax. +32-16-321838
-------------- http://www.esat.kuleuven.ac.be/~deknuydt --------------

Re: More code removal, mips ecoff support

[Joe Buck]

> I'd really regret removing ecoff.  It would mean the end of Ultrix/MIPS
> support, as far as I understand ... 

We should not proceed with removing ecoff until we know the impact, and
if a significant class of users are affected, then I think that the SC
will have to approve or disapprove the removal.

But is anyone aware of someone who is still running Ultrix/MIPS?

Re: More code removal, mips ecoff support

[Eric Christopher]

In article <200112071740.JAA11188@atrus.synopsys.com>, "Joe Buck"
<jbuck@synopsys.com> wrote:

>> I'd really regret removing ecoff.  It would mean the end of Ultrix/MIPS
>> support, as far as I understand ...
> 
> We should not proceed with removing ecoff until we know the impact, and
> if a significant class of users are affected, then I think that the SC
> will have to approve or disapprove the removal.
> 

That's fine with me. I just thought I'd start the ball rolling...

> But is anyone aware of someone who is still running Ultrix/MIPS?

I tried a year or two back. My machine wasn't beefy enough to bootstrap
gcc. I doubt it would have worked anyhow.

-eric

-- 
Fridays are not "pants optional"

Re: More code removal, mips ecoff support

[Eric Christopher]

In article <15376.46097.482650.386352@bespin.esat.kuleuven.ac.be>, "Bert
De Knuydt" <Bert.Deknuydt@esat.kuleuven.ac.be> wrote:

> I'd really regret removing ecoff.  It would mean the end of Ultrix/MIPS
> support, as far as I understand ...

Is anyone still using it? I mean, bootstrapping up new gcc's every
release? My ultrix box can't even handle a bootstrap.

-eric

-- 
Fridays are not "pants optional"

Re: More code removal, mips ecoff support

[Guido Guenther]

On Fri, Dec 07, 2001 at 01:12:33PM -0500, Daniel Jacobowitz wrote:
> On Fri, Dec 07, 2001 at 05:28:24PM +0100, Michal Moskal wrote:
> > Isn't linux booting from ecoff image on mips (at least when loading
> > kernel from network)? Will it be still possible?
> 
> Sure.  Link to ELF, then use objcopy.  That's the way it is currently
> done in most cases, I believe.
Linux/Mips does not even do this. It uses arch/mips/boot/elf2ecoff.
 -- Guido

Re: More code removal, mips ecoff support

[Daniel Jacobowitz]

On Fri, Dec 07, 2001 at 05:28:24PM +0100, Michal Moskal wrote:
> Isn't linux booting from ecoff image on mips (at least when loading
> kernel from network)? Will it be still possible?

Sure.  Link to ELF, then use objcopy.  That's the way it is currently
done in most cases, I believe.

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

Re: More code removal, mips ecoff support

[Michal Moskal]

On Thu, Dec 06, 2001 at 03:59:36PM -0800, mike stump wrote:
> > From: Eric Christopher <echristo@redhat.com>
> > To: gcc@gcc.gnu.org
> > Date: 06 Dec 2001 15:14:32 -0800
> 
> > I'm looking at current OSs that support ecoff on mips or any objections
> > to removing the ecoff support from the backend. Anyone?
> 
> It might be interesting to to contemplate annoucing the desupporting
> of all non-elf system, and removing all non-elf code.  Before that
> could be done, we'd need to run a user survey for months and months to
> collect user opinion.  This would help consolidate everyone towards
> elf, if they had been dragging their feet.
> 
> The theory would be, generate elf everywhere, and if the end user OMF
> is different in the end, have them objcopy (extending objcopy as
> necessary) from elf to the format they want.
> 
> A limitation would be, things like link once sections and a.out.  You
> would have to objcopy fully resolved non-relocatable files to be a.out
> files, one, in general could not just copy a single .o elf file, to a
> single .o a.out file.  Also, binutils doesn't always copy relocs
> correctly, thus, it would either have to be fixed, or again, one would
> have to copy fully linked files.

Isn't linux booting from ecoff image on mips (at least when loading
kernel from network)? Will it be still possible?

-- 
: Michal ``,/\/\,       '' Moskal    | |            : GCS {C,UL}++++$
:          |    |alekith      @    |)|(| . org . pl : {E--, W, w-,M}-
:    Linux: We are dot in .ORG.    |                : {b,e>+}++ !tv h
: CurProj: ftp://ftp.pld.org.pl/people/malekith/ksi : PLD Team member

Re: More code removal, mips ecoff support

[Richard Kenner]

    Woo, end of another era.  Well, you don't see many Irix 4 or Mipsco
    systems around anymore, and the only embedded users will be doing
    r3000s of some flavor, so not much chance for user objections.

Perhaps not much chance of user objects from people *on this list*, but
I think removing support when there are still systems around is a bad idea.
Keeping support for them is not that much work.

Isn't ecoff also used on Alpha?  I have a distinct recollection that it's
the default on the Alpha I use.

Re: More code removal, mips ecoff support

[Stan Shebs]

Eric Christopher wrote:
> 
> I'm looking at current OSs that support ecoff on mips or any objections
> to removing the ecoff support from the backend. Anyone?

Woo, end of another era.  Well, you don't see many Irix 4 or Mipsco
systems around anymore, and the only embedded users will be doing
r3000s of some flavor, so not much chance for user objections.

One of the heuristics I use for GDB obsolescence is to poke
around with Google.  For instance, AMD used to have a page or two
mentioning the a29k, but now they strenuously deny they were ever
involved with it. :-)  If the only references to ecoff are in
online GNU docs, then that's a hint that we're the last people
to support it...

> I also didn't see any comments (other than Richard's) about removing
> half-pic support from the compiler. Does no one care?

I can't even remember the last time I heard of anyone interested
in that stuff.

Stan

Re: More code removal, mips ecoff support

[DJ Delorie]

> I'm looking at current OSs that support ecoff on mips or any objections
> to removing the ecoff support from the backend. Anyone?

Windows CE on mips is coff/PE (not ecoff) so please be careful.

Re: More code removal, mips ecoff support

[mike stump]

> From: Eric Christopher <echristo@redhat.com>
> To: gcc@gcc.gnu.org
> Date: 06 Dec 2001 15:14:32 -0800

> I'm looking at current OSs that support ecoff on mips or any objections
> to removing the ecoff support from the backend. Anyone?

It might be interesting to to contemplate annoucing the desupporting
of all non-elf system, and removing all non-elf code.  Before that
could be done, we'd need to run a user survey for months and months to
collect user opinion.  This would help consolidate everyone towards
elf, if they had been dragging their feet.

The theory would be, generate elf everywhere, and if the end user OMF
is different in the end, have them objcopy (extending objcopy as
necessary) from elf to the format they want.

A limitation would be, things like link once sections and a.out.  You
would have to objcopy fully resolved non-relocatable files to be a.out
files, one, in general could not just copy a single .o elf file, to a
single .o a.out file.  Also, binutils doesn't always copy relocs
correctly, thus, it would either have to be fixed, or again, one would
have to copy fully linked files.

Re: More code removal, mips ecoff support

[Joseph S. Myers]

On 6 Dec 2001, Eric Christopher wrote:

> I'm looking at current OSs that support ecoff on mips or any objections
> to removing the ecoff support from the backend. Anyone?

Just generic comments on such removal:

* Be sure to remove/update all documentation that is made obsolete by such
removal - for example, there are references to ECOFF in install.texi.

* If this means certain targets are no longer supported, actually remove
support for them (headers, config.gcc fragments, ...) so that they fail at
configure time.

* Enumerate the costs and benefits.  What targets are affected, how long
have they been obsolete, how much does this simplify the compiler and make
it easier to maintain?

* Ideally the release notes for each release would list the targets for
which support has been removed, even if we're sure they're long obsolete,
in caveats.html, though we haven't really been tracking this information
properly to do this.

-- 
Joseph S. Myers
jsm28@cam.ac.uk

More code removal, mips ecoff support

[Eric Christopher]

I'm looking at current OSs that support ecoff on mips or any objections
to removing the ecoff support from the backend. Anyone?

I also didn't see any comments (other than Richard's) about removing
half-pic support from the compiler. Does no one care?

-eric

-- 
Fridays are not "pants optional"