Re: CVS commit: src/sys/arch/amiga/amiga

2020-08-08 Thread Rin Okuyama

Hi,

Sorry for the serious delay in my response.

On 2020/07/22 13:37, matthew green wrote:

thanks for getting more m68k working!


Thanks!


"Rin Okuyama" writes:

Module Name:src
Committed By:   rin
Date:   Tue Jul 21 06:39:31 UTC 2020

Modified Files:
src/sys/arch/amiga/amiga: locore.s

Log Message:
Align tmpstk to 4-byte boundary in the same manner as mac68k.

However, unfortunately, this does not fix strange crashes of GCC8-compiled
kernel, for which I cannot even enter DDB nor obtain crash dump.

We need further investigation...


boo.  can you update the README.gcc8 file (external/gpl3/gcc),
for the m68k: line on L87 or so, and add 'y' for the known
working kernels, and 'n' for the failed ones.


Finally, I managed GCC8 to work for amiga kernel! Can you please take a
look into port-m68k/6 ?

http://gnats.netbsd.org/6

I will update the table when the patch in the PR and related ones are
committed. After that, I think m68k ports can be switched to GCC8.

Thanks,
rin


re: CVS commit: src/sys/arch/amiga/amiga

2020-07-21 Thread matthew green
thanks for getting more m68k working!

"Rin Okuyama" writes:
> Module Name:  src
> Committed By: rin
> Date: Tue Jul 21 06:39:31 UTC 2020
> 
> Modified Files:
>   src/sys/arch/amiga/amiga: locore.s
> 
> Log Message:
> Align tmpstk to 4-byte boundary in the same manner as mac68k.
> 
> However, unfortunately, this does not fix strange crashes of GCC8-compiled
> kernel, for which I cannot even enter DDB nor obtain crash dump.
> 
> We need further investigation...

boo.  can you update the README.gcc8 file (external/gpl3/gcc),
for the m68k: line on L87 or so, and add 'y' for the known
working kernels, and 'n' for the failed ones.

thanks.


.mrg.


Re: CVS commit: src/sys/arch/amiga/amiga

2011-11-17 Thread Izumi Tsutsui
> Module Name:  src
> Committed By: mlelstv
> Date: Thu Nov 17 07:45:54 UTC 2011
> 
> Modified Files:
>   src/sys/arch/amiga/amiga: machdep.c
> 
> Log Message:
> identifycpu() is not just cosmetic for the banner but initializes how FPU
> contexts are saved.
> Also drop code that checks for fputype before it is determined.

Is it really ok to remove m68k_make_fpu_idle_frame()?
Shouldn't it be moved after identifycpu()?

I wonder if it would affect recent awk problem on port-amiga.

---
Izumi Tsutsui