mac68k and gcc 4

I sent this to port-mac68k a few months ago but didn't get
any
response... the first problem (invalid lvalue in assignment)
has been
fixed, the second (unknown register name 'fp' in 'asm')
hasn't, and I
haven't checked the third ('pg_' may be used
uninitialized in this
function). Anyone have any thoughts or suggestions?

BTW, is anyone still working on mac68k? 4.0 has been
branched, and
there are a few PRs with patches that IMO need to be in 4.0:
http://www.netbsd.org/cgi-bin/query-pr-single.pl?nu
mber=32583
http://www.netbsd.org/cgi-bin/query-pr-single.pl?nu
mber=33636


----- Forwarded message from Dave Huang <khymazeotrope.org> -----
Date: Sat, 3 Jun 2006 20:33:41 -0500
From: Dave Huang <khymazeotrope.org>
To: port-mac68knetbsd.org
Subject: mac68k and gcc 4

I tried building a -current mac68k kernel with the
newly-imported gcc
4, and ran into a few errors, most of which I'm not too
sure about
how to solve.

First is:
/usr/src.local/sys/arch/mac68k/mac68k/macrom.c: In function
'mrg_DTInstall':
/usr/src.local/sys/arch/mac68k/mac68k/macrom.c:180: error:
invalid lvalue in assignment

        caddr_t ptr, prev;

        __asm volatile ("movl %%a0,%0" :
"=g" (ptr));

        (caddr_t *)prev = &mrg_DTList;
 
I think changing the last line to:
	prev = (caddr_t)&mrg_DTList;
will do the same thing.

After changing that, I run into another problem in macrom.c:
/usr/src.local/sys/arch/mac68k/mac68k/macrom.c: In function
'mrg_aline_super':
/usr/src.local/sys/arch/mac68k/mac68k/macrom.c:728: error:
unknown register name 'fp' in 'asm'

