Обсуждение: configure on linux
Last thing when running config: >include/config.h is unchanged >linking ./backend/port/tas/linux.s to backend/port/tas.s >configure: error: ./backend/port/tas/linux.s: File not found It does compile OK, since this file is not used anyway. But it would be confusing to Joe User if it is still there in the release. :-) I am totally ignorant when it comes to autoconf hacking, so.. no patch (Sorry). regards, --------------------------------------------- G�ran Thyni, sysadm, JMS Bildbasen, Kiruna
On 4 Feb 1998, Goran Thyni wrote: > >include/config.h is unchanged > >linking ./backend/port/tas/linux.s to backend/port/tas.s > >configure: error: ./backend/port/tas/linux.s: File not found > > It does compile OK, since this file is not used anyway. > But it would be confusing to Joe User if it is still there > in the release. :-) With the 1998-02-04 snapshot, I see the same problem that Göran sees on NetBSD/sparc, where it looks for a tas/bsd.s to link to. It's building here now, after I put an empty bsd.s where it wanted it and reran configure -- I assume, from Göran's experience, that it's OK. Actually, it would be good to get all tas() assembly implementations out of include/storage/s_lock.h and into genuine .s files like this. With the current way of doing it, the assembly routine has to be "static", because s_lock.h is included several places, which is a bit silly, but a worse consequence is that GCC will inline the assembly code at optimization levels above 2, thus breaking it.. Is this what you're doing, and the reason why the above problem occurred? By the way, I'm running Monday's snapshot on NetBSD/vax now. Small changes only: a couple of changed ifdefs, a couple of Makefile mods and a tas() implementation in four lines of assembly. There are no shared libraries, and no dynamic loading of object modules, but apart from that, it works fine -- regression tests pass and fail in the same pattern as on NetBSD/sparc, with the addition of dynload failures. Is it too late to get the VAX stuff into 6.3? It's really not much, and it would be kinda fun... :-) -tih -- Popularity is the hallmark of mediocrity. --Niles Crane, "Frasier"
On Wed, 4 Feb 1998, Tom I Helbekkmo wrote:
> Actually, it would be good to get all tas() assembly implementations
> out of include/storage/s_lock.h and into genuine .s files like this.
> With the current way of doing it, the assembly routine has to be
> "static", because s_lock.h is included several places, which is a bit
> silly, but a worse consequence is that GCC will inline the assembly
> code at optimization levels above 2, thus breaking it.. Is this what
> you're doing, and the reason why the above problem occurred?
Actually, the problem seems to be configure not quite doing things
as I expect :(
> Is it too late to get the VAX stuff into 6.3? It's really not much,
> and it would be kinda fun... :-)
Ssend in the patch, we'll look it over. If it doesn't go into
v6.3, then we'll have the patch online for v6.4 :)
> > On 4 Feb 1998, Goran Thyni wrote: > > > >include/config.h is unchanged > > >linking ./backend/port/tas/linux.s to backend/port/tas.s > > >configure: error: ./backend/port/tas/linux.s: File not found > > > > It does compile OK, since this file is not used anyway. > > But it would be confusing to Joe User if it is still there > > in the release. :-) > > With the 1998-02-04 snapshot, I see the same problem that G�ran sees > on NetBSD/sparc, where it looks for a tas/bsd.s to link to. It's > building here now, after I put an empty bsd.s where it wanted it and > reran configure -- I assume, from G�ran's experience, that it's OK. > > Actually, it would be good to get all tas() assembly implementations > out of include/storage/s_lock.h and into genuine .s files like this. > With the current way of doing it, the assembly routine has to be > "static", because s_lock.h is included several places, which is a bit > silly, but a worse consequence is that GCC will inline the assembly > code at optimization levels above 2, thus breaking it.. Is this what > you're doing, and the reason why the above problem occurred? Don't break my optimizations. The locking stuff is in *.h files for a reason. They get called thousands of times, and inlining this code has produced a good speedup and they aren't that big. The only case where the inlining of the lock code does not work in on alpha/linux, and I believe it is because the assembler does not support local labels. If this is your problem, there is an s_lock.c file for such cases, but the general case of using s_lock.h and inlining the lock calls is a good strategy. > > By the way, I'm running Monday's snapshot on NetBSD/vax now. Small > changes only: a couple of changed ifdefs, a couple of Makefile mods > and a tas() implementation in four lines of assembly. There are no > shared libraries, and no dynamic loading of object modules, but apart > from that, it works fine -- regression tests pass and fail in the same > pattern as on NetBSD/sparc, with the addition of dynload failures. > > Is it too late to get the VAX stuff into 6.3? It's really not much, > and it would be kinda fun... :-) I certainly think we want those changes. 6.3 beta is the place we expect to be making platform-specific patches. -- Bruce Momjian maillist@candle.pha.pa.us
Bruce Momjian wrote:
> Don't break my optimizations. The locking stuff is in *.h files for a
> reason. They get called thousands of times, and inlining this code has
> produced a good speedup and they aren't that big.
You misunderstand me. I didn't suggest removing the S_LOCK() et al
macros. What I meant was that the actual assembly implementation of
tas() itself might be better off in a separate source file. As an
example, here is my current version of the locking code for the VAX,
in s_lock.h (bbssi is "branch on bit set and set, interlocked"):
static int tas(slock_t *lock) {
register ret;
asm(" clrl r0
bbssi $0,(%1),1f
incl r0
1: movl r0,%0"
: "=r"(ret) /* return value, in register */
: "r"(lock) /* argument, 'lock pointer', in register */
: "r0"); /* assembly code uses this register */
return ret;
}
#define S_LOCK(addr) do { while (!tas(addr)) ; } while (0)
#define S_UNLOCK(addr) (*(addr) = 0)
#define S_INIT_LOCK(addr) (*(addr) = 0)
The inlining of lock handling through the macros is fine, and it all
works great with "gcc -O2". Go to "gcc -O3", however, and GCC will
drop tas() as a function (it's declared static, so it can't be called
from outside the current compilation unit), and inline the given code
wherever tas() was called, which is wherever S_LOCK() is used. This
can actually break it. Specifically, testing the above with a source
file that includes that version of tas() and does
lock = 0;
retv = tas(&lock);
printf("%d %d", lock, retv);
retv = tas(&lock);
printf(" %d %d\n", lock, retv);
will print "1 1 1 0" when compiled with -O2, but "1 1 1 1" with -O3.
I believe this can be fixed by proper use of "__volatile", but I don't
yet have a complete understanding of this. In all probability, you
have to use a pathological case such as this to even produce this
behaviour, though. Still, I would be quite wary of using "-O3" and up
in the presence of static functions with asm() code within them. (I
just checked, and none of the PostgreSQL ports uses higher than "-O2",
so there's no current danger. Heck, I've never seen anything except
operating system kernels be compiled at higher than "-O2".)
About the VAX stuff:
> I certainly think we want those changes. 6.3 beta is the place we
> expect to be making platform-specific patches.
Scrappy sounded positive as well, so I'll send them in -- but not
until tomorrow, when I've had a chance to test the latest version of
them with a fresh snapshot. My aging VAX will be busy installing an
operating system upgrade tonight, but will be free to test tomorrow's
snapshot as soon as it's made available. Once that looks good, I'll
send in diffs.
-tih
--
Popularity is the hallmark of mediocrity. --Niles Crane, "Frasier"
> > Bruce Momjian wrote: > > > Don't break my optimizations. The locking stuff is in *.h files for a > > reason. They get called thousands of times, and inlining this code has > > produced a good speedup and they aren't that big. > > You misunderstand me. I didn't suggest removing the S_LOCK() et al > macros. What I meant was that the actual assembly implementation of > tas() itself might be better off in a separate source file. As an > example, here is my current version of the locking code for the VAX, > in s_lock.h (bbssi is "branch on bit set and set, interlocked"): Yes, I considered static functions, but that is assuming the compiler is going to do something, and we can't really be sure of this. Better to make it a macro, so there is no change of it not being inlined. Also, I don't think asm stuff is re-ordered, so you don't have the 'volatile' problem. -- Bruce Momjian maillist@candle.pha.pa.us
unsubscribe
On Wed, 4 Feb 1998, Bruce Momjian wrote:
> Yes, I considered static functions, but that is assuming the compiler is
> going to do something, and we can't really be sure of this. Better to
> make it a macro, so there is no change of it not being inlined. Also, I
> don't think asm stuff is re-ordered, so you don't have the 'volatile'
> problem.
Good thinking. I think I'll just inline the thing down to this:
#define S_LOCK(addr) asm("1: bbssi $0,(%0),1b": :"r"(addr))
#define S_UNLOCK(addr) (*(addr) = 0)
#define S_INIT_LOCK(addr) (*(addr) = 0)
Dropping this into the (simple) test code I was using, it worked right
at all optimization levels -- but how much can the compiler manage to
screw up for me anyway, when there's just one single instruction? :-)
-tih
--
Popularity is the hallmark of mediocrity. --Niles Crane, "Frasier"
On Wed, 4 Feb 1998, Bruce Momjian wrote:
> I certainly think we want those changes. 6.3 beta is the place we
> expect to be making platform-specific patches.
...and here they are. There are only small modifications, but there
is one that requires a decision to be made: NetBSD/vax does not have
shared libraries, and it thus introduces a situation where a single
"port" has internal differences in this regard. What I've chosen to
do is to add a kludge to Makefile.global, identical in function to the
LINUX_ELF kludge. I think this acceptable -- you may disagree.
Apart from this Makefile hack, all I've done is to make dynamically
loaded code modules fail properly (as was already done for __mips__,
although I think this is too loose: I believe NetBSD for the pmax can
do dynamic linking), and to add test-and-set lock handling. As Bruce
suggested, this is done in a maximally efficient inlined way: I was
not aware that this code was so important, speed-wise.
Oh, and Bruce: I figured out why we talked past each other about the
lock code and inlining: I was looking at the Sparc assembly code in
s_lock.h, since my main platform is NetBSD/sparc, and if you take a
look at that, you'll see that it's _not_ inlined, and not pretty. In
fact, it breaks at -O3 and up by causing linking to fail, when GCC
eliminates the whole tas_dummy() function, since it's static and not
called by anything else. I've tried to figure out how to inline it,
but I don't know enough about the Sparc. Besides, RISC machines were
never meant to be programmed by anything but a computer. :-)
Anyway, this is all it takes to make things work on NetBSD/vax (note
the _single_ instruction used to implement the test-and-set -- it's
only one of _six_ such instructions in this powerful architecture):
*** ./Makefile.global.in.orig Tue Jan 27 09:00:13 1998
--- ./Makefile.global.in Wed Feb 4 11:58:40 1998
***************
*** 48,53 ****
--- 48,58 ----
# compiling to a.out (which means you're using the dld dynamic loading
# library), set LINUX_ELF to null in Makefile.custom.
LINUX_ELF= true
+ #
+ # Ignore BSD_SHLIB if you're not using one of the BSD ports. But if you
+ # are, and it's one that doesn't have shared libraries (NetBSD/vax is an
+ # example of this), set BSD_SHLIB to null in Makefile.custom.
+ BSD_SHLIB= true
LIBPQDIR:= $(SRCDIR)/interfaces/libpq
*** ./backend/port/dynloader/bsd.c.orig Sat Dec 20 01:10:17 1997
--- ./backend/port/dynloader/bsd.c Wed Feb 4 11:58:39 1998
***************
*** 61,67 ****
void *
BSD44_derived_dlopen(const char *file, int num)
{
! #ifdef __mips__
sprintf(error_message, "dlopen (%s) not supported", file);
return NULL;
#else
--- 61,67 ----
void *
BSD44_derived_dlopen(const char *file, int num)
{
! #if defined(__mips__) || (defined(__NetBSD__) && defined(vax))
sprintf(error_message, "dlopen (%s) not supported", file);
return NULL;
#else
***************
*** 78,84 ****
void *
BSD44_derived_dlsym(void *handle, const char *name)
{
! #ifdef __mips__
sprintf(error_message, "dlsym (%s) failed", name);
return NULL;
#else
--- 78,84 ----
void *
BSD44_derived_dlsym(void *handle, const char *name)
{
! #if defined(__mips__) || (defined(__NetBSD__) && defined(vax))
sprintf(error_message, "dlsym (%s) failed", name);
return NULL;
#else
***************
*** 101,107 ****
void
BSD44_derived_dlclose(void *handle)
{
! #ifndef __mips__
dlclose(handle);
#endif
}
--- 101,108 ----
void
BSD44_derived_dlclose(void *handle)
{
! #if defined(__mips__) || (defined(__NetBSD__) && defined(vax))
! #else
dlclose(handle);
#endif
}
*** ./include/port/bsd.h.orig Sat Dec 20 01:11:00 1997
--- ./include/port/bsd.h Wed Feb 4 11:58:39 1998
***************
*** 10,15 ****
--- 10,20 ----
#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
*** ./include/storage/s_lock.h.orig Wed Feb 4 09:00:41 1998
--- ./include/storage/s_lock.h Thu Feb 5 05:37:12 1998
***************
*** 288,293 ****
--- 288,305 ----
#endif /* NEED_SPARC_TAS_ASM */
/*
+ * VAXen -- even multiprocessor ones
+ */
+
+ #if defined(NEED_VAX_TAS_ASM)
+
+ #define S_LOCK(addr) __asm__("1: bbssi $0,(%0),1b": :"r"(addr))
+ #define S_UNLOCK(addr) (*(addr) = 0)
+ #define S_INIT_LOCK(addr) (*(addr) = 0)
+
+ #endif /* NEED_VAX_TAS_ASM */
+
+ /*
* i386 based things
*/
*** ./interfaces/libpgtcl/Makefile.in.orig Fri Jan 23 09:01:01 1998
--- ./interfaces/libpgtcl/Makefile.in Wed Feb 4 11:58:40 1998
***************
*** 42,51 ****
endif
ifeq ($(PORTNAME), bsd)
! install-shlib-dep := install-shlib
! shlib := libpgtcl.so.1.0
! LDFLAGS_SL = -x -Bshareable -Bforcearchive
! CFLAGS += $(CFLAGS_SL)
endif
ifeq ($(PORTNAME), i386_solaris)
--- 42,53 ----
endif
ifeq ($(PORTNAME), bsd)
! ifdef BSD_SHLIB
! install-shlib-dep := install-shlib
! shlib := libpgtcl.so.1.0
! LDFLAGS_SL = -x -Bshareable -Bforcearchive
! CFLAGS += $(CFLAGS_SL)
! endif
endif
ifeq ($(PORTNAME), i386_solaris)
*** ./interfaces/libpq/Makefile.in.orig Mon Jan 26 09:01:30 1998
--- ./interfaces/libpq/Makefile.in Wed Feb 4 11:58:40 1998
***************
*** 43,52 ****
endif
endif
ifeq ($(PORTNAME), bsd)
! install-shlib-dep := install-shlib
! shlib := libpq.so.$(SO_MAJOR_VERSION).$(SO_MINOR_VERSION)
! LDFLAGS_SL = -x -Bshareable -Bforcearchive
! CFLAGS += $(CFLAGS_SL)
endif
ifeq ($(PORTNAME), i386_solaris)
install-shlib-dep := install-shlib
--- 43,54 ----
endif
endif
ifeq ($(PORTNAME), bsd)
! ifdef BSD_SHLIB
! install-shlib-dep := install-shlib
! shlib := libpq.so.$(SO_MAJOR_VERSION).$(SO_MINOR_VERSION)
! LDFLAGS_SL = -x -Bshareable -Bforcearchive
! CFLAGS += $(CFLAGS_SL)
! endif
endif
ifeq ($(PORTNAME), i386_solaris)
install-shlib-dep := install-shlib
-tih
--
Popularity is the hallmark of mediocrity. --Niles Crane, "Frasier"
> Oh, and Bruce: I figured out why we talked past each other about the > lock code and inlining: I was looking at the Sparc assembly code in > s_lock.h, since my main platform is NetBSD/sparc, and if you take a > look at that, you'll see that it's _not_ inlined, and not pretty. In > fact, it breaks at -O3 and up by causing linking to fail, when GCC > eliminates the whole tas_dummy() function, since it's static and not > called by anything else. I've tried to figure out how to inline it, > but I don't know enough about the Sparc. Besides, RISC machines were > never meant to be programmed by anything but a computer. :-) I have no idea what this tas_dummy does. On those architectures that have tas(), we call it directly. I think we would be better off inlining the call, but no one has given us asm code to do it. Now, it would be nice if the system includes would define tas() as a macro, but I don't know any that do. The locking stuff gets called many, many times, and they are usually very small routines, so the inlining is a big win for us. > > Anyway, this is all it takes to make things work on NetBSD/vax (note > the _single_ instruction used to implement the test-and-set -- it's > only one of _six_ such instructions in this powerful architecture): -- Bruce Momjian maillist@candle.pha.pa.us
Patch is applied and committed...
On Fri, 6 Feb 1998, Tom I Helbekkmo wrote:
> On Wed, 4 Feb 1998, Bruce Momjian wrote:
>
> > I certainly think we want those changes. 6.3 beta is the place we
> > expect to be making platform-specific patches.
>
> ...and here they are. There are only small modifications, but there
> is one that requires a decision to be made: NetBSD/vax does not have
> shared libraries, and it thus introduces a situation where a single
> "port" has internal differences in this regard. What I've chosen to
> do is to add a kludge to Makefile.global, identical in function to the
> LINUX_ELF kludge. I think this acceptable -- you may disagree.
>
> Apart from this Makefile hack, all I've done is to make dynamically
> loaded code modules fail properly (as was already done for __mips__,
> although I think this is too loose: I believe NetBSD for the pmax can
> do dynamic linking), and to add test-and-set lock handling. As Bruce
> suggested, this is done in a maximally efficient inlined way: I was
> not aware that this code was so important, speed-wise.
>
> Oh, and Bruce: I figured out why we talked past each other about the
> lock code and inlining: I was looking at the Sparc assembly code in
> s_lock.h, since my main platform is NetBSD/sparc, and if you take a
> look at that, you'll see that it's _not_ inlined, and not pretty. In
> fact, it breaks at -O3 and up by causing linking to fail, when GCC
> eliminates the whole tas_dummy() function, since it's static and not
> called by anything else. I've tried to figure out how to inline it,
> but I don't know enough about the Sparc. Besides, RISC machines were
> never meant to be programmed by anything but a computer. :-)
>
> Anyway, this is all it takes to make things work on NetBSD/vax (note
> the _single_ instruction used to implement the test-and-set -- it's
> only one of _six_ such instructions in this powerful architecture):
>
Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org