Patch for m68k architecture

Applied. You man want to give us a fix for /template/.similar for that
platform, if needed to configure guesses the proper platform.

This patch should enable 6.5 to build on Motorola 68000 architecture. It comes
from Roman Hodek <Roman.Hodek@informatik.uni-erlangen.de>.

Content-Description: ol

[Attachment, skipping...]

Vote against SPAM: http://www.politik-digital.de/spam/
========================================
Oliver Elphick Oliver.Elphick@lfix.co.uk
Isle of Wight http://www.lfix.co.uk/oliver
PGP key from public servers; key ID 32B8FAA1
========================================
"I love them that love me; and those that seek me early
shall find me." Proverbs 8:17

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@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

Applied. You man want to give us a fix for /template/.similar for that
platform, if needed to configure guesses the proper platform.

This patch should enable 6.5 to build on Motorola 68000 architecture. It comes
from Roman Hodek <Roman.Hodek@informatik.uni-erlangen.de>.

Content-Description: ol

OK, I have a big question on this. The template/linux_m68k uses
CFLAGS:-O2. Now, with egcs, which I think the person using, this -O2
causes some problems with the function pointers we call. It is a known
problem.

Can you please test with -O instead, and see if the fmgr_ptr change made
to postgres.h is needed in this case?

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@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

At 8:29 AM -0700 6/10/99, Oliver Elphick wrote:

This patch should enable 6.5 to build on Motorola 68000 architecture. It
comes
from Roman Hodek <Roman.Hodek@informatik.uni-erlangen.de>.

Has anyone compared the Linux/m68k patch with the NetBSD/m68k patch (which
I believe was already included in 6.5)?

Also I have been trying to cross-post some traffic on the
port-mac68k@NetBSD.org list to the PG-ports list and it hasn't been
appearing afaict. Am I just not looking carefully enough or is something
screwy?

Signature failed Preliminary Design Review.
Feasibility of a new signature is currently being evaluated.
h.b.hotz@jpl.nasa.gov, or hbhotz@oxy.edu

At 8:29 AM -0700 6/10/99, Oliver Elphick wrote:

This patch should enable 6.5 to build on Motorola 68000 architecture. It
comes
from Roman Hodek <Roman.Hodek@informatik.uni-erlangen.de>.

Has anyone compared the Linux/m68k patch with the NetBSD/m68k patch (which
I believe was already included in 6.5)?

yes.

Also I have been trying to cross-post some traffic on the
port-mac68k@NetBSD.org list to the PG-ports list and it hasn't been
appearing afaict. Am I just not looking carefully enough or is something
screwy?

I have tried 6.4beta4 on NetBSD 1.3.3/m68k. It failed while running
initdb:

Creating template database in /usr/local/pgsql/data/base/template1

FATAL: s_lock(001bbea3) at bufmgr.c:1992, stuck spinlock. Aborting.

FATAL: s_lock(001bbea3) at bufmgr.c:1992, stuck spinlock. Aborting.

Seems something really bad is going on...
--
Tatsuo Ishii

At 8:29 AM -0700 6/10/99, Oliver Elphick wrote:

This patch should enable 6.5 to build on Motorola 68000 architecture. It
comes
from Roman Hodek <Roman.Hodek@informatik.uni-erlangen.de>.

Has anyone compared the Linux/m68k patch with the NetBSD/m68k patch (which
I believe was already included in 6.5)?

yes.

Also I have been trying to cross-post some traffic on the
port-mac68k@NetBSD.org list to the PG-ports list and it hasn't been
appearing afaict. Am I just not looking carefully enough or is something
screwy?

I have tried 6.4beta4 on NetBSD 1.3.3/m68k. It failed while running
initdb:

Creating template database in /usr/local/pgsql/data/base/template1

FATAL: s_lock(001bbea3) at bufmgr.c:1992, stuck spinlock. Aborting.

FATAL: s_lock(001bbea3) at bufmgr.c:1992, stuck spinlock. Aborting.

Seems something really bad is going on...

I reverted back the patch for include/storage/s_lock.h and seems
NetBSD/m68k port begins to work again.

I think we should revert back the linux/m68k patches and leave them
for 6.5.1. Objection?
--
Tatsuo Ishii

Tatsuo Ishii wrote:

At 8:29 AM -0700 6/10/99, Oliver Elphick wrote:

This patch should enable 6.5 to build on Motorola 68000 architecture.

...

Seems something really bad is going on...

I reverted back the patch for include/storage/s_lock.h and seems
NetBSD/m68k port begins to work again.

I think we should revert back the linux/m68k patches and leave them
for 6.5.1. Objection?

That seems sensible; presumably no other current users are on linux_m68k
or this would have been sorted already. I will keep it in the Debian
version where there can't be any conflict with NetBSD users.

It seems that the patch needs to depend not only on being m68k but also
on being linux. What defined variable can we use to distinguish between
the two?

--
Vote against SPAM: http://www.politik-digital.de/spam/
========================================
Oliver Elphick Oliver.Elphick@lfix.co.uk
Isle of Wight http://www.lfix.co.uk/oliver
PGP key from public servers; key ID 32B8FAA1
========================================
"And he said unto Jesus, Lord, remember me when thou
comest into thy kingdom. And Jesus said unto him,
Verily I say unto thee, To day shalt thou be with me
in paradise." Luke 23:42,43

