On Sat, Apr 2, 2011 at 1:09 AM, Ian Lance Taylor <i...@google.com> wrote:
> On Wed, Mar 30, 2011 at 12:58 PM, Uros Bizjak <ubiz...@gmail.com> wrote:
>>
>> Attached ports go to ALPHA architecture.
>
> Thanks!
>
> Committed.
>
>
>> b) alpha doesn't define "struct user_regs_struct" from which "type
>> PtraceRegs" is derived. I have manually created PtraceRegs from
>> pt_regs structure and patched generated libgo/sysinfo.go in build
>> directory after the build broke. However - the comment from sys/user.h
>> says that this file is for GDB and GDB only...
>
> libgo uses it to support ptrace, which in effect is the same as what
> gdb does. If mksysinfo.sh is unable to provide any definition for the
> structure, then the choices are either to patch up mksysinfo.sh so
> that it works, or to simply define the structure in
> libgo/syscalls/syscall_linux_alpha.go. it is unlikely to change so
> the latter seems acceptable if patching mksysinfo is too hard.
Attached patch implements this suggestion and builds libgo without problems.
>> c) some weird issue with double definition of "const _SOCK_NONBLOCK"
>> in gen-sysinfo.go and consequently sysinfo.go.
>
> The code in gcc/godump.c uses a hash table to keep this from
> happening; I'm not sure why that is not working in this case. Is
> SOCK_NONBLOCK both a #define macro and an enum value?
Yes, SOCK_NONBLOCK is defined in bits/sock.h as
--cut here--
enum __socket_type
{
#undef SOCK_NONBLOCK
SOCK_NONBLOCK = 0x40000000 /* Atomically mark descriptor(s) as
non-blocking. */
#define SOCK_NONBLOCK SOCK_NONBLOCK
};
/* Get socket manipulation related informations from kernel headers. */
#include "asm/socket.h"
--cut here--
asm/socket.h:
--cut here--
/* O_NONBLOCK clashes with the bits used for socket types. Therefore we
* have to define SOCK_NONBLOCK to a different value here.
*/
#define SOCK_NONBLOCK 0x40000000
--cut here--
Processing bits/socket.h with -fdumo-go-spec= , we get:
// unknowndefine SOCK_NONBLOCK SOCK_NONBLOCK
const _SOCK_NONBLOCK = 0x40000000
const _SOCK_NONBLOCK = 1073741824
>
>> The test results from "make -k check" in libgo directory are quite
>> encouraging:
>
> Yes.
>
>> FAIL: cmath
>> panic: runtime error: integer divide by zero or floating point error
>
> This is peculiar--it looks like there is something systematically
> causing a division by zero. I wonder what it could be.
I will try to analyse these failures. Perhaps these failures are due
to the fact that alpha needs -mieee to handle NaN and Inf values (a
FPE is generated otherwise).
Thanks,
Uros.
Index: libgo/syscalls/syscall_linux_alpha.go
===================================================================
--- libgo/syscalls/syscall_linux_alpha.go (revision 171911)
+++ libgo/syscalls/syscall_linux_alpha.go (working copy)
@@ -6,6 +6,38 @@
package syscall
+type PtraceRegs struct {
+ R0 uint64
+ R1 uint64
+ R2 uint64
+ R3 uint64
+ R4 uint64
+ R5 uint64
+ R6 uint64
+ R7 uint64
+ R8 uint64
+ R19 uint64
+ R20 uint64
+ R21 uint64
+ R22 uint64
+ R23 uint64
+ R24 uint64
+ R25 uint64
+ R26 uint64
+ R27 uint64
+ R28 uint64
+ Hae uint64
+ Trap_a0 uint64
+ Trap_a1 uint64
+ Trap_a2 uint64
+ Ps uint64
+ Pc uint64
+ Gp uint64
+ R16 uint64
+ R17 uint64
+ R18 uint64
+}
+
func (r *PtraceRegs) PC() uint64 {
return r.Pc;
}