/* 	put a0 in a0 */
/* 	put a1 in a1 */
/* 	put d0 in d0 */
/* 	put d1 in d1 */
/*	put trapaddr in a2 */
/* save a6 */
/* 	call the damn routine */
/* restore a6 */
/* 	store d0 in d0bucket */
/* 	store a0 in d0bucket */
/* This will change a2,a1,d1,d0,a0 and possibly a6 */

	__asm volatile (
	"	movl	%2,%%d0	\n"
	"	movl	%2(4),%%d1	\n"
	"	movl	%2(32),%%a0	\n"
	"	movl	%2(36),%%a1	\n"
	"	movl	%3,%%a2		\n"
	"	jbsr	%%a2		\n"
	"	movl	%%a0,%0		\n"
	"	movl	%%d0,%1"

		: "=g" (a0bucket), "=g" (d0bucket)

		: "a" (&frame->f_regs), "g"
(trapaddr)

		:
"d0","d1","a0","a1
","a2",
#ifdef __ELF__
			  "fp"
#else
			  "a6"
#endif

I don't know why the clobber register spec is
"fp" for ELF and "a6"
otherwise... isn't "fp" just an alias for
"a6"? I tried changing it to
use "a6" unconditionally, but that doesn't work
either:

/usr/src.local/sys/arch/mac68k/mac68k/macrom.c: In function
'mrg_aline_super':
/usr/src.local/sys/arch/mac68k/mac68k/macrom.c:763: error:
%a6 cannot be used in asm here

The comments say "save a6" and "restore
a6", but I don't see where
that happens. They also say that it'll possibly change A6,
but I don't
see when that would happen either. Are there some ROM
toolbox calls
that will modify A6? That seems like it'd be a bad thing
for a
subroutine to not restore the frame pointer...

Anyways, I don't know if it's the right thing to do, but I
just
removed fp/a6 from the list of clobbered registers.

That gets us past macrom.c and on to this:
cc1: warnings being treated as errors
/usr/src.local/sys/arch/m68k/m68k/pmap_motorola.c: In
function 'pmap_changebit':
/usr/src.local/sys/arch/m68k/m68k/pmap_motorola.c:2518:
warning: 'pg_' may be used uninitialized in this function
/usr/src.local/sys/arch/m68k/m68k/pmap_motorola.c:2525:
warning: 'pg_' may be used uninitialized in this function

It's complaining about these two macros:

#define	pa_to_pvh(pa)							\
({									\
	int bank_, pg_;							\
									\
	bank_ = vm_physseg_find(atop((pa)), &pg_);			\
	&vm_physmem[bank_].pmseg.pvent[pg_];				\
})

#define	pa_to_attribute(pa)						\
({									\
	int bank_, pg_;							\
									\
	bank_ = vm_physseg_find(atop((pa)), &pg_);			\
	&vm_physmem[bank_].pmseg.attrs[pg_];				\
})

And I suppose that gcc is right that vm_physseg_find may not
set
pg_... it looks like vm_physseg_find returns -1 if it
didn't find what
it was looking for, but I don't know how to check for that
due to the
way those macros are written. Initializing pg_=0 gets rid of
the
warning, but it seems like that's just sweeping the problem
under the
rug 
----- End forwarded message -----

-- 
Name: Dave Huang         |  Mammal, mammal / their names are
called /
INet: khymazeotrope.org |  they raise a paw / the bat, the cat
/
FurryMUCK: Dahan         |  dolphin and dog / koala bear and
hog -- TMBG
Dahan: Hani G Y+C 30 Y++ L+++ W- C++ T++ A+ E+ S++ V++ F-
Q+++ P+ B+ PA+ PL++

Another thing that would be nice to see in the next version
of netbsd-m68k 
is the preliminary support for DMA on av macs that someone
posted they wrote 
and submitted. 

And unnder heavy hard drive activity netbsd crashes
sometimes. For instance 
mine crashed at least twice while trying to do 

cd /usr/pkgsrc/editors/xemacs-packages
make install 

, which handles lots of small text files.

Just a few uninformed comments...

At 3:22 Uhr -0500 3.9.2006, Dave Huang wrote:
>I tried building a -current mac68k kernel with the
newly-imported gcc
>4, and ran into a few errors, most of which I'm not too
sure about
>how to solve.

[...]

>I run into another problem in macrom.c:
>/usr/src.local/sys/arch/mac68k/mac68k/macrom.c: In
function 'mrg_aline_super':
>/usr/src.local/sys/arch/mac68k/mac68k/macrom.c:728:
error: unknown
>register name 'fp' in 'asm'
>
>/* 	put a0 in a0 */
>/* 	put a1 in a1 */
>/* 	put d0 in d0 */
>/* 	put d1 in d1 */
>/*	put trapaddr in a2 */
>/* save a6 */
>/* 	call the damn routine */
>/* restore a6 */
>/* 	store d0 in d0bucket */
>/* 	store a0 in d0bucket */
>/* This will change a2,a1,d1,d0,a0 and possibly a6 */
>
>	__asm volatile (
>	"	movl	%2,%%d0	\n"
>	"	movl	%2(4),%%d1	\n"
>	"	movl	%2(32),%%a0	\n"
>	"	movl	%2(36),%%a1	\n"
>	"	movl	%3,%%a2		\n"
>	"	jbsr	%%a2		\n"
>	"	movl	%%a0,%0		\n"
>	"	movl	%%d0,%1"
>
>		: "=g" (a0bucket), "=g"
(d0bucket)
>
>		: "a" (&frame->f_regs),
"g" (trapaddr)
>
>		:
"d0","d1","a0","a1
","a2",
>#ifdef __ELF__
>			  "fp"
>#else
>			  "a6"
>#endif
>
>I don't know why the clobber register spec is
"fp" for ELF and "a6"
>otherwise...

The pre-ELF as(1) was considerably older (and had changes
not fed back to
GNU as) than the ELF as(1) from binutils that replaced it.
What does the
netbsd-4 info page for as(1) say?

>isn't "fp" just an alias for
"a6"? I tried changing it to
>use "a6" unconditionally, but that doesn't
work either:
>
>/usr/src.local/sys/arch/mac68k/mac68k/macrom.c: In
function 'mrg_aline_super':
>/usr/src.local/sys/arch/mac68k/mac68k/macrom.c:763:
error: %a6 cannot be
>used in asm here
>
>The comments say "save a6" and
"restore a6", but I don't see where
>that happens.

Nor do I. Ask Allen Briggs, since according to 'cvs
annotate' he added the
comments.  ;)

> They also say that it'll possibly change A6, but I
don't
>see when that would happen either.

Ask Scott Reynolds, since... see above. Although Allen may
be easier to reach.

> Are there some ROM toolbox calls
>that will modify A6? That seems like it'd be a bad
thing for a
>subroutine to not restore the frame pointer...
>
>Anyways, I don't know if it's the right thing to do,
but I just
>removed fp/a6 from the list of clobbered registers.
>
>That gets us past macrom.c and on to this:

[...]

Did you get a working kernel in the end? I have an idle
Quadra 650 around
that I could drop a snapshot of netbsd-4 onto...

	hauke

--
"It's never straight up and down"     (DEVO)

[ Dropping current-users since I was mainly trying to get
wider exposure
 for the problems I mentioned; subsequent discussion can
probably just
 go on port-mac68k ]

On Mon, Sep 04, 2006 at 02:02:15AM +0200, Hauke Fath wrote:
> Did you get a working kernel in the end? I have an idle
Quadra 650 around
> that I could drop a snapshot of netbsd-4 onto...

Yes, I had forgotten to mention it in that original email,
but sent a
followup <http://mail-index.netbsd.org/port-mac68k/2006/0
6/03/0001.html>
where I said it works fine on my Centris 660av.

I don't currently have a netbsd-4 snapshot, but I could
build a set of
GENERIC netbsd-4/gcc 4 kernels for people to try out...
-- 
Name: Dave Huang         |  Mammal, mammal / their names are
called /
INet: khymazeotrope.org |  they raise a paw / the bat, the cat
/
FurryMUCK: Dahan         |  dolphin and dog / koala bear and
hog -- TMBG
Dahan: Hani G Y+C 30 Y++ L+++ W- C++ T++ A+ E+ S++ V++ F-
Q+++ P+ B+ PA+ PL++

At 22:01 Uhr -0500 3.9.2006, khymazeotrope.org wrote:
>[ Dropping current-users since I was mainly trying to
get wider exposure
> for the problems I mentioned; subsequent discussion can
probably just
> go on port-mac68k ]
>
>On Mon, Sep 04, 2006 at 02:02:15AM +0200, Hauke Fath
wrote:
>> Did you get a working kernel in the end? I have an
idle Quadra 650 around
>> that I could drop a snapshot of netbsd-4 onto...
>
>Yes, I had forgotten to mention it in that original
email, but sent a
>followup <http://mail-index.netbsd.org/port-mac68k/2006/0
6/03/0001.html>
>where I said it works fine on my Centris 660av.
>
>I don't currently have a netbsd-4 snapshot, but I could
build a set of
>GENERIC netbsd-4/gcc 4 kernels for people to try out...

I kicked off a cross-build on my i386 workplace machine
today, and

[hfGstoder] ~ > ls -l
/void/netbsd-builds/4/mac68k/releasedir/mac68k/binary/sets/
total 115380
-rw-r--r--  1 hf  wheel       303 Sep  4 20:16 BSDSUM
-rw-r--r--  1 hf  wheel       415 Sep  4 20:16 CKSUM
-rw-r--r--  1 hf  wheel       724 Sep  4 20:16 MD5
-rw-r--r--  1 hf  wheel      2110 Sep  4 20:16 SHA512
-rw-r--r--  1 hf  wheel       305 Sep  4 20:16 SYSVSUM
-rw-r--r--  1 hf  wheel  22736437 Sep  4 20:14 base.tgz
-rw-r--r--  1 hf  wheel  21984558 Sep  4 20:15 comp.tgz
-rw-r--r--  1 hf  wheel    144226 Sep  4 20:15 etc.tgz
-rw-r--r--  1 hf  wheel   3065946 Sep  4 20:15 games.tgz
-rw-r--r--  1 hf  wheel   1419935 Sep  4 20:11
kern-GENERIC.tgz
-rw-r--r--  1 hf  wheel   1417904 Sep  4 20:11
kern-GENERICSBC.tgz
-rw-r--r--  1 hf  wheel   8333313 Sep  4 20:15 man.tgz
-rw-r--r--  1 hf  wheel   2940018 Sep  4 20:15 misc.tgz
-rw-r--r--  1 hf  wheel   2520679 Sep  4 20:15 text.tgz
-rw-r--r--  1 hf  wheel   5751366 Sep  4 20:15 xbase.tgz
-rw-r--r--  1 hf  wheel  10565421 Sep  4 20:16 xcomp.tgz
-rw-r--r--  1 hf  wheel     14839 Sep  4 20:16 xetc.tgz
-rw-r--r--  1 hf  wheel  32224887 Sep  4 20:16 xfont.tgz
-rw-r--r--  1 hf  wheel   4428004 Sep  4 20:16 xserver.tgz
[hfGstoder] ~ >

looks pretty complete. Maybe the recent gcc && gas
updates have fixed the
issues? I'll pick up the tarballs tomorrow, and drop them
on the Quadra at
home.

	hauke

--
"It's never straight up and down"     (DEVO)

On Mon, 4 Sep 2006, Hauke Fath wrote:

> Just a few uninformed comments...
...
> >I don't know why the clobber register spec is
"fp" for ELF and "a6"
> >otherwise...
>
> The pre-ELF as(1) was considerably older (and had
changes not fed back to
> GNU as) than the ELF as(1) from binutils that replaced
it. What does the
> netbsd-4 info page for as(1) say?

  From what it looked like to me is that when NetBSD
switched m68k to ELF,
a netbsd-specific m68kelf file was added, and someone
"took the
chance" to convert "a6" to
"fp".  The gcc4 compiler uses the m68kelf.h
file provided, which still used "a6".

>
> >isn't "fp" just an alias for
"a6"? I tried changing it to
> >use "a6" unconditionally, but that
doesn't work either:
> >
> >/usr/src.local/sys/arch/mac68k/mac68k/macrom.c: In
function 'mrg_aline_super':
> >/usr/src.local/sys/arch/mac68k/mac68k/macrom.c:763:
error: %a6 cannot be
> >used in asm here

  I suspect that gcc3 may never have done anything with
a6/fp if present,
but gcc4, being more strict, generates an error.  I looked
at the code
generated by a gcc3 compiler, and it doesn't appear to do
anything
different, so I suspect that removing the a6/fp from the
clobber list
won't really change anything.

> >
> >The comments say "save a6" and
"restore a6", but I don't see where
> >that happens.
>
> Nor do I. Ask Allen Briggs, since according to 'cvs
annotate' he added the
> comments.  ;)
>
> > They also say that it'll possibly change A6, but
I don't
> >see when that would happen either.
>
> Ask Scott Reynolds, since... see above. Although Allen
may be easier to reach.

  The aline traps are either routines provided by the NetBSD