I reverted back the patch for include/storage/s_lock.h and seems
NetBSD/m68k port begins to work again.

I think we should revert back the linux/m68k patches and leave them
for 6.5.1. Objection?

That seems sensible; presumably no other current users are on linux_m68k
or this would have been sorted already. I will keep it in the Debian
version where there can't be any conflict with NetBSD users.

It seems that the patch needs to depend not only on being m68k but also
on being linux. What defined variable can we use to distinguish between
the two?

I have changed
#if defined(__mc68000__)
to:
#if defined(__mc68000__) && defined(__linux__)
in s_lock.h.
--
Tatsuo Ishii

At 1:47 AM -0700 6/12/99, Tatsuo Ishii wrote:

I have tried 6.4beta4 on NetBSD 1.3.3/m68k. It failed while running
initdb:

Creating template database in /usr/local/pgsql/data/base/template1

FATAL: s_lock(001bbea3) at bufmgr.c:1992, stuck spinlock. Aborting.

FATAL: s_lock(001bbea3) at bufmgr.c:1992, stuck spinlock. Aborting.

Seems something really bad is going on...

That certainly seems bad enough, but I did not see that problem. Are you
talking about way back when 6.4 was still in beta? Or did you mean 6.5?

As I tried to post earlier: when I built 6.4.2 using the patches it built
fine and initdb worked. Most regression tests seemed ok-ish, but one of
them noticed that 'now' - 'current' was more than 200 days.

I had a problem building 6.5, but I think it was related to my
configuration rather than to Postgres.

Signature failed Preliminary Design Review.
Feasibility of a new signature is currently being evaluated.
h.b.hotz@jpl.nasa.gov, or hbhotz@oxy.edu

At 8:39 AM -0700 6/12/99, Tatsuo Ishii wrote:

I reverted back the patch for include/storage/s_lock.h and seems
NetBSD/m68k port begins to work again.

I think we should revert back the linux/m68k patches and leave them
for 6.5.1. Objection?

I would like to support linux/m68k, but on the Mac 68K platform the NetBSD
folks are more numerous. Unless linux outnumbers NetBSD on some 68k
platforms other than Mac (and I think Amiga) I don't think you should break
a (mostly) working port in order to support a less widely used one.

Just my $0.02.

Signature failed Preliminary Design Review.
Feasibility of a new signature is currently being evaluated.
h.b.hotz@jpl.nasa.gov, or hbhotz@oxy.edu

I reverted back the patch for include/storage/s_lock.h and seems
NetBSD/m68k port begins to work again.

I think we should revert back the linux/m68k patches and leave them
for 6.5.1. Objection?

I would like to support linux/m68k, but on the Mac 68K platform the NetBSD
folks are more numerous. Unless linux outnumbers NetBSD on some 68k
platforms other than Mac (and I think Amiga) I don't think you should break
a (mostly) working port in order to support a less widely used one.

I think the change I made in s_lock.h should make both NetBSD/m68k and
Linux/m68k happy. Can some Linux/m68k folks confirm it?
--
Tatsuo Ishii

The change was:
#if defined(__mc68000__)
to:
#if defined(__mc68000__) && defined(__linux__)
in s_lock.h.

I think the change I made in s_lock.h should make both NetBSD/m68k
and Linux/m68k happy. Can some Linux/m68k folks confirm it?

Sure, this can't cause any trouble on Linux/m68k.

Roman

Hi Bruce!

I have already asked for you to try a change to template/linux_m68k
by changing the optimization -O2 to -O and see if you still need the
postgres.h fmgr_ptr change you did. I assume you are using egcs, right?

Can't remember that you asked me... But anyway, it wouldn't help. It's
defined in the SysV/m68k ABI that %d0 is used for scalar return values
and %a0 for pointer values. Both gcc and egcs do it like this, and
it's also independent from optimization level. (And, BTW, I didn't use
egcs.)

This behaviour is one of the most prominent porting problems to m68k.
ANSI C says results are undefined if you call a function via pointer
and the pointer is declared to return another type than the function
actually returns. So m68k compilers conform to the standard here.
However, most programmers never expect such problems... also because
on most architectures it works without probs, because all values are
returned in the same register.

Yes, we admit that we break the standard with fmgr_ptr, because we
return a variety of values depending on what function they call. It
appears the egcs optimization on the powerpc or alpha cause a problem
when optimization is -O2, but not -O. We may see more platforms with
problems as optimizers get smarter.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@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

Hi Bruce!

Yes, we admit that we break the standard with fmgr_ptr, because we
return a variety of values depending on what function they call.

Yep... the correct thing would be to cast all such return values to a
common type (e.g. long) and cast them back in the caller.

It appears the egcs optimization on the powerpc or alpha cause a
problem when optimization is -O2, but not -O.

Can be like this on those archs. On m68k, however, the registers for
function return values are the same independent of optimization level.

We may see more platforms with problems as optimizers get smarter.

Yep...

Roman