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;
}
next prev parent 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).