Re: [HACKERS] S_LOCK() change produces error... - Mailing list pgsql-hackers

From The Hermit Hacker
Subject Re: [HACKERS] S_LOCK() change produces error...
Date
Msg-id Pine.NEB.3.96.980117230220.259I-100000@thelab.hub.org
Whole thread Raw
In response to Re: [HACKERS] S_LOCK() change produces error...  (Bruce Momjian <maillist@candle.pha.pa.us>)
Responses Re: [HACKERS] S_LOCK() change produces error...  (Bruce Momjian <maillist@candle.pha.pa.us>)
Re: [HACKERS] S_LOCK() change produces error...  (teunis <teunis@mauve.computersupportcentre.com>)
List pgsql-hackers
On Sat, 17 Jan 1998, Bruce Momjian wrote:

> >
> >
> > I installed some patches today for the univel port, and one of the changes
> > did the following to include/storage/s_lock.h:
> >
> > 302c318
> > <                               __asm__("xchgb %0,%1": "=q"(_res), "=m"(*lock):"0"(0x1)); \
> > ---
> > >                               __asm__("lock xchgb %0,%1": "=q"(_res), "=m"(*lock):"0"(0x1)); \
> >
>
> I guess this is a multiple cpu modifier for asm, and most people don't
> run multiple cpus.  I guess our gcc's call it an error, rather than
> ignore it.  I think we need an OS-specific ifdef there.  We can't have
> Univel changing the normal i386 stuff that works so well now.

    Actually, I think that the patch was meant to improve...if you look at the
code, he put all the Univel stuff inside of its own #ifdef...see around
line 297 in include/storage/s_lock.h and you'll see what I mean.

    He seems to have only added a 'lock' to the beginning of the __asm__,
which is what is breaking things under FreeBSD, but unless it affects every
other port, I'm loath to remove it without just throwing in a FreeBSD #ifdef
in there...

Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org           secondary: scrappy@{freebsd|postgresql}.org


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: [HACKERS] Re: [QUESTIONS] Business cases
Next
From: "Micha3 Mosiewicz"
Date:
Subject: Re: [HACKERS] Re: New pg_pwd patch and stuff