sparc64/freebsd configuration patch

[Kurt Lidl]

Here's a couple of diffs that allow the current CVS
version of pcc to configure and compile on sparc64/freebsd.

It almost generates working code. There's some grot at
the head of the assembly prolog:

.section .rodata
.type Hello World!\012,#object
.size Hello World!\012,14
L220:

If I comment out the emitted ".type" and ".size" lines in
the .s file, I can then link the resulting .s file into
a working binary. (Only tried on a 'hello world' type
program.)

I haven't tried digger further yet, but here's the first patch.

-Kurt


diff -r fc2815c71e10 configure.ac
--- a/configure.ac Fri Jun 22 07:03:58 2012 +0000
+++ b/configure.ac Fri Jun 22 16:04:33 2012 -0400
@@ -80,6 +80,7 @@
esac
case "$target_cpu" in
i386) targmach=i386 ;;
+ sparc64) targmach=sparc64 endian=big ;;
x86_64) targmach=amd64 ;;
esac
;;
diff -r fc2815c71e10 os/freebsd/ccconfig.h
--- a/os/freebsd/ccconfig.h Fri Jun 22 07:03:58 2012 +0000
+++ b/os/freebsd/ccconfig.h Fri Jun 22 16:04:33 2012 -0400
@@ -41,7 +41,7 @@
#define ENDFILES { LIBDIR "crtend.o", LIBDIR "crtn.o", NULL }
#define STARTFILES_S { LIBDIR "crti.o", LIBDIR "crtbeginS.o", NULL }
#define ENDFILES_S { LIBDIR "crtendS.o", LIBDIR "crtn.o", NULL }
-#define LIBCLIBS { "-lc", "-lpcc", NULL }
+#define LIBCLIBS { "-lc", /* "-lpcc", */ NULL }
#define STARTLABEL "_start"

/* host-independent */
@@ -53,6 +53,10 @@
#define CPPMDADD \
{ "-D__x86_64__", "-D__x86_64", "-D__amd64__", "-D__amd64", \
"-D__LP64__=1", "-D_LP64=1", NULL, }
+#elif defined(mach_sparc64)
+#define CPPMDADD \
+ { "-D__sparc64__", "-D__sparc_v9__", "-D__sparc__", "-D__sparc",\
+ "-D__LP64__=1", "-D_LP64=1", NULL, }
#else
#error defines for arch missing
#endif

[Kurt Lidl]

Post by Kurt Lidl
Here's a couple of diffs that allow the current CVS
version of pcc to configure and compile on sparc64/freebsd.
It almost generates working code. There's some grot at
.section .rodata
.type Hello World!\012,#object
.size Hello World!\012,14
If I comment out the emitted ".type" and ".size" lines in
the .s file, I can then link the resulting .s file into
a working binary. (Only tried on a 'hello world' type
program.)

what is the input that produced such output is it just a plain
hello_world.c program?

--- snip, snip ---
#include <stdio.h>
#include <stdlib.h>

int
main(int argc, char *argv[]) {
int x = 0;

x = 1234;

printf("Hello World!\n");
return 0;
}
--- snip, snip ---

the #object is, at least, produced in arch/sparc64/code.c and should not
be, for a const data..

Post by Kurt Lidl
-#define LIBCLIBS { "-lc", "-lpcc", NULL }
+#define LIBCLIBS { "-lc", /* "-lpcc", */ NULL }

per this, is it that libpcc is never required on FreeBSD? It seems the
other BSDs usually provide their own helper functions..

Well, with the specification of -lpcc (which I don't have) the pcc
compiler fails to link to a binary. Without -lpcc in the linker
args, (modulo commenting out the two lines in the output), it produces
a working binary.

I was also able to take the .s file generated by pcc (again, after
commenting out those two line) and link that using gcc into a working
binary.

I don't know definatively, if commenting out -lpcc is really correct or
not, but it got me past that little bump in the road.

-Kurt

[Iain Hibbert]

Post by Kurt Lidl

Post by Kurt Lidl
-#define LIBCLIBS { "-lc", "-lpcc", NULL }
+#define LIBCLIBS { "-lc", /* "-lpcc", */ NULL }

per this, is it that libpcc is never required on FreeBSD? It seems the
other BSDs usually provide their own helper functions..

Well, with the specification of -lpcc (which I don't have) the pcc
compiler fails to link to a binary. Without -lpcc in the linker
args, (modulo commenting out the two lines in the output), it produces
a working binary.

I think the minimal test is, to check out pcc-libs and look in
pcc-libs/libpcc. If the functions provided that start with __ are provided
by the host libc, then libpcc will not be needed for now. Probably an
autoconf test could be written for that..

regards,
iain

[Iain Hibbert]

Post by Kurt Lidl
Here's a couple of diffs that allow the current CVS
version of pcc to configure and compile on sparc64/freebsd.
It almost generates working code. There's some grot at
.section .rodata
.type Hello World!\012,#object
.size Hello World!\012,14
If I comment out the emitted ".type" and ".size" lines in
the .s file, I can then link the resulting .s file into
a working binary. (Only tried on a 'hello world' type
program.)

what is the input that produced such output is it just a plain
hello_world.c program?

the #object is, at least, produced in arch/sparc64/code.c and should not
be, for a const data..

Post by Kurt Lidl
-#define LIBCLIBS { "-lc", "-lpcc", NULL }
+#define LIBCLIBS { "-lc", /* "-lpcc", */ NULL }

per this, is it that libpcc is never required on FreeBSD? It seems the
other BSDs usually provide their own helper functions..

iain

[Anders Magnusson]

Post by Kurt Lidl
-#define LIBCLIBS { "-lc", "-lpcc", NULL }
+#define LIBCLIBS { "-lc", /* "-lpcc", */ NULL }

per this, is it that libpcc is never required on FreeBSD? It seems the
other BSDs usually provide their own helper functions..

libpcc should be installed and used on FreeBSD, even though most stuff
is in libc. have never tried it on Sparc though.

Kurt, you need the pcc-libs package to install it.

-- Ragge

[Kurt Lidl]

Post by Kurt Lidl
Here's a couple of diffs that allow the current CVS
version of pcc to configure and compile on sparc64/freebsd.
It almost generates working code. There's some grot at
.section .rodata
.type Hello World!\012,#object
.size Hello World!\012,14
If I comment out the emitted ".type" and ".size" lines in
the .s file, I can then link the resulting .s file into
a working binary. (Only tried on a 'hello world' type
program.)

what is the input that produced such output is it just a plain
hello_world.c program?
the #object is, at least, produced in arch/sparc64/code.c and should not
be, for a const data..

I think that the code in arch/sparc64/code.c:defloc() is just wrong.
Comparing it to all other instances of the defloc() function
shows that it's just "different".

If I replace the defloc() function with the same code from the
i386 version of that function, recompile the compiler, the resulting
compiler actually generates a working binary.

-Kurt