This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: QNX bfd backend and ELFOSABI_QNX
- From: "Graeme Peterson" <gp at qnx dot com>
- To: jtc at acorntoolworks dot com
- Cc: binutils at sources dot redhat dot com
- Date: Mon, 28 Oct 2002 17:09:40 -0500 (EST)
- Subject: Re: QNX bfd backend and ELFOSABI_QNX
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
>