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?


Home | Main Index | Thread Index | Old Index