code, or
MacROM routines.  It's quite possible the MacROM routines
could clobber
a6.  Since the old gcc3 generated code doesn't appear to
have saved a6, I
suspect that nothing currently used does.  The comment about
"save a6" and
"restore a6" are offset from the other comments,
which leads me to suspect
the intent was to document the possible need to save/restore
a6, but not
actually do it unless a need to do it showed up.

  My inclination would be to just remove the a6/fp from the
clobber list,
since it doesn't seem to have actually done anything
before.

--
Michael L. Hitch			mhitchmontana.edu
Computer Consultant
Information Technology Center
Montana State University	Bozeman, MT	USA

khymazeotrope.org wrote:

>         (caddr_t *)prev = &mrg_DTList;
>  
> I think changing the last line to:
> 	prev = (caddr_t)&mrg_DTList;
> will do the same thing.

This looks fixed already.

> /usr/src.local/sys/arch/mac68k/mac68k/macrom.c: In
function 'mrg_aline_super':
> /usr/src.local/sys/arch/mac68k/mac68k/macrom.c:728:
error: unknown register name 'fp' in 'asm'
 :
> #ifdef __ELF__
> 			  "fp"
> #else
> 			  "a6"
> #endif
> 
> I don't know why the clobber register spec is
"fp" for ELF and "a6"
> otherwise... isn't "fp" just an alias for
"a6"?

