Port-vax archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Native builds?

Well, I think I'm somewhat active, but I have never been close to gcc internals and I would prefer not to spend time with that.

It is probably more easy for me to compile the VAX port with pcc than to fix the bugs in gcc.

-- Ragge

Den 2018-08-29 kl. 15:27, skrev Paul Koning:
The VAX port has had some problems in its instruction generation at times.  I remember some discussion about one, including possible fixes I think -- something to do with INSV instructions?  I would assume the bug you ran into is simply one of those, a wrong code generation error that would show up in any run, native or cross.  There's nothing about native vs. cross that affects how code generation works.

Some internal compiler errors are tricky, but illegal instruction ones tend to be not all that hard.

Are there active VAX port maintainers?  While GCC is a large program with complex internals, the target part is fairly small and pretty well documented.  Taking up maintenance of a simple port like VAX is quite doable.

Given that I don't think this has to do with native vs. cross, I would say that one should care.  I have enough of a spare time sink being pdp11 target maintainer so I'm not going to volunteer for this one.  For those who understand VAX well, I'd suggest picking up the GCC Internals manual and reading chapters 17 and 18, that's the basics of what you need to know to tackle this.


On Aug 29, 2018, at 8:17 AM, Johnny Billquist <bqt%softjar.se@localhost> wrote:

Have anyone tried building natively lately?

I just tried on an 8650 with 8.0 Stable. The results were depressing.

===> build.sh command:    ./build.sh build
===> build.sh started:    Wed Aug 29 14:00:03 CEST 2018
===> NetBSD version:      8.0_STABLE
===> MACHINE:             vax
===> MACHINE_ARCH:        vax
===> Build platform:      NetBSD 8.0_STABLE vax
===> HOST_SH:             /bin/sh
===> No $TOOLDIR/bin/nbmake, needs building.
===> Bootstrapping nbmake
checking for sh... /bin/sh
checking for gcc... cc
checking for C compiler default output... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for executable suffix...
checking for object suffix... o
checking whether we are using the GNU C compiler... yes
checking whether cc accepts -g... yes
checking how to run the C preprocessor... cc -E
checking for regex.h... yes
checking for poll.h... yes
checking for regfree in -lregex... no
checking for library containing regfree... none required
checking for setenv... yes
checking for strdup... yes
checking for strerror... yes
checking for strftime... yes
checking for vsnprintf... yes
configure: creating ./config.status
config.status: creating buildmake.sh
cc  -D_PATH_DEFSYSPATH="/usr/src/share/mk" -DDEFSHELL_CUSTOM="/bin/sh" -DHAVE_SETENV=1 -DHAVE_STRDUP=1 -DHAVE_STRERROR=1 -DHAVE_STRFTIME=1 -DHAVE_VSNPRINTF=1  -O -c /usr/src/usr.bin/make/arch.c
/usr/src/usr.bin/make/arch.c: In function 'ArchStatMember':
/usr/src/usr.bin/make/arch.c:720:1: internal compiler error: Illegal instruction
no stack trace because unwind library not available
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://www.NetBSD.org/support/send-pr.html> for instructions.

ERROR: Build of nbmake failed

The system I'm running was cross compiler from an amd64 system.

Du we care? Anyone feel comfortable at looking at gcc internals? I generally don't.


Johnny Billquist                  || "I'm on a bus
                                  ||  on a psychedelic trip
email: bqt%softjar.se@localhost             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol

Home | Main Index | Thread Index | Old Index