Thread: got Postgresql working on FreeBSD-alpha
http://people.freebsd.org/~alfred/pgsql/port-alpha.diff This enables spinlocks for FreeBSD on both i386 and alpha as well as removing the -m486 compiler flag. i386 port should be tested heavily as I'm in foriegn territory porting and messing with autoconf. There's still some warnings that have me concerned: http://people.freebsd.org/~alfred/pgsql/build.log Are the format problems solved on Linux-alpha somehow? Regression looked a bit upset, but a lot seems to be cosmetic: http://people.freebsd.org/~alfred/pgsql/regression.diffs -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk."
Alfred Perlstein writes: > There's still some warnings that have me concerned: > http://people.freebsd.org/~alfred/pgsql/build.log In outfuncs.c, that was somebody's cute idea to print pointers like printf("%x", (int) ptr); rather than printf("%p", ptr); Same in s_lock.c. The format warnings look like size_t being used as %d or %u. You'll probably have to add casts everywhere. -- Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
* Peter Eisentraut <peter_e@gmx.net> [001114 09:11] wrote: > Alfred Perlstein writes: > > > There's still some warnings that have me concerned: > > http://people.freebsd.org/~alfred/pgsql/build.log > > In outfuncs.c, that was somebody's cute idea to print pointers like > > printf("%x", (int) ptr); > > rather than > > printf("%p", ptr); > > Same in s_lock.c. The format warnings look like size_t being used as %d > or %u. You'll probably have to add casts everywhere. grr! :) I'll take a shot at it. thanks, -Alfred
* Alfred Perlstein <bright@wintelcom.net> [001114 09:47] wrote: > * Peter Eisentraut <peter_e@gmx.net> [001114 09:11] wrote: > > Alfred Perlstein writes: > > > > > There's still some warnings that have me concerned: > > > http://people.freebsd.org/~alfred/pgsql/build.log > > > > In outfuncs.c, that was somebody's cute idea to print pointers like > > > > printf("%x", (int) ptr); > > > > rather than > > > > printf("%p", ptr); > > > > Same in s_lock.c. The format warnings look like size_t being used as %d > > or %u. You'll probably have to add casts everywhere. > > grr! :) > > I'll take a shot at it. > updated: http://people.freebsd.org/~alfred/pgsql/port-alpha.diff Make pgsql compile on FreeBSD-alpha. Remove -m486 compile args for FreeBSD-i386. Make the port use the TEST_AND_SET for alpha and i386 on FreeBSD. Fix a lot of bogus string formats for outputting pointers (cast to int and %u/%x replaced with no cast and %p), and 'Size'(size_t) are now cast to 'unsigned long' and output with %lu/ Remove an unused variable. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk."
Alfred Perlstein writes: > http://people.freebsd.org/~alfred/pgsql/port-alpha.diff > > Make pgsql compile on FreeBSD-alpha. > > Remove -m486 compile args for FreeBSD-i386. > > Make the port use the TEST_AND_SET for alpha and i386 on FreeBSD. > > Fix a lot of bogus string formats for outputting pointers (cast to int > and %u/%x replaced with no cast and %p), and 'Size'(size_t) are now > cast to 'unsigned long' and output with %lu/ > > Remove an unused variable. That variable *is* used, if you compile with -DXLOG, which will be the default eventually. Also: !case $host_cpu in ! alpha*) CFLAGS="$CFLAGS -O";; ! i386*) CFLAGS="$CFLAGS -O2";; ! esac s/i386/i.86/, or better s/i386//. Trouble with -O2? Being conservative? About the regression tests: Apparently you're picking up the wrong "expected" files. I can't make out why offhand, though. Modulo that, the inet failure looks to be the only real trouble. -- Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
It's updated and moved: http://people.freebsd.org/~alfred/pgsql/port-alpha2.diff Responses below: * Peter Eisentraut <peter_e@gmx.net> [001114 14:10] wrote: > Alfred Perlstein writes: > > > http://people.freebsd.org/~alfred/pgsql/port-alpha.diff > > > > Make pgsql compile on FreeBSD-alpha. > > > > Remove -m486 compile args for FreeBSD-i386. > > > > Make the port use the TEST_AND_SET for alpha and i386 on FreeBSD. > > > > Fix a lot of bogus string formats for outputting pointers (cast to int > > and %u/%x replaced with no cast and %p), and 'Size'(size_t) are now > > cast to 'unsigned long' and output with %lu/ > > > > Remove an unused variable. > > That variable *is* used, if you compile with -DXLOG, which will be the > default eventually. Ok fixed. (variable is #ifdef XLOG) > Also: > > !case $host_cpu in > ! alpha*) CFLAGS="$CFLAGS -O";; > ! i386*) CFLAGS="$CFLAGS -O2";; > ! esac > > s/i386/i.86/, or better s/i386//. FreeBSD always reports i386. -O2 is not appropriate for arches other than i386 because of potential gcc bugs. > Trouble with -O2? Being conservative? Yes, possible gcc bugs under alpha. ~ % gcc -O2 t.c cc1: warning: *** *** The -O2 flag TRIGGERS KNOWN OPTIMIZER BUGS ON THIS PLATFORM *** .(14:28:46)(alfred@beast.freebsd.org) ~ % uname -a FreeBSD beast.freebsd.org 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Sat Nov 11 14:27:30 PST 2000 root@beast.freebsd.org:/usr/src/sys/compile/BEAST alpha fear. :) > About the regression tests: Apparently you're picking up the wrong > "expected" files. I can't make out why offhand, though. Modulo that, the > inet failure looks to be the only real trouble. Yes, can you point to at the general location of that code? I'd like to see if it's a FreeBSD bug, FreeBSD-alpha bug, Postgresql bug or Postgresql-alpha bug or any combination thereof. :) I've updated the patch again, I've changed the CFLAGS to be -O on everything but i386 and #ifdef'd the variable based on XLOG. I've also run regression on i386 since I've posted the patch and the results are consistant with i386 without my patch. Question, how much of an impact is using test and set over using system semaphores? Would it be worth it to patch 7.0.x for alpha and using hardware spinlocks rather than kernel mutexes? I'd like to give my FreeBSD boxes running 7.0.3 a little boost if possible... -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk."
Alfred Perlstein writes: > > About the regression tests: Apparently you're picking up the wrong > > "expected" files. I can't make out why offhand, though. Modulo that, the > > inet failure looks to be the only real trouble. > > Yes, can you point to at the general location of that code? I'd > like to see if it's a FreeBSD bug, FreeBSD-alpha bug, Postgresql > bug or Postgresql-alpha bug or any combination thereof. :) A short explanation of the mechanism is at the end of src/test/regress/README. Depending on how you invoke the regression test you'll have to look into pg_regress, regress.sh, or run_check.sh for the implementation. I recommend using 'gmake check' or 'gmake installcheck', which would invoke the former. The others are obsolescent. > Question, how much of an impact is using test and set over using > system semaphores? Would it be worth it to patch 7.0.x for alpha > and using hardware spinlocks rather than kernel mutexes? Generally, test and set should be a lot faster. Specifically, the non-TAS code is probably broken and will be removed sometime. -- Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
* Peter Eisentraut <peter_e@gmx.net> [001115 12:18] wrote: > Alfred Perlstein writes: > > > > About the regression tests: Apparently you're picking up the wrong > > > "expected" files. I can't make out why offhand, though. Modulo that, the > > > inet failure looks to be the only real trouble. > > > > Yes, can you point to at the general location of that code? I'd > > like to see if it's a FreeBSD bug, FreeBSD-alpha bug, Postgresql > > bug or Postgresql-alpha bug or any combination thereof. :) > > A short explanation of the mechanism is at the end of > src/test/regress/README. Depending on how you invoke the regression test > you'll have to look into pg_regress, regress.sh, or run_check.sh for the > implementation. I recommend using 'gmake check' or 'gmake installcheck', > which would invoke the former. The others are obsolescent. > > > Question, how much of an impact is using test and set over using > > system semaphores? Would it be worth it to patch 7.0.x for alpha > > and using hardware spinlocks rather than kernel mutexes? > > Generally, test and set should be a lot faster. Specifically, the non-TAS > code is probably broken and will be removed sometime. Can you commit my patch as is for the time being? People are touching files near where my work was done. :( I'll try to address the inet problem with alpha when I get a chance, I'm wondering if there's a problem on Linux-alpha as well, any idea? -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk."