Re: QNX bfd backend and ELFOSABI_QNX

["Graeme Peterson" <gp at qnx dot com>]

JT, you are being hasty and jumping to conclusions.

Please let everyone understand:  I am removing the qnx bfd's and
using the base ones instead.  I said nothing about removing QNX
support from binutils.

QNX arm-nto, ppc-nto, sh-nto, and i386-nto target support are _NOT_ 
being removed.  They are being cleaned up.

>From my pending ChangeLog entry:

	* config.bfd: Changed qnx targets to use base bfd's instead
	of the removed qnx extended base bfd's.
	* configure.in: Removed support for bfd_elf32_{l}qnx_vec,
	bfd_elf32_powerpc{le}qnx_vec, bfd_elf32_{big|little}armqnx_vec,
	and bfd_elf32_i386qnx_vec.

What does this mean?  It means that instead of getting, for example,
bfd_elf32_i386qnx_vec with the qnx specific extensions, you will
instead get bfd_elf32_i386_vec without the extensions.  This is
the same way that it has always been.  QNX has never released a
toolchain with the extended bfd's (GNU has, binutils-2.13 I think).

And yes, HJ was right on the money.  The extensions did create a new
ABI, which QNX does not want, which is why we are removing the 
extensions and leaving the core support.

Clear?  I hope so...

Regards,
GP

> 
> "Graeme Peterson" <gp@qnx.com> writes:
> > Regarding the QNX bfd backend and ELFOSABI_QNX:
> > 
> > I have taken this up with my bosses/superiors here at QNX,
> > and I have been asked to take out the qnx specific backend
> > code that Alan Modra, Nick Clifton, HJ and others have helped
> > so much with.
> 
> However, as a QNX user, not having any QNX support in the current
> binutils is crippling.  It will be even more so once my QNX gcc port
> makes it into a formal release, since users won't be able to move to
> non-QNX hosts for QNX target development.
> 
> Surely something can be done.  In the worst case, perhaps we can go
> with a QNX config that is an alias for the SysV ABI.  It won't work
> for the QNX kernel, but it appears to work well enough for normal user
> binaries.  In fact, I submitted such a patch to binutils about the
> same time Graeme did, and we're still using tools built with it for
> our production builds.
> 
> > For a variety of reasons, we think this is the right thing
> > to do for now.  When we have the time we will re-examine this
> > issue and come up with another solution.
> 
> I hope this is sooner rather than later.  As you're aware, we've had
> nothing but frustration with QNX-native tools over the last few years.
> This is why I was given the time to provide an alternate toolchain.  I
> was hoping that QSSL assigning you to integrate your local changes
> into the master sources signified a turn in a more positive direction.
> I will now have to tell my bosses/superiors that this was not the case.
> 
> > At this time, we do not want a QNX specific ELFOSABI, and will
> > not be registering one with caldera.
> 
> The fact is that the QNX extensions do create an new ABI, and as such
> they should be branded as such.  I think H.J. was right on the money
> when he advocated so strongly.
> 
> > I will put together a patch ASAP and submit it for your
> > consideration.
> 
> IMO, what is done should not be undone so quickly.
> 
>         --jtc
> 
> -- 
> J.T. Conklin
>