public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Uros Bizjak <ubizjak@gmail.com>
To: Ian Lance Taylor <iant@google.com>
Cc: gcc-patches@gcc.gnu.org, gofrontend-dev@googlegroups.com
Subject: Re: [RFC PATCH, go]: Port to ALPHA arch
Date: Sun, 03 Apr 2011 17:46:00 -0000	[thread overview]
Message-ID: <BANLkTimr+W+6TEbyeKoJUSXynUjTGtPtbg@mail.gmail.com> (raw)
In-Reply-To: <BANLkTinHNEB97kTMF1km9KYg-yKNKHH04A@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2685 bytes --]

On Sat, Apr 2, 2011 at 1:09 AM, Ian Lance Taylor <iant@google.com> wrote:
> On Wed, Mar 30, 2011 at 12:58 PM, Uros Bizjak <ubizjak@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.

[-- Attachment #2: a.diff.txt --]
[-- Type: text/plain, Size: 730 bytes --]

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;
 }

  reply	other threads:[~2011-04-03 17:46 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-30 20:12 Uros Bizjak
2011-04-01 23:09 ` Ian Lance Taylor
2011-04-03 17:46   ` Uros Bizjak [this message]
2011-05-31 19:50     ` Ian Lance Taylor

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=BANLkTimr+W+6TEbyeKoJUSXynUjTGtPtbg@mail.gmail.com \
    --to=ubizjak@gmail.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=gofrontend-dev@googlegroups.com \
    --cc=iant@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).