In message <0e7f751fd4116f4773fc74b5379b73af@shagadelic.org>,
Jason Thorpe writes:

>On Feb 21, 2005, at 5:01 PM, Eric Christopher wrote:
>
>> Thinking about deprecating the mips-ecoff target out of binutils. Not
>> many people (incl. me) have been paying attention to it and I'd be
>> surprised if it worked much at all. I believe the only question is
>> whether or not you guys use it for anything. From talking to Matt you
>> seem to have your own stuff for the boot loader, but I wanted to make
>> sure it wasn't being used anywhere else.
>
>We have "our own thing" for the pmax boot loader.  But ARC systems 
>still require ECOFF, and we use regular objcopy for that.

Hi  Eric,

ECOFF is a tricky animal when it comes to booting. The Third
Eye/MipsCo/SGI mips-ECOFF tools met various assumptions at various
different points in their history.  Various PROMs and bootloaders
(written by different people at different companies) made different
assumptions about what where, at that time, "invariants" in the output
of the proprietary toolchain.  Ordering of sections and subsections,
alignment within the executable file, padding of sections to page
boundaries, ugly stuff like that.

What we have now on pmax works, but it'd be very difficult to recreate
the chain of dependencies of various bugs (or dependencies on those
"invariants" above). I know for a fact that previous binutils
maintainers didn't want to deal with those bootloader constraints; and
fair enough too.

I dont know if ARC-firmware bootloaders have similar constraints, but
I'd be pleasantly surprised if they don't.  If we had to, we could
roll our own ELF-to-arc-ecoff converter tool. But the historic desire
within NetBSD has been to kill off platform-specific converters in
favour of objcopy.

If NetBSD is truly the only remaining users of binutils mips-ecoff,
then I guess we should contemplate switching to our own
ELF-to-ECOFF-loader converters?  Are you saying that's where we should
be heading, or more that we should start thinking about it ASAP?