Maybe binutils-2.9.x or egcs-2.91.x restriction when m68k
ports
switched to ELF.

> I tried changing it to
> use "a6" unconditionally, but that doesn't
work either:

> /usr/src.local/sys/arch/mac68k/mac68k/macrom.c: In
function 'mrg_aline_super':
> /usr/src.local/sys/arch/mac68k/mac68k/macrom.c:763:
error: %a6 cannot be used in asm here

> The comments say "save a6" and
"restore a6", but I don't see where
> that happens. They also say that it'll possibly change
A6, but I don't
> see when that would happen either. Are there some ROM
toolbox calls
> that will modify A6? That seems like it'd be a bad
thing for a
> subroutine to not restore the frame pointer...
>
> Anyways, I don't know if it's the right thing to do,
but I just
> removed fp/a6 from the list of clobbered registers.

I guess it's okay, because as mentioned in the warning,
there is nothing to do by compiler if the frame pointer
is actually modified in the asm block.
If the called routine actually breaks the frame pointer,
we should save it before calling the function in the asm
manually, as the comment said. (but I'm not sure, maybe
port-m68k or port-toolchain is the right place to ask)

> /usr/src.local/sys/arch/m68k/m68k/pmap_motorola.c: In
function 'pmap_changebit':
> /usr/src.local/sys/arch/m68k/m68k/pmap_motorola.c:2518:
warning: 'pg_' may be used uninitialized in this function
> /usr/src.local/sys/arch/m68k/m68k/pmap_motorola.c:2525:
warning: 'pg_' may be used uninitialized in this function

