Thread: Minimal patches for PostgreSQL 7.0b3 on NetBSD/alpha 1.4.1....
Here are minimal patches to get 7.0 beta 3 limping along on NetBSD/alpha release 1.4.1. There are lots of problems with the oid handling, and I can't get it to successfully even begin to do a make runcheck, make runtest, or make bigtest. The results of a maketest are: =============== Notes... ================= postmaster must already be running for the regression tests to succeed. The time zone is set to PST8PDT for these tests by the client frontend. Please report any apparent problems to ports@postgresql.org See regress/README for more information. =============== dropping old regression database... ================= ERROR: typeidTypeRelid: Invalid type - oid = 0 dropdb: database removal failed =============== creating new regression database... ================= ERROR: createdb: database 'regression' already exists createdb: database creation failed createdb failed Minimal patches are attached. They are enough to get 7.0 beta 3 up and able to do minimal SQL queries. They are also required to get it to build at all. -- Kevin P. Neal http://www.pobox.com/~kpn/ "You're a slacker if you only give 90% 'cause you are afraid of the \ other 10%." -- Ross Smith Apr 22 1999 2:29am
Attachment
On Tue, 11 Apr 2000, Kevin P. Neal wrote:
> Here are minimal patches to get 7.0 beta 3 limping along on NetBSD/alpha
> release 1.4.1.
*** ./old/src/include/storage/s_lock.h Wed Jan 26 00:58:33 2000
--- ./new/src/include/storage/s_lock.h Sun Apr 9 23:56:46 2000
***************
*** 260,270 ****
--- 260,275 ----
#else /* i.e. not __osf__ */
#define TAS(lock) tas(lock)
#define S_UNLOCK(lock) { __asm__("mb"); *(lock) = 0; }
+ #if defined(__GNUC__)
+ static int /* GCC on the Alpha doesn't appear to handle
+ inlining of assembly with %0 or %1 properly.
*/
+ #else
static __inline__ int
+ #endif
tas(volatile slock_t *lock)
{
register slock_t _res;
__asm__(" ldq $0, %0 \n\
Any chance you could write a configure test that exposes this deficiency
rather than assuming that every GCC on every Alpha now and in the future
will have it? What does "doesn't appear to handle properly" mean anyway?
Have you notified the GCC maintainers?
Also, whose idea was it to use '__inline__' instead of 'inline'?
--
Peter Eisentraut Sernanders väg 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
Yes, we can't apply this at this stage of the game. Just too many
port-specific changes.
[Charset iso-8859-1 unsupported, filtering to ASCII...]
> On Tue, 11 Apr 2000, Kevin P. Neal wrote:
>
> > Here are minimal patches to get 7.0 beta 3 limping along on NetBSD/alpha
> > release 1.4.1.
>
> *** ./old/src/include/storage/s_lock.h Wed Jan 26 00:58:33 2000
> --- ./new/src/include/storage/s_lock.h Sun Apr 9 23:56:46 2000
> ***************
> *** 260,270 ****
> --- 260,275 ----
> #else /* i.e. not __osf__ */
>
> #define TAS(lock) tas(lock)
> #define S_UNLOCK(lock) { __asm__("mb"); *(lock) = 0; }
>
> + #if defined(__GNUC__)
> + static int /* GCC on the Alpha doesn't appear to handle
> + inlining of assembly with %0 or %1 properly.
> */
> + #else
> static __inline__ int
> + #endif
> tas(volatile slock_t *lock)
> {
> register slock_t _res;
>
> __asm__(" ldq $0, %0 \n\
>
>
> Any chance you could write a configure test that exposes this deficiency
> rather than assuming that every GCC on every Alpha now and in the future
> will have it? What does "doesn't appear to handle properly" mean anyway?
> Have you notified the GCC maintainers?
>
> Also, whose idea was it to use '__inline__' instead of 'inline'?
>
> --
> Peter Eisentraut Sernanders v_g 10:115
> peter_e@gmx.net 75262 Uppsala
> http://yi.org/peter-e/ Sweden
>
>
--
Bruce Momjian | http://www.op.net/~candle
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
"Kevin P. Neal" <kpneal@pobox.com> wrote:
>>>> Here are minimal patches to get 7.0 beta 3 limping along on NetBSD/alpha
>>>> release 1.4.1.
Has anyone compared these to Ryan Kirkpatrick's efforts for Linux/Alpha?
regards, tom lane
On Wed, 12 Apr 2000, Tom Lane wrote:
> "Kevin P. Neal" <kpneal@pobox.com> wrote:
> >>>> Here are minimal patches to get 7.0 beta 3 limping along on NetBSD/alpha
> >>>> release 1.4.1.
>
> Has anyone compared these to Ryan Kirkpatrick's efforts for Linux/Alpha?
I have not... I would glance over the patches if I could find them
(mailing list archive search turned up nothing or error messages). If some
one could forward them to me, I will give them a quick look over.
Most of the Linux/Alpha patches have to do with replacing int8,
int16, int32, and absoluteTime (not sure on the spelling of the last) to
Datum when passing to functions. Not 100% what that does, but seems to
solve a number of data corruption problems in passing data through the
utility adt functions. I plan to figure out more specificly what is going
on, but first I need to graduate from college. :)
---------------------------------------------------------------------------
| "For to me to live is Christ, and to die is gain." |
| --- Philippians 1:21 (KJV) |
---------------------------------------------------------------------------
| Ryan Kirkpatrick | Boulder, Colorado | http://www.rkirkpat.net/ |
---------------------------------------------------------------------------
I am unsure how to address this NetBSD/alpha patch. > Here are minimal patches to get 7.0 beta 3 limping along on NetBSD/alpha > release 1.4.1. > > There are lots of problems with the oid handling, and I can't get it > to successfully even begin to do a make runcheck, make runtest, or > make bigtest. > > The results of a maketest are: > =============== Notes... ================= > postmaster must already be running for the regression tests to succeed. > The time zone is set to PST8PDT for these tests by the client frontend. > Please report any apparent problems to ports@postgresql.org > See regress/README for more information. > > =============== dropping old regression database... ================= > ERROR: typeidTypeRelid: Invalid type - oid = 0 > dropdb: database removal failed > =============== creating new regression database... ================= > ERROR: createdb: database 'regression' already exists > createdb: database creation failed > createdb failed > > Minimal patches are attached. They are enough to get 7.0 beta 3 up > and able to do minimal SQL queries. They are also required to get > it to build at all. > -- > Kevin P. Neal http://www.pobox.com/~kpn/ > > "You're a slacker if you only give 90% 'cause you are afraid of the \ > other 10%." -- Ross Smith Apr 22 1999 2:29am [ Attachment, skipping... ] -- Bruce Momjian | http://www.op.net/~candle pgman@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026 *** ./old/src/backend/main/main.c Wed Jan 26 00:56:30 2000 --- ./new/src/backend/main/main.c Fri Apr 7 22:19:30 2000 *************** *** 12,27 **** --- 12,31 ---- * *------------------------------------------------------------------------- */ #include <unistd.h> + #if defined(__NetBSD__) + #include <sys/param.h> + #else #if defined(__alpha__) && !defined(linux) #include <sys/sysinfo.h> #include "machine/hal_sysinfo.h" #define ASSEMBLER #include <sys/proc.h> #undef ASSEMBLER + #endif #endif #include "postgres.h" #ifdef USE_LOCALE #include <locale.h> *** ./old/src/include/port/netbsd.h Tue Mar 7 20:58:23 2000 --- ./new/src/include/port/netbsd.h Sun Apr 9 23:49:37 2000 *************** *** 1,43 **** #define USE_POSIX_TIME #if defined(__i386__) #define NEED_I386_TAS_ASM #define HAS_TEST_AND_SET #endif #if defined(__sparc__) #define NEED_SPARC_TAS_ASM #define HAS_TEST_AND_SET #endif #if defined(__vax__) #define NEED_VAX_TAS_ASM #define HAS_TEST_AND_SET #endif #if defined(__ns32k__) #define NEED_NS32K_TAS_ASM #define HAS_TEST_AND_SET #endif #if defined(__m68k__) #define HAS_TEST_AND_SET #endif #if defined(__arm__) #define HAS_TEST_AND_SET #endif #if defined(__mips__) /* # undef HAS_TEST_AND_SET */ #endif ! #if defined(__powerpc__) #define HAS_TEST_AND_SET #endif #if defined(__powerpc__) typedef unsigned int slock_t; - #else - typedef unsigned char slock_t; #endif --- 1,50 ---- #define USE_POSIX_TIME #if defined(__i386__) #define NEED_I386_TAS_ASM #define HAS_TEST_AND_SET + typedef unsigned char slock_t; #endif #if defined(__sparc__) #define NEED_SPARC_TAS_ASM #define HAS_TEST_AND_SET + typedef unsigned char slock_t; #endif #if defined(__vax__) #define NEED_VAX_TAS_ASM #define HAS_TEST_AND_SET + typedef unsigned char slock_t; #endif #if defined(__ns32k__) #define NEED_NS32K_TAS_ASM #define HAS_TEST_AND_SET + typedef unsigned char slock_t; #endif #if defined(__m68k__) #define HAS_TEST_AND_SET + typedef unsigned char slock_t; #endif #if defined(__arm__) #define HAS_TEST_AND_SET + typedef unsigned char slock_t; #endif #if defined(__mips__) /* # undef HAS_TEST_AND_SET */ + typedef unsigned char slock_t; #endif ! #if defined(__alpha__) #define HAS_TEST_AND_SET + typedef unsigned long int slock_t; #endif #if defined(__powerpc__) + #define HAS_TEST_AND_SET typedef unsigned int slock_t; #endif *** ./old/src/include/storage/s_lock.h Wed Jan 26 00:58:33 2000 --- ./new/src/include/storage/s_lock.h Sun Apr 9 23:56:46 2000 *************** *** 260,270 **** --- 260,275 ---- #else /* i.e. not __osf__ */ #define TAS(lock) tas(lock) #define S_UNLOCK(lock) { __asm__("mb"); *(lock) = 0; } + #if defined(__GNUC__) + static int /* GCC on the Alpha doesn't appear to handle + inlining of assembly with %0 or %1 properly. */ + #else static __inline__ int + #endif tas(volatile slock_t *lock) { register slock_t _res; __asm__(" ldq $0, %0 \n\
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> I am unsure how to address this NetBSD/alpha patch.
I'd say leave it out for now. After I finish the fmgr revisions we
ought to have a better shot at porting to Alphas. I know most of
Ryan K's Linux/Alpha patches will go away with that.
I am only fifty or so functions away from updating everything that
accepts pass-by-value data types. There are a lot of pass-by-reference
data types not touched yet, but I think that those should work anywhere
that sizeof(Datum) == sizeof(pointer), so the vast majority of the
fmgr-related porting problems should be gone at that point. I will be
calling for port testers as soon as I commit those changes...
regards, tom lane
That was my guess, though his changes were s_lock related. Seems that is an Alpha mess too. > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > I am unsure how to address this NetBSD/alpha patch. > > I'd say leave it out for now. After I finish the fmgr revisions we > ought to have a better shot at porting to Alphas. I know most of > Ryan K's Linux/Alpha patches will go away with that. > > I am only fifty or so functions away from updating everything that > accepts pass-by-value data types. There are a lot of pass-by-reference > data types not touched yet, but I think that those should work anywhere > that sizeof(Datum) == sizeof(pointer), so the vast majority of the > fmgr-related porting problems should be gone at that point. I will be > calling for port testers as soon as I commit those changes... > > regards, tom lane > -- Bruce Momjian | http://www.op.net/~candle pgman@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> That was my guess, though his changes were s_lock related. Seems that is
> an Alpha mess too.
Yes, it sounds like we will need some help from a certified Alpha guru
to make spinlock code that works reliably on multi-CPU Alphas :-(.
Anyone have friends in the right places at DEC?
regards, tom lane
On Mon, Jun 12, 2000 at 05:39:55PM -0400, Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > That was my guess, though his changes were s_lock related. Seems that is > > an Alpha mess too. > > Yes, it sounds like we will need some help from a certified Alpha guru > to make spinlock code that works reliably on multi-CPU Alphas :-(. If you leave the locking code as it is then PostgreSQL will dump core. If you do not inline the locking code then the registers will not get stomped (gcc bug), and PostgreSQL will function properly enough to initialize itself and make it through a make install. Simple SQL queries work ok, but I never tried anything fancy. I haven't had the time to write up a test case to send to the GCC people. Plus, the other (much larger) set of patches that a Linux/Alpha guy wrote up did the same thing my patches did, but differently (-fno-inline instead of patching the header file to not be __inline__). The other change from me was to change the type for locks to be 32 bits wide instead of 8 bits wide. All Alphas handle 32 bit quantities naturally, but only some can handle 8 or 16 bit quantities. The assembly code tries to do locks with 32 bit quantities, it doesn't make sense to then try to lock an 8 bit quantity. Guys, my patches are not complex. It doesn't take a guru to handle my changes; otherwise I wouldn't have been able to write them. -- Kevin P. Neal http://www.pobox.com/~kpn/ "You know, I think I can hear the machine screaming from here... \ 'help me! hellpp meeee!'" - Heather Flanagan, 14:52:23 Wed Jun 10 1998
I think this had been addressed. > On Mon, Jun 12, 2000 at 05:39:55PM -0400, Tom Lane wrote: > > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > > That was my guess, though his changes were s_lock related. Seems that is > > > an Alpha mess too. > > > > Yes, it sounds like we will need some help from a certified Alpha guru > > to make spinlock code that works reliably on multi-CPU Alphas :-(. > > If you leave the locking code as it is then PostgreSQL will dump core. > > If you do not inline the locking code then the registers will not get > stomped (gcc bug), and PostgreSQL will function properly enough to > initialize itself and make it through a make install. Simple SQL > queries work ok, but I never tried anything fancy. > > I haven't had the time to write up a test case to send to the GCC people. > Plus, the other (much larger) set of patches that a Linux/Alpha guy > wrote up did the same thing my patches did, but differently (-fno-inline > instead of patching the header file to not be __inline__). > > The other change from me was to change the type for locks to be 32 bits > wide instead of 8 bits wide. All Alphas handle 32 bit quantities > naturally, but only some can handle 8 or 16 bit quantities. The assembly > code tries to do locks with 32 bit quantities, it doesn't make sense to > then try to lock an 8 bit quantity. > > > Guys, my patches are not complex. It doesn't take a guru to handle > my changes; otherwise I wouldn't have been able to write them. > -- > Kevin P. Neal http://www.pobox.com/~kpn/ > > "You know, I think I can hear the machine screaming from here... \ > 'help me! hellpp meeee!'" - Heather Flanagan, 14:52:23 Wed Jun 10 1998 > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026