| Author |
Message |
|
| Guest |
 Posted: Fri Feb 02, 2007 5:20 pm |
 |
|
|
Guest
|
Hi, I sent these patches earlier to patches@, but they didn't reach the
mailing list so I'm reposting them to erlang-bugs@.
All patches are against R11B-3.
/ Jon
This fixes a bug on OpenBSD/sparc64 build - this needs to be conditionalized for
OpenBSD if these are the right flags for other sparc64 OS'en.
--- erts/emulator/Makefile.in.orig Mon Jan 29 13:52:09 2007
+++ erts/emulator/Makefile.in Wed Jan 31 17:25:33 2007
@@ -137,7 +137,7 @@ darwinCFLAGS=-DDARWIN
noopsysCFLAGS=
OPSYSCFLAGS=$($(OPSYS)CFLAGS)
ARCH=@ARCH@
-ultrasparcCFLAGS=-Wa,-xarch=v8plusa
+ultrasparcCFLAGS=
ARCHCFLAGS=$($(ARCH)CFLAGS)
ifdef HIPE_ENABLED
This fixes a hang in the configure script on OpenBSD/amd64 similiar to the FreeBSD one.
--- erts/configure.in.orig Wed Jan 31 17:36:19 2007
+++ erts/configure.in Wed Jan 31 17:37:08 2007
@@ -1855,14 +1855,14 @@ static __inline__ int check_fpe(double f
#endif
-#if (defined(__linux__) && (defined(__i386__) || defined(__x86_64__) || defined(__sparc__) || defined(
__powerpc__))
) || (defined(__DARWIN__) && (defined(__i386__) || defined(__ppc__))) || (defined(__FreeBSD__) && (defi
ned(__i386__)
|| defined(__x86_64__))) || (defined(__sun__) && defined(__x86_64__))
+#if (defined(__linux__) && (defined(__i386__) || defined(__x86_64__) || defined(__sparc__) || defined(
__powerpc__))
) || (defined(__DARWIN__) && (defined(__i386__) || defined(__ppc__))) || ((defined(__OpenBSD__) || defi
ned(__FreeBSD
__)) && (defined(__i386__) || defined(__x86_64__))) || (defined(__sun__) && defined(__x86_64__))
#if defined(__linux__) && defined(__i386__)
#include <asm/sigcontext.h>
#elif defined(__FreeBSD__) && defined(__i386__)
#include <sys/types.h>
#include <machine/npx.h>
-#elif defined(__FreeBSD__) && defined(__x86_64__)
+#elif (defined(__OpenBSD__) || defined(__FreeBSD__)) && defined(__x86_64__)
#include <sys/types.h>
#include <machine/fpu.h>
#endif
----- End forwarded message -----
--
Jon
_______________________________________________
erlang-bugs mailing list
erlang-bugs@erlang.org
http://www.erlang.org/mailman/listinfo/erlang-bugs
Post recived from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Fri Feb 02, 2007 6:31 pm |
|
|
|
Guest
|
On Fri, 2 Feb 2007 18:19:38 +0100, Jon Olsson wrote:
>Hi, I sent these patches earlier to patches@, but they didn't reach the
>mailing list so I'm reposting them to erlang-bugs@.
>
>All patches are against R11B-3.
>
>/ Jon
>
>This fixes a bug on OpenBSD/sparc64 build - this needs to be conditionalized for
>OpenBSD if these are the right flags for other sparc64 OS'en.
>--- erts/emulator/Makefile.in.orig Mon Jan 29 13:52:09 2007
>+++ erts/emulator/Makefile.in Wed Jan 31 17:25:33 2007
>@@ -137,7 +137,7 @@ darwinCFLAGS=-DDARWIN
> noopsysCFLAGS=
> OPSYSCFLAGS=$($(OPSYS)CFLAGS)
> ARCH=@ARCH@
>-ultrasparcCFLAGS=-Wa,-xarch=v8plusa
>+ultrasparcCFLAGS=
> ARCHCFLAGS=$($(ARCH)CFLAGS)
>
> ifdef HIPE_ENABLED
They were introduced originally for Solaris, but they
also see use (whether needed or not) on Linux.
They are (were) needed on Solaris because the compilers do not
necessarily support the SPARC v9 instruction set by default,
and parts of the runtime system need(ed) to include v9 instructions.
What exactly is the failure on OpenBSD?
>This fixes a hang in the configure script on OpenBSD/amd64 similiar to the FreeBSD one.
>--- erts/configure.in.orig Wed Jan 31 17:36:19 2007
>+++ erts/configure.in Wed Jan 31 17:37:08 2007
>@@ -1855,14 +1855,14 @@ static __inline__ int check_fpe(double f
>
> #endif
>
>-#if (defined(__linux__) && (defined(__i386__) || defined(__x86_64__) || defined(__sparc__) || defined(
>__powerpc__))
>) || (defined(__DARWIN__) && (defined(__i386__) || defined(__ppc__))) || (defined(__FreeBSD__) && (defi
>ned(__i386__)
> || defined(__x86_64__))) || (defined(__sun__) && defined(__x86_64__))
>+#if (defined(__linux__) && (defined(__i386__) || defined(__x86_64__) || defined(__sparc__) || defined(
>__powerpc__))
>) || (defined(__DARWIN__) && (defined(__i386__) || defined(__ppc__))) || ((defined(__OpenBSD__) || defi
>ned(__FreeBSD
>__)) && (defined(__i386__) || defined(__x86_64__))) || (defined(__sun__) && defined(__x86_64__))
>
> #if defined(__linux__) && defined(__i386__)
> #include <asm/sigcontext.h>
> #elif defined(__FreeBSD__) && defined(__i386__)
> #include <sys/types.h>
> #include <machine/npx.h>
>-#elif defined(__FreeBSD__) && defined(__x86_64__)
>+#elif (defined(__OpenBSD__) || defined(__FreeBSD__)) && defined(__x86_64__)
> #include <sys/types.h>
> #include <machine/fpu.h>
> #endif
This patch is broken due word-wrapping. But what it implies is
that OpenBSD should receive the same treatment as FreeBSD wrt
floating-point exceptions and SIGFPE handlers, correct?
A (perhaps temporary) shell account on an x86-32 and an x86-64
OpenBSD box would do wonders for Erlang/OTP's OpenBSD support.
(That's how the FreeBSD folks got their verified support for HiPE,
floating-point exceptions, and SMP. Hint hint, nudge nudge.)
/Mikael
_______________________________________________
erlang-bugs mailing list
erlang-bugs@erlang.org
http://www.erlang.org/mailman/listinfo/erlang-bugs
Post recived from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Sat Feb 03, 2007 8:11 am |
|
|
|
Guest
|
On Fri, Feb 02, 2007 at 07:29:55PM +0100, Mikael Pettersson wrote:
> On Fri, 2 Feb 2007 18:19:38 +0100, Jon Olsson wrote:
[snip]
> They were introduced originally for Solaris, but they
> also see use (whether needed or not) on Linux.
> They are (were) needed on Solaris because the compilers do not
> necessarily support the SPARC v9 instruction set by default,
> and parts of the runtime system need(ed) to include v9 instructions.
>
> What exactly is the failure on OpenBSD?
cc -O2 -pipe -I/usr/ports/lang/erlang/w-erlang-11b.2/otp_src_R11B-2/erts/sparc64-unknown-openbsd4.0 -DUSE_THREADS -D_THREAD_SAFE -D_REENTRANT -DHAVE_CONFIG_H -Wall -Wstrict-prototypes -Wmissing-prototypes -DUSE_THREADS -D_THREAD_SAFE -D_REENTRANT -Wa,-xarch=v8plusa -Ibeam -Isys/unix -Isys/common -Isparc64-unknown-openbsd4.0/opt/plain -Isparc64-unknown-openbsd4.0 -Izlib -Ihipe -I../include/internal -I../include/internal/sparc64-unknown-openbsd4.0 -c hipe/hipe_mkliterals.c -o obj/sparc64-unknown-openbsd4.0/opt/plain/hipe_mkliterals.o
{standard input}: Assembler messages:
{standard input}:286: Error: internal error: can't export reloc type 91 (`BFD_RELOC_SPARC_H44')
{standard input}:289: Error: internal error: can't export reloc type 92 (`BFD_RELOC_SPARC_M44')
{standard input}:293: Error: internal error: can't export reloc type 93 (`BFD_RELOC_SPARC_L44')
{standard input}:841: Error: internal error: can't export reloc type 91 (`BFD_RELOC_SPARC_H44')
{standard input}:844: Error: internal error: can't export reloc type 92 (`BFD_RELOC_SPARC_M44')
{standard input}:848: Error: internal error: can't export reloc type 93 (`BFD_RELOC_SPARC_L44')
{standard input}:856: Error: internal error: can't export reloc type 91 (`BFD_RELOC_SPARC_H44')
{standard input}:857: Error: internal error: can't export reloc type 91 (`BFD_RELOC_SPARC_H44')
{standard input}:858: Error: internal error: can't export reloc type 92 (`BFD_RELOC_SPARC_M44')
{standard input}:859: Error: internal error: can't export reloc type 92 (`BFD_RELOC_SPARC_M44')
{standard input}:864: Error: internal error: can't export reloc type 93 (`BFD_RELOC_SPARC_L44')
{standard input}:865: Error: internal error: can't export reloc type 93 (`BFD_RELOC_SPARC_L44')
{standard input}:867: Error: internal error: can't export reloc type 91 (`BFD_RELOC_SPARC_H44')
{standard input}:869: Error: internal error: can't export reloc type 92 (`BFD_RELOC_SPARC_M44')
{standard input}:874: Error: internal error: can't export reloc type 93 (`BFD_RELOC_SPARC_L44')
{standard input}:885: Error: internal error: can't export reloc type 92 (`BFD_RELOC_SPARC_M44')
{standard input}:887: Error: internal error: can't export reloc type 91 (`BFD_RELOC_SPARC_H44')
{standard input}:895: Error: internal error: can't export reloc type 92 (`BFD_RELOC_SPARC_M44')
{standard input}:898: Error: internal error: can't export reloc type 93 (`BFD_RELOC_SPARC_L44')
{standard input}:915: Error: internal error: can't export reloc type 91 (`BFD_RELOC_SPARC_H44')
{standard input}:916: Error: internal error: can't export reloc type 92 (`BFD_RELOC_SPARC_M44')
{standard input}:920: Error: internal error: can't export reloc type 93 (`BFD_RELOC_SPARC_L44')
{standard input}:939: Error: internal error: can't export reloc type 91 (`BFD_RELOC_SPARC_H44')
{standard input}:940: Error: internal error: can't export reloc type 92 (`BFD_RELOC_SPARC_M44')
{standard input}:944: Error: internal error: can't export reloc type 93 (`BFD_RELOC_SPARC_L44')
{standard input}:959: Error: internal error: can't export reloc type 91 (`BFD_RELOC_SPARC_H44')
{standard input}:961: Error: internal error: can't export reloc type 92 (`BFD_RELOC_SPARC_M44')
{standard input}:966: Error: internal error: can't export reloc type 93 (`BFD_RELOC_SPARC_L44')
{standard input}:972: Error: internal error: can't export reloc type 92 (`BFD_RELOC_SPARC_M44')
{standard input}:984: Error: internal error: can't export reloc type 91 (`BFD_RELOC_SPARC_H44')
{standard input}:985: Error: internal error: can't export reloc type 92 (`BFD_RELOC_SPARC_M44')
{standard input}:990: Error: internal error: can't export reloc type 93 (`BFD_RELOC_SPARC_L44')
{standard input}:1026: Error: internal error: can't export reloc type 91 (`BFD_RELOC_SPARC_H44')
{standard input}:1028: Error: internal error: can't export reloc type 92 (`BFD_RELOC_SPARC_M44')
{standard input}:1032: Error: internal error: can't export reloc type 93 (`BFD_RELOC_SPARC_L44')
{standard input}:1036: Error: internal error: can't export reloc type 91 (`BFD_RELOC_SPARC_H44')
{standard input}:1038: Error: internal error: can't export reloc type 92 (`BFD_RELOC_SPARC_M44')
{standard input}:1041: Error: internal error: can't export reloc type 93 (`BFD_RELOC_SPARC_L44')
{standard input}:1043: Error: internal error: can't export reloc type 91 (`BFD_RELOC_SPARC_H44')
{standard input}:1044: Error: internal error: can't export reloc type 91 (`BFD_RELOC_SPARC_H44')
{standard input}:1045: Error: internal error: can't export reloc type 92 (`BFD_RELOC_SPARC_M44')
{standard input}:1046: Error: internal error: can't export reloc type 92 (`BFD_RELOC_SPARC_M44')
{standard input}:1049: Error: internal error: can't export reloc type 93 (`BFD_RELOC_SPARC_L44')
{standard input}:1057: Error: internal error: can't export reloc type 91 (`BFD_RELOC_SPARC_H44')
{standard input}:1060: Error: internal error: can't export reloc type 92 (`BFD_RELOC_SPARC_M44')
{standard input}:1062: Error: internal error: can't export reloc type 93 (`BFD_RELOC_SPARC_L44')
{standard input}:1066: Error: internal error: can't export reloc type 93 (`BFD_RELOC_SPARC_L44')
{standard input}:1070: Error: internal error: can't export reloc type 91 (`BFD_RELOC_SPARC_H44')
{standard input}:1085: Error: internal error: can't export reloc type 91 (`BFD_RELOC_SPARC_H44')
{standard input}:1086: Error: internal error: can't export reloc type 92 (`BFD_RELOC_SPARC_M44')
{standard input}:1090: Error: internal error: can't export reloc type 93 (`BFD_RELOC_SPARC_L44')
{standard input}:1105: Error: internal error: can't export reloc type 91 (`BFD_RELOC_SPARC_H44')
{standard input}:1107: Error: internal error: can't export reloc type 92 (`BFD_RELOC_SPARC_M44')
{standard input}:1112: Error: internal error: can't export reloc type 93 (`BFD_RELOC_SPARC_L44')
{standard input}:1118: Error: internal error: can't export reloc type 92 (`BFD_RELOC_SPARC_M44')
{standard input}:1153 reloc type 91 (`BFD_RELOC_SPARC_H44')
{standard input}:1155: Error: internal error: can't export reloc type 92 (`BFD_RELOC_SPARC_M44')
{standard input}:1159: Error: internal error: can't port reloc type 93 (`BFD_RELOC_SPARC_L44')
{standard input}:1162: Error: internal error: can't export reloc type 91 (`BFD_RELOC_SPARC_H44')
{standard input}:1164: Error: internal error: canype 92 (`BFD_RELOC_SPARC_M44')
{standard input}:1168: Error: internal error: can't export reloc type 93 (`BFD_RELOC_SPARC_L44')
{standard input}:1171: Error: internal error: can't export rec type 91 (`BFD_RELOC_SPARC_H44')
{standard input}:1173: Error: internal error: can't export reloc type 92 (`BFD_RELOC_SPARC_M44')
{standard input}:1178: Error: internal error: can't export reloc type 93 (`BFD_RELOC_SPARC_L44')
{standard input}:1179: Eror: internal error: can't export reloc type 91 (`BFD_RELOC_SPARC_H44')
{standard input}:1181: Error: internal error: can't export reloc type 92 (`BFD_RELOC_SPARC_M44')
{standard input}:118 Error: internal error: can't export reloc type 93 (`BFD_RELOC_SPARC_L44')
{standard input}:1185: Error: internal error: can'ttandard input}:1192: Error: internal error: can't export reloc pe 91 (`BFD_RELOC_SPARC_H44')
{standard input}:1193: Error: internal error: can't export reloc type 92 (`BFD_RELOC_SPARC_M44')
{standard input}:1194: Error: internal error: can't export relype 92 (`BFD_RELOC_SPARC_M44')
{standard input}:1197: Error: internal error: can't export reloc type 93 (`BFD_RELOC_SPARC_L44')
{standard input}:1200: Error: internal error: can't export re type 93 (`BFD_RELOC_SPARC_L44')
{standard input}:1201: Error: internal error: can't export reloc type 91 (`BFD_RELOC_SPARC_H44')
{standard input}:1202: Error: internal error: can't export loc type 91 (`BFD_RELOC_SPARC_H44')
{standard input}:1203: Error: internal error: can't export reloc type 92 (`BFD_RELOC_SPARC_M44')
{standard input}:1204: Error: internal error: can't export reloc type 92 (`BFD_RELOC_SPARC_M44')
{standard input}:1207:ror: internal error: can't export reloc type 93 (`BFD_RELOC_SPARC_L44')
{standard input}:1210: Error: internal error: can't export reloc type 93 (`BFD_RELOC_SPARC_L44')
{standard input}:121rror: internal error: can't export reloc type 91 (`BFD_RELOC_SPARC_H44')
{standard input}:1216: Error: internal error: can't export reloc type 92 (`BFD_RELOC_SPARC_M44')
{standard input}:12: Error: internal error: can't export reloc type 93 (`BFD_RELOC_SPARC_L44')
{standard input}:1222: Error: internal error: can't export reloc type 91 (`BFD_RELOC_SPARC_H44')
{standard input}4: Error: internal error: can't export reloc type 92 (`BFD_RELOC_SPARC_M44')
{standard input}:1227: Error: internal error: can't export reloc type 93 (`BFD_RELOC_SPARC_L44')
{standard input}:1228: Error: internal error: can't export reloc type 91 (`BFD_RELOC_SPARC_H44')
{standard input}:1230: Error: internal error: can't export reloc type 92 (`BFD_RELOC_SPARC_M44')
{standard :1235: Error: internal error: can't export reloc type 93 (`BFD_RELOC_SPARC_L44')
{standard input}:1255: Error: internal error:t reloc type 92 (`BFD_RELOC_SPARC_M44')
{standard input}:1326: Error: internal error: can't export reloc type 93 (`BFD_RELOC_SRC_L44')
{standard input}:1333: Error: internal error: can't export reloc type 93 (`BFD_RELOC_SPARC_L44')
{standard input}:1334: Error: internal error: can't export reloc type 91 (`BFD_RELOPARC_H44')
{standard input}:1337: Error: internal error: can't export reloc type 92 (`BFD_RELOC_SPARC_M44')
{standard input}:1339: Error: internal error: can't export reloc type 93 (`BFD_RE_SPARC_L44')
{standard input}:1343: Error: internal error: can't export reloc type 91 (`BFD_RELOC_SPARC_H44')
{standard input}:1344: Error: internal error: can't export reloc type 91 (`BFD_LOC_SPARC_H44')
{standard input}:1346: Error: internal error: can't export reloc type 92 (`BFD_RELOC_SPARC_M44')
{standard input}:1347: Error: internal error: can't export reloc type 92 (`BELOC_SPARC_M44')
{standard input}:1350: Error: internal error: n't export reloc type 93 (`BFD_RELOC_SPARC_L44')
{standard input}:1351: Error: internal error: can't export reloc type 93 (`BFC_SPARC_L44')
{standard input}:1361: Fatal error: {standard inp}:523: bad return from bfd_install_relocation: 4
gmake[2]: *** [obj/sparc64-unknown-openbsd4.0/opt/plain/hipe_mkliterals.o] Error 1
gmake[2]: Leaving directory `/usr/ports/lang/erlang/w-erlb.2/otp_src_R11B-2/erts/emulator'
gmake[1]: *** [generate] Error 2
gmake[1]: Leaving directory `/usr/ports/lang/erlang/w-erlan11b.2/otp_src_R11B-2/erts/emulator'
gmake: *** [depend] Error 2
[snip word wrapped patch]
> This patch is broken due word-wrapping. But what it implies is
> that OpenBSD should receive the same treatment as FreeBSD wrt
> floating-point exceptions and SIGFPE handlers, correct?
Correct, adding the patches as attachement now, sorry about
the copy'n'pasto.
> A (perhaps temporary) shell account on an x86-32 and an x86-64
> OpenBSD box would do wonders for Erlang/OTP's OpenBSD support.
> (That's how the FreeBSD folks got their verified support for HiPE,
> floating-point exceptions, and SMP. Hint hint, nudge nudge.)
My x86-32 OpenBSD box could possibly be used for that, although
it is dog slow so, it won't be pleasant using it.
--
Jon
Post recived from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Sat Feb 03, 2007 11:41 am |
|
|
|
Guest
|
On Sat, 3 Feb 2007 09:10:33 +0100, Jon Olsson <jon@vexed.se> wrote:
> > They were introduced originally for Solaris, but they
> > also see use (whether needed or not) on Linux.
> > They are (were) needed on Solaris because the compilers do not
> > necessarily support the SPARC v9 instruction set by default,
> > and parts of the runtime system need(ed) to include v9 instructions.
> >
> > What exactly is the failure on OpenBSD?
>
> cc -O2 -pipe -I/usr/ports/lang/erlang/w-erlang-11b.2/otp_src_R11B-2/erts/sparc64-unknown-openbsd4.0 -DUSE_THREADS -D_THREAD_SAFE -D_REENTRANT -DHAVE_CONFIG_H -Wall -Wstrict-prototypes -Wmissing-prototypes -DUSE_THREADS -D_THREAD_SAFE -D_REENTRANT -Wa,-xarch=v8plusa -Ibeam -Isys/unix -Isys/common -Isparc64-unknown-openbsd4.0/opt/plain -Isparc64-unknown-openbsd4.0 -Izlib -Ihipe -I../include/internal -I../include/internal/sparc64-unknown-openbsd4.0 -c hipe/hipe_mkliterals.c -o obj/sparc64-unknown-openbsd4.0/opt/plain/hipe_mkliterals.o
> {standard input}: Assembler messages:
> {standard input}:286: Error: internal error: can't export reloc type 91 (`BFD_RELOC_SPARC_H44')
> {standard input}:289: Error: internal error: can't export reloc type 92 (`BFD_RELOC_SPARC_M44')
> {standard input}:293: Error: internal error: can't export reloc type 93 (`BFD_RELOC_SPARC_L44')
> {standard input}:841: Error: internal error: can't export reloc type 91 (`BFD_RELOC_SPARC_H44')
etc
That smells like a toolchain (binutils/gas) bug. It certainly works with the versions I
have on my Aurora Linux SPARC64 machine.
Hmm, does your `cc' perhaps default to building 64-bit code? The v8plusa option should
not be needed in that case, and might even be harmful.
> This fixes a bug on OpenBSD/sparc64
> --- erts/emulator/Makefile.in.orig Mon Jan 29 13:52:09 2007
> +++ erts/emulator/Makefile.in Wed Jan 31 17:25:33 2007
> @@ -137,7 +137,7 @@ darwinCFLAGS=-DDARWIN
> noopsysCFLAGS=
> OPSYSCFLAGS=$($(OPSYS)CFLAGS)
> ARCH=@ARCH@
> -ultrasparcCFLAGS=-Wa,-xarch=v8plusa
> +ultrasparcCFLAGS=
> ARCHCFLAGS=$($(ARCH)CFLAGS)
Unfortunately this change breaks Solaris/SPARC:
gcc -g -O3 -fomit-frame-pointer -I/tmp/mikpe/otp-0202/erts/sparc-sun-solaris2.9 -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -DUSE_THREADS -D_THREAD_SAFE -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS -DHYBRID -DHAVE_CONFIG_H -Wall -Wstrict-prototypes -Wmissing-prototypes -DUSE_THREADS -D_THREAD_SAFE -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS -Ibeam -Isys/unix -Isys/common -Isparc-sun-solaris2.9/opt/hybrid -Isparc-sun-solaris2.9 -Izlib -Ihipe -I../include/internal -I../include/internal/sparc-sun-solaris2.9 -c beam/io.c -o obj/sparc-sun-solaris2.9/opt/hybrid/io.o
beam/io.c: In function 'io_list_to_vec':
beam/io.c:922: warning: pointer targets in assignment differ in signedness
beam/io.c: In function 'deliver_vec_message':
beam/io.c:1735: warning: pointer targets in assignment differ in signedness
/usr/ccs/bin/as: "/tmp/ccJaaCzj.s", line 1599: error: cannot use v8plus instructions in a non-v8plus target binary
/usr/ccs/bin/as: "/tmp/ccJaaCzj.s", line 1611: error: cannot use v8plus instructions in a non-v8plus target binary
/usr/ccs/bin/as: "/tmp/ccJaaCzj.s", line 1617: error: cannot use v8plus instructions in a non-v8plus target binary
(many more of these follow)
The issue is that we MUST use V9 instructions for atomic operations, but the assembler
rejects them unless the v8plusa option is passed to it.
This means that you need to figure out how to make this change only for OpenBSD.
An update in erts/configure{.in,} to detect OpenBSD and set OPSYS accordingly,
plus some trickery in erts/emulator/Makefile.in, should suffice.
/Mikael
_______________________________________________
erlang-bugs mailing list
erlang-bugs@erlang.org
http://www.erlang.org/mailman/listinfo/erlang-bugs
Post recived from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Mon Feb 05, 2007 11:23 am |
|
|
|
Guest
|
On Sat, Feb 03, 2007 at 12:40:53PM +0100, Mikael Pettersson wrote:
> Hmm, does your `cc' perhaps default to building 64-bit code? The v8plusa option should
> not be needed in that case, and might even be harmful.
It seems to be the case that OpenBSD/sparc64 gcc generates 64-bit code.
% gcc foo.c
% file a.out
a.out: ELF 64-bit MSB executable, Sparc64, version 1, for OpenBSD, dynamically linked (uses shared libs), not stripped
> The issue is that we MUST use V9 instructions for atomic operations, but the assembler
> rejects them unless the v8plusa option is passed to it.
>
> This means that you need to figure out how to make this change only for OpenBSD.
> An update in erts/configure{.in,} to detect OpenBSD and set OPSYS accordingly,
> plus some trickery in erts/emulator/Makefile.in, should suffice.
Ok, I'll cook something up later this week perhaps.
--
Jon
_______________________________________________
erlang-bugs mailing list
erlang-bugs@erlang.org
http://www.erlang.org/mailman/listinfo/erlang-bugs
Post recived from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Mon Feb 12, 2007 9:42 am |
|
|
|
Guest
|
On Sun, Feb 04, 2007 at 11:03:34PM +0100, Jon Olsson wrote:
> Ok, I'll cook something up later this week perhaps.
Here's an updated patch, I'm also including the diff for the amd64
floating point exceptions issue.
erts/configure.in | 5 +++--
erts/emulator/Makefile.in | 5 +++++
2 files changed, 8 insertions(+), 2 deletions(-)
Post recived from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Thu Feb 15, 2007 3:53 pm |
|
|
|
Guest
|
Jon Olsson writes:
> On Sun, Feb 04, 2007 at 11:03:34PM +0100, Jon Olsson wrote:
> > Ok, I'll cook something up later this week perhaps.
>
> Here's an updated patch, I'm also including the diff for the amd64
> floating point exceptions issue.
>
> erts/configure.in | 5 +++--
> erts/emulator/Makefile.in | 5 +++++
> 2 files changed, 8 insertions(+), 2 deletions(-)
>
> $OpenBSD: patch-erts_configure_in,v 1.1 2007/02/03 11:48:39 steven Exp $
> --- erts/configure.in.orig Mon Jan 29 13:53:26 2007
> +++ erts/configure.in Sun Feb 11 22:42:06 2007
> @@ -304,6 +304,7 @@ SunOS) case `uname -r` in
> Linux) OPSYS=linux;;
> Darwin) OPSYS=darwin;;
> FreeBSD) OPSYS=freebsd;;
> +OpenBSD) OPSYS=openbsd;;
> esac
> ARCH=noarch
> case `uname -m` in
...
> --- erts/emulator/Makefile.in.orig Mon Jan 29 13:52:09 2007
> +++ erts/emulator/Makefile.in Sun Feb 11 22:38:23 2007
> @@ -137,7 +137,12 @@ darwinCFLAGS=-DDARWIN
> noopsysCFLAGS=
> OPSYSCFLAGS=$($(OPSYS)CFLAGS)
> ARCH=@ARCH@
> +
> +ifeq ($(OPSYS),openbsd)
> +ultrasparcCFLAGS=
> +else
> ultrasparcCFLAGS=-Wa,-xarch=v8plusa
> +endif
> ARCHCFLAGS=$($(ARCH)CFLAGS)
While this may solve your immediate problem (64-bit mode code
on OpenBSD/SPARC64), it's inappropriate for other cases: What
if the user prefers to generate 32-bit code on OpenBSD? What
about other operating systems on SPARC64?
I've checked in the patch below which solves the problem by
using ARCH=sparc64 instead of ARCH=ultrasparc when the C compiler
generates 64-bit mode code. This is similar to the solution I
used for x86 machines where `uname` alone is insufficient to
detect if the system will be built in 32- or 64-bit mode.
This patch was required to let me build a 64-bit system on
an Ultra running Linux.
/Mikael
--- otp-0202/erts/configure.in.~1~ 2006-11-24 13:51:40.000000000 +0100
+++ otp-0202/erts/configure.in 2007-02-14 19:55:02.000000000 +0100
@@ -308,7 +308,7 @@ esac
ARCH=noarch
case `uname -m` in
sun4u) ARCH=ultrasparc;;
-sparc64) ARCH=ultrasparc;;
+sparc64) ARCH=sparc64;;
sun4v) ARCH=ultrasparc;;
i86pc) ARCH=x86;;
i386) ARCH=x86;;
@@ -327,6 +327,7 @@ esac
dnl
dnl Convert between x86 and amd64 based on the compiler's mode.
+dnl Ditto between ultrasparc and sparc64.
dnl
AC_MSG_CHECKING(whether compilation mode forces ARCH adjustment)
case "$ARCH-$ac_cv_sizeof_void_p" in
@@ -338,6 +339,14 @@ amd64-4)
AC_MSG_RESULT(yes: adjusting ARCH=amd64 to ARCH=x86)
ARCH=x86
;;
+ultrasparc-
+ AC_MSG_RESULT(yes: adjusting ARCH=ultrasparc to ARCH=sparc64)
+ ARCH=amd64
+ ;;
+sparc64-4)
+ AC_MSG_RESULT(yes: adjusting ARCH=sparc64 to ARCH=ultrasparc)
+ ARCH=x86
+ ;;
*)
AC_MSG_RESULT(no)
;;
--- otp-0202/erts/configure.~1~ 2006-11-24 13:51:40.000000000 +0100
+++ otp-0202/erts/configure 2007-02-14 19:58:28.000000000 +0100
@@ -1423,7 +1423,7 @@ esac
ARCH=noarch
case `uname -m` in
sun4u) ARCH=ultrasparc;;
-sparc64) ARCH=ultrasparc;;
+sparc64) ARCH=sparc64;;
sun4v) ARCH=ultrasparc;;
i86pc) ARCH=x86;;
i386) ARCH=x86;;
@@ -1451,6 +1451,14 @@ amd64-4)
echo "$ac_t""yes: adjusting ARCH=amd64 to ARCH=x86" 1>&6
ARCH=x86
;;
+ultrasparc-
+ echo "$ac_t""yes: adjusting ARCH=ultrasparc to ARCH=sparc64" 1>&6
+ ARCH=amd64
+ ;;
+sparc64-4)
+ echo "$ac_t""yes: adjusting ARCH=sparc64 to ARCH=ultrasparc" 1>&6
+ ARCH=x86
+ ;;
*)
echo "$ac_t""no" 1>&6
;;
_______________________________________________
erlang-bugs mailing list
erlang-bugs@erlang.org
http://www.erlang.org/mailman/listinfo/erlang-bugs
Post recived from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Thu Feb 15, 2007 4:14 pm |
|
|
|
Guest
|
On Thu, Feb 15, 2007 at 04:52:16PM +0100, Mikael Pettersson wrote:
[snip]
> While this may solve your immediate problem (64-bit mode code
> on OpenBSD/SPARC64), it's inappropriate for other cases: What
> if the user prefers to generate 32-bit code on OpenBSD? What
> about other operating systems on SPARC64?
For the record:
core% uname -a
OpenBSD xxx.yyy.com 4.0 GENERIC#999 sparc64
core% gcc -m32 z.c
cc1: error: -m32 is not supported by this configuration
I guess this means OpenBSD doesn't support 32 bit code compilation
on sparc64? Correct me if I'm wrong.
Cheers,
--
Jon
_______________________________________________
erlang-bugs mailing list
erlang-bugs@erlang.org
http://www.erlang.org/mailman/listinfo/erlang-bugs
Post recived from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Thu Feb 15, 2007 4:31 pm |
|
|
|
Guest
|
Jon Olsson writes:
> On Thu, Feb 15, 2007 at 04:52:16PM +0100, Mikael Pettersson wrote:
> [snip]
> > While this may solve your immediate problem (64-bit mode code
> > on OpenBSD/SPARC64), it's inappropriate for other cases: What
> > if the user prefers to generate 32-bit code on OpenBSD? What
> > about other operating systems on SPARC64?
>
> For the record:
>
> core% uname -a
> OpenBSD xxx.yyy.com 4.0 GENERIC#999 sparc64
> core% gcc -m32 z.c
> cc1: error: -m32 is not supported by this configuration
>
> I guess this means OpenBSD doesn't support 32 bit code compilation
> on sparc64? Correct me if I'm wrong.
Well, this particular gcc cannot generate 32-bit mode code.
But that's an exception: gcc is usually configured as a
"bi-arch" compiler that can generate either 32-bit or 64-bit
code, and many 64-bit systems make 32-bit code the default.
It's certainly possible that OpenBSD on SPARC64 has completely
banned all 32-bit mode code, making your change OK for OpenBSD.
But even if they have done that, inferring 64-bitness from the
C compiler instead of `uname` is a safer and more general solution.
/Mikael
_______________________________________________
erlang-bugs mailing list
erlang-bugs@erlang.org
http://www.erlang.org/mailman/listinfo/erlang-bugs
Post recived from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Thu Feb 15, 2007 7:00 pm |
|
|
|
Guest
|
On Thu, Feb 15, 2007 at 05:30:34PM +0100, Mikael Pettersson wrote:
> Jon Olsson writes:
> > On Thu, Feb 15, 2007 at 04:52:16PM +0100, Mikael Pettersson wrote:
> > [snip]
> > > While this may solve your immediate problem (64-bit mode code
> > > on OpenBSD/SPARC64), it's inappropriate for other cases: What
> > > if the user prefers to generate 32-bit code on OpenBSD? What
> > > about other operating systems on SPARC64?
> >
> > For the record:
> >
> > core% uname -a
> > OpenBSD xxx.yyy.com 4.0 GENERIC#999 sparc64
> > core% gcc -m32 z.c
> > cc1: error: -m32 is not supported by this configuration
> >
> > I guess this means OpenBSD doesn't support 32 bit code compilation
> > on sparc64? Correct me if I'm wrong.
>
> Well, this particular gcc cannot generate 32-bit mode code.
> But that's an exception: gcc is usually configured as a
> "bi-arch" compiler that can generate either 32-bit or 64-bit
> code, and many 64-bit systems make 32-bit code the default.
>
> It's certainly possible that OpenBSD on SPARC64 has completely
> banned all 32-bit mode code, making your change OK for OpenBSD.
> But even if they have done that, inferring 64-bitness from the
> C compiler instead of `uname` is a safer and more general solution.
I wasn't disagreeing with your changes/comment regarding sparc64 in
general, just stating the "OpenBSD world order".
Cheers,
--
Jon
_______________________________________________
erlang-bugs mailing list
erlang-bugs@erlang.org
http://www.erlang.org/mailman/listinfo/erlang-bugs
Post recived from mailinglist |
|
|
| Back to top |
|
|
|
All times are GMT
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You cannot download files in this forum
|
|
|
Digg It
Del.icio.us
Reddit
Facebook
Stumble Upon
Technorati