This has been fixed with a HACK. (see src/doc/HACKS)
---
Izumi Tsutsui

>>> Did you get a working kernel in the end? I have
an idle Quadra 650 around
>>> that I could drop a snapshot of netbsd-4
onto...

>> I don't currently have a netbsd-4 snapshot, but I
could build a set of
>> GENERIC netbsd-4/gcc 4 kernels for people to try
out...

Just FYI: I have a snapshot of NetBSD 4 which is built with
gcc 4 except 
for the kernel running on a Quadra 605. To test the system a
bit, I'm 
having it self host a complete NetBSD 4 build, also using
gcc 4.

Did someone say that the kernel can now be built using gcc
4?

John

Jeffrey Loren Shaw wrote:
> Another thing that would be nice to see in the next
version of 
> netbsd-m68k is the preliminary support for DMA on av
macs that someone 
> posted they wrote and submitted.
> And unnder heavy hard drive activity netbsd crashes
sometimes. For 
> instance mine crashed at least twice while trying to do
> cd /usr/pkgsrc/editors/xemacs-packages
> make install
> , which handles lots of small text files.

That would be sweet.  I'm not sure exactly what DMA does
for you, but 
since I've got a Q840, that'd be great.  


Tim

-- 
Tim & Alethea
christtrek.org

I wrote:

> > I tried changing it to
> > use "a6" unconditionally, but that
doesn't work either:
> 
> > /usr/src.local/sys/arch/mac68k/mac68k/macrom.c: In
function 'mrg_aline_super':
> >
/usr/src.local/sys/arch/mac68k/mac68k/macrom.c:763: error:
%a6 cannot be used in asm here
> 
> > The comments say "save a6" and
"restore a6", but I don't see where
> > that happens. They also say that it'll possibly
change A6, but I don't
> > see when that would happen either. Are there some
ROM toolbox calls
> > that will modify A6? That seems like it'd be a
bad thing for a
> > subroutine to not restore the frame pointer...
> >
> > Anyways, I don't know if it's the right thing to
do, but I just
> > removed fp/a6 from the list of clobbered
registers.
> 
> I guess it's okay, because as mentioned in the
warning,
> there is nothing to do by compiler if the frame pointer
> is actually modified in the asm block.
> If the called routine actually breaks the frame
pointer,
> we should save it before calling the function in the
asm
> manually, as the comment said.

I've committed a fix which just removes fp/a6 from
clobbered list,
and now GENERIC compiles with gcc4.

Could anyone test a gcc4 GENERIC kernel on real mac68k
machines?
http://www.ceres.dti.ne.jp/~tsutsui/
netbsd/netbsd-macppc-GENERIC-20060909.gz

BTW, did a GENERIC compiled with gcc3 even work?
For PR port-mac68k/32583, does the latest patch in the PR
just work
but not committed yet?
How about port-mac68k/33636?
---
Izumi Tsutsui