> 
> 
> Could __error be trampling on the a0 register? The C compiler is
> allowed to use it as a temporary.

The code disassembles to this....

(gdb) disassem __error
Dump of assembler code for function __error:
0x120001920 <__error>:  27bb2000  9     ldah    gp, 536870912(t12)
0x120001924 <__error+4>:        23bd6a40  8     lda     gp, 27200(gp)
0x120001928 <__error+8>:        23deffe0  8     lda     sp, -32(sp)
0x12000192c <__error+12>:       b75e0000 2d     stq     ra, 0(sp)
0x120001930 <__error+16>:       b5fe0008 2d     stq     fp, 8(sp)
0x120001934 <__error+20>:       47de040f 11     bis     sp, sp, fp
0x120001938 <__error+24>:       201fe078  8     lda     v0, -8072(zero)
0x12000193c <__error+28>:       401d0440 10     s4addq  v0, gp, v0
0x120001940 <__error+32>:       a4000000 29     ldq     v0, 0(v0)
0x120001944 <__error+36>:
    c3e00000 30 br      zero, 0x120001948 <__error+40>
0x120001948 <__error+40>:       45ef041e 11     bis     fp, fp, sp
0x12000194c <__error+44>:       a75e0000 29     ldq     ra, 0(sp)
0x120001950 <__error+48>:       a5fe0008 29     ldq     fp, 8(sp)
0x120001954 <__error+52>:       43c4141e 10     addq    sp, 0x20, sp
0x120001958 <__error+56>:       6bfa8001 1a     ret     zero, (ra), 1
End of assembler dump.
Current language:  auto; currently asm


Doesn't look like a0 is touched (assuming I can believe my hacked gdb 8-)>).

And cerror disassembles to .....


(gdb) disassem cerror
Dump of assembler code for function cerror:
0x12000baf0 <cerror>:   c0200000 30     br      t0, 0x12000baf4 <cerror+4>
0x12000baf4 <cerror+4>: 27a12000  9     ldah    gp, 536870912(t0)
0x12000baf8 <cerror+8>: 23bdc86c  8     lda     gp, -14228(gp)
0x12000bafc <cerror+12>:        47e00410 11     bis     zero, v0, a0
0x12000bb00 <cerror+16>:        237fe238  8     lda     t12, -7624(zero)
0x12000bb04 <cerror+20>:        437d045b 10     s4addq  t12, gp, t12
0x12000bb08 <cerror+24>:        a77b0000 29     ldq     t12, 0(t12)
0x12000bb0c <cerror+28>:        6b5b578c 1a     jsr     ra, (t12), 0x120011940
0x12000bb10 <cerror+32>:        27ba2000  9     ldah    gp, 536870912(ra)
0x12000bb14 <cerror+36>:        23bdc850  8     lda     gp, -14256(gp)
0x12000bb18 <cerror+40>:        b2000000 2c     stl     a0, 0(v0)
0x12000bb1c <cerror+44>:        201fffff  8     lda     v0, -1(zero)
0x12000bb20 <cerror+48>:        6bfa8001 1a     ret     zero, (ra), 1
End of assembler dump.

> 
> That shouldn't cause the bus error, though. Keep in mind that on the
> alpha, bus errors usually aren't pinpointed very accurately, so it
> could be +/- a few instructions.

When I look at gdb output again, it is reporting ...

(gdb) where
#0  cerror () at /u/thread/dev/netbsd/libc/cerror.S:67
#1  0x12000bb10 in cerror () at /u/thread/dev/netbsd/libc/cerror.S:62

and line 67 is the stl a0, 0(v0).

Hmmm, if bus errors aren't pinpointed accurately, then it may not be getting
out of __error (which I assumed it was). I can successfully write(1,..) before
returning from __error.

Looking at the register dump, I expected to see v0 with the address of
the global errno. The register dump is ... 


(gdb) info reg
v0             0xffffffffffffffff       -1
t0             0x12000baf4      4831886068
t1             0x0      0
t2             0x0      0
t3             0x0      0
t4             0x0      0
t5             0x0      0
t6             0x0      0
t7             0x0      0
s0             0x0      0
s1             0x1fffffb20      8589933344
s2             0x1fffffb30      8589933360
s3             0xbabefacedeadbeef       -4990275570673795345
s4             0x1      1
s5             0xbabefacedeadbeef       -4990275570673795345
s6             0x1ffffeea8      8589930152
a3             0x1      1
a4             0x1fffff020      8589930528
a5             0x1ffffe8fc      8589928700
t8             0x0      0
t9             0x0      0
t10            0x0      0
t11            0x0      0
ra             0x12000bb10      4831886096
t12            0x120001920      4831844640
at             0x12000baf0      4831886064
sp             0x1ffffeea8      8589930152
zero           0x1ffffe6c0      8589928128
ps             0x8      8
pc             0x12000bb18      4831886104
gp             0x140008360      5368742752
a0             0x16     22
a1             0x1ffffef90      8589930384
a2             0x1ffffefb0      8589930416
vfp            0x1ffffeea8      8589930152

This shows that a0 wasn't clobbered (expected EINVAL = 22). I don't know if the 
value of v0 is the result of 'lda v0, -1(zero)' or if it wasn't set the the
return value of __error.

> 
> --
> Trevor Blackwell         tlb@eecs.harvard.edu          (617) 495-8912
> 


-- 
John Birrell                                CIMlogic Pty Ltd
jb@cimlogic.com.au                          119 Cecil Street
Ph  +61  3 9690 9600                        South Melbourne Vic 3205
Fax +61  3 9690 6650                        Australia
Mob +61 18  353  137