Port-vax archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Native builds?
On Wed, 29 Aug 2018, Johnny Billquist wrote:
> The problem is that gcc as such is not broken. It's the code generation for
> VAX that is, and you will not spot that with a cross compile.
> Only native builds will detect it.
Well, not only, fortunately, unless it's a very narrow corner case.
Many if not most people working on GCC development these days use the
tool as a cross-compiler mostly if not solely. Especially as embedded
bare-metal targets have no native configuration at all.
Being unable to spot issues but in a native configuration only would
therefore be a serious hindrance. Therefore we have the GCC test suite,
which can be quite straightforwardly run with a cross-compiler, as long as
you have your target system remotely accessible for running newly-built
executables. These days SSH has been the usual way for doing remote
access with the test suite. I've done it many times, so I can help anyone
wishing doing such compiler verification.
Beyond the usual bugs popping up from time to time we have another issue
with the upstream VAX port of GCC, which is that it is at risk of being
dropped unless someone converts it from the deprecated CC0 representation.
See <https://gcc.gnu.org/wiki/CC0Transition> for more details and the
conversion status across the supported architectures.
A less pressing issue is the conversion from reload to LRA. This does
not pose a risk for a port being dropped right now, but it would be good
doing anyway as the next step, as I imagine eventually reload will get
deprecated too.
I'll see what I can do about these issues, but I work on the Linux side
really and have no experience with NetBSD at all. So I need to think
first whether to focus on making the VAX/Linux port usable enough to be
able to run the GCC test suite as a remotely accessible target system, or
whether to switch to NetBSD.
One problem with using Linux is I have been stuck for many years with GCC
4.1.2, because this is the newest version of GCC that I have been able to
make work without NPTL as the Posix threads implementation, i.e. using
LinuxThreads instead. To upgrade I would have to switch to NPTL and I
could only do that if we had a TLS ABI defined for the VAX architecture.
My understanding has been that there has been intent to have TLS defined
for use by NetBSD too. Is that right? If so, then I think we could
cooperate. Except from an OS-specific way of obtaining the thread pointer
(I don't think we want to waste a GPR for that, we don't have that many of
them) all the rest would be strictly architecture-specific and therefore
the same across any OS wishing to run on VAX hardware.
Questions, comments, thoughts?
Maciej
Home |
Main Index |
Thread Index |
Old Index