QNX bfd backend and ELFOSABI_QNX

[J.T. Conklin]

"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