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

Re: ARAnyM VMs with Debian hanging at 100% CPU usage

Andreas Schwab dixit:

>Thorsten Glaser <tg@mirbsd.de> writes:
>> GCC happens to generate these if you use the atomic builtins
>> even in 4.6 already.
>I don't.

You don’t say… oh well.

GCC 4.7 uses the cas instruction, against the recommendations
of the Linux kernel developers. What’s to say? Let’s force it
to use the syscall then.

root@aranym:~ # gcc-4.7 -O2 -g3 -Wall -o t47 t.c -m68000
root@aranym:~ # gdb ./t47
Dump of assembler code for function main:
   0x80000354 <+0>:     linkw %fp,#0
   0x80000358 <+4>:     movel %a3,%sp@-
   0x8000035a <+6>:     movel %a2,%sp@-
   0x8000035c <+8>:     movel 0x80003388 <ctr>,%d0
   0x80000362 <+14>:    movel %d0,%sp@-
   0x80000364 <+16>:    pea 0x80001248
   0x8000036a <+22>:    lea 0x80000304 <printf@plt>,%a3
   0x80000370 <+28>:    jsr %a3@
   0x80000372 <+30>:    clrl %sp@-
   0x80000374 <+32>:    lea 0x80000318 <fflush@plt>,%a2
   0x8000037a <+38>:    jsr %a2@
=> 0x8000037c <+40>:    pea 0x1
   0x80000380 <+44>:    pea 0x80003388 <ctr>
   0x80000386 <+50>:    jsr 0x80000a06 <__sync_add_and_fetch_4>
   0x8000038c <+56>:    addql #8,%sp
   0x8000038e <+58>:    movel 0x80003388 <ctr>,%d0
   0x80000394 <+64>:    movel %d0,%sp@-
   0x80000396 <+66>:    pea 0x80001253
   0x8000039c <+72>:    jsr %a3@
   0x8000039e <+74>:    clrl %sp@-
   0x800003a0 <+76>:    jsr %a2@
   0x800003a2 <+78>:    moveq #0,%d0
(gdb) si
0x80000a06 in __sync_add_and_fetch_4 ()
(gdb) disas
Dump of assembler code for function __sync_add_and_fetch_4:
=> 0x80000a06 <+0>:     linkw %fp,#0
   0x80000a0a <+4>:     moveml %d2-%d3/%a2,%sp@-
   0x80000a0e <+8>:     moveal %fp@(8),%a2
   0x80000a12 <+12>:    movel %a2@,%d2
   0x80000a14 <+14>:    movel %fp@(12),%d3
   0x80000a18 <+18>:    addl %d2,%d3
   0x80000a1a <+20>:    moveal %a2,%a0
   0x80000a1c <+22>:    movel %d3,%d1
   0x80000a1e <+24>:    movel #335,%d0
   0x80000a24 <+30>:    trap #0
   0x80000a26 <+32>:    cmpl %d2,%d0
   0x80000a28 <+34>:    bnes 0x80000a34 <__sync_add_and_fetch_4+46>
   0x80000a2a <+36>:    movel %d3,%d0
   0x80000a2c <+38>:    moveml %sp@+,%d2-%d3/%a2
   0x80000a30 <+42>:    unlk %fp
   0x80000a32 <+44>:    rts
   0x80000a34 <+46>:    movel %d0,%d2
   0x80000a36 <+48>:    bras 0x80000a14 <__sync_add_and_fetch_4+14>
End of assembler dump.
0x80000a24 in __sync_add_and_fetch_4 ()
(gdb) info r
d0             0x14f    335
d1             0x12345679       305419897
d2             0x12345678       305419896
d3             0x12345679       305419897
d4             0x1d     29
d5             0xd004eefc       -804983044
d6             0xd004edfc       -804983300
d7             0xc      12
a0             0x80003388       0x80003388
a1             0xc014b7f4       0xc014b7f4
a2             0x80003388       0x80003388
a3             0x80000304       0x80000304
a4             0x800003b0       0x800003b0
a5             0xc0148000       0xc0148000
fp             0xef8d4b60       0xef8d4b60
sp             0xef8d4b54       0xef8d4b54
ps             0x8300   [ I0 I1 T1 ]
pc             0x80000a24       0x80000a24 <__sync_add_and_fetch_4+30>
fpcontrol      0x0      0
fpstatus       0x0      0
fpiaddr        0x0      0
(gdb) si
[… aaaaaaand, freeze! ]

Okay. So there’s something wrong with either the way how
GCC uses the syscall, or how the syscall is implemented
in Linux, or how ARAnyM runs that (unlikely).

Additionally, GCC doesn’t use the syscall with -m68020,
which is default in Debian/m68k. Linux and Debian devs,
please comment on whether that should be kept or changed.

“It is inappropriate to require that a time represented as
 seconds since the Epoch precisely represent the number of
 seconds between the referenced time and the Epoch.”
	-- IEEE Std 1003.1b-1993 (POSIX) Section B.2.2.2

Reply to: