freebsd-sparc-digest V5 #214
owner-freebsd...@freebsd.org
freebsd-sparc-digest Sunday, January 12 2003 Volume 05 : Number 214
In this issue:
Re: Do we want this added to the docs
panic: trap: fast data access mmu miss
Re: panic: trap: fast data access mmu miss
fpsetmask on sparc64
Re: fpsetmask on sparc64
Re: fpsetmask on sparc64
Re: fpsetmask on sparc64
Re: fpsetmask on sparc64
Re: fpsetmask on sparc64
Re: fpsetmask on sparc64
Re: fpsetmask on sparc64
Re: fpsetmask on sparc64
Re: fpsetmask on sparc64
Re: fpsetmask on sparc64
Re: fpsetmask on sparc64
Re: fpsetmask on sparc64
RE: panic: trap: fast data access mmu miss
Re: fpsetmask on sparc64
compiling postgresql7 failed
RE: compiling postgresql7 failed
Question about odd stack pointer values on sparc64
Re: fpsetmask on sparc64
Re: Question about odd stack pointer values on sparc64
----------------------------------------------------------------------
Date: Sat, 11 Jan 2003 16:13:47 -0500
From: Jake Burkholder <ja...@locore.ca>
Subject: Re: Do we want this added to the docs
Apparently, On Sat, Jan 11, 2003 at 12:51:52PM -0800,
David O'Brien said words to the effect of;
> I'm not sure where I got this from.
There was a description of all the machines in the proc-sparc64.sgml before.
I'd rather just have a list of systems and point people to sunsolve for
specifics, there's not much point in duplicating it and there may be a lot
of systems. So no, I'd rather not do this.
Jake
>
> --- proc-sparc64.sgml Sat Jan 11 12:46:55 2003
> +++ proc-sparc64.sgml.new Sat Jan 11 12:47:35 2003
> @@ -116,6 +116,88 @@
> sufficient onboard devices to make &os; generally useful.</para>
>
> <itemizedlist>
> + <listitem><para>1 or 2 UltraSPARC II CPUs</para></listitem>
> + <listitem><para>Built-in Ethernet
> + (<devicename>hme</devicename> compatible)
> + interface</para></listitem>
> + <listitem><para>4 SBus slots</para></listitem>
> + <listitem><para>1 UPA Slot</para></listitem>
> + <listitem><para>Serial and Parallel ports</para></listitem>
> + <listitem><para>16-bit audio</para></listitem>
> + </itemizedlist>
> + </sect3>
> +
> + <sect3>
> + <title>Ultra 5/10</title>
> +
> + <para>UltraSPARC Ultra5/10-family systems include the following
> + hardware:</para>
> +
> + <itemizedlist>
> + <listitem><para>UltraSPARC IIi CPU</para></listitem>
> + <listitem><para>Three PCI busses</para></listitem>
> + <listitem><para>Built-in Ethernet
> + (<devicename>hme</devicename> compatible)
> + interface</para></listitem>
> + <listitem><para>Built-in PCI-IDE controller</para></listitem>
> + <listitem><para>Two PC-AT style `com' ports for the mouse and keyboard</para></listitem>
> + <listitem><para>Floppy driver controller</para></listitem>
> + <listitem><para>Siemens SAB82532 dual-channel serial ports for ttya and ttyb</para></listitem>
> + <listitem><para>One CS4231 audio device</para></listitem>
> + <listitem><para>One PC-AT style parallel port</para></listitem>
> + <listitem><para>Sun `ffb' frame buffer (Ultra10 only)</para></listitem>
> + <listitem><para>EBus (Sun proprietary bus for slow
> + devices)</para></listitem>
> + </itemizedlist>
> + </sect3>
> +
> + <sect3>
> + <title>Ultra 60</title>
> +
> + <para>Sun Ultra 60 workstations include the following hardware:</para>
> +
> + <itemizedlist>
> + <listitem><para>1 or 2 UltraSPARC II CPUs</para></listitem>
> + <listitem><para>4 PCI slots</para></listitem>
> + <listitem><para>2 UPA slots</para></listitem>
> + <listitem><para>&man.sym.4;-based UltraSCSI
> + controller</para></listitem>
> + <listitem><para>Built-in Ethernet
> + (<devicename>hme</devicename> compatible)
> + interface</para></listitem>
> + <listitem><para>Serial and Parallel ports</para></listitem>
> + <listitem><para>16-bit audio</para></listitem>
> + <listitem><para>EBus (Sun proprietary bus for slow
> + devices)</para></listitem>
> + </itemizedlist>
> + </sect3>
> +
> + <sect3>
> + <title>Blade 100</title>
> +
> + <para>Sun Blade 100 workstations include the following hardware:</para>
> +
> + <itemizedlist>
> + <listitem><para>UltraSPARC IIe CPU</para></listitem>
> + <listitem><para>Three PCI busses</para></listitem>
> + <listitem><para>Built-in Ethernet
> + (<devicename>gem</devicename> compatible)
> + interface</para></listitem>
> + <listitem><para>Two USB ports &unsupported;</para></listitem>
> + <listitem><para>Two Firewire ports &unsupported;</para></listitem>
> + <listitem><para>Built-in PCI-IDE controller</para></listitem>
> + <listitem><para>Two PC-AT style `com' ports for the mouse and keyboard</para></listitem>
> + <listitem><para>Floppy driver controller</para></listitem>
> + <listitem><para>&man.sio.4; supported serial ports for ttya
> + and ttyb</para></listitem>
> + <listitem><para>One CS4231 audio device</para></listitem>
> + <listitem><para>One PC-AT style parallel port</para></listitem>
> + <listitem><para>Built-in PGX64 (ATI)
> + graphics</para></listitem>
> + <listitem><para>EBus (Sun proprietary bus for slow
> + devices)</para></listitem>
> + <listitem><para>ISA bus</para></listitem>
> +
> <listitem>
> <para>All systems containing UltraSPARC III processor(s).</para>
> </listitem>
>
> To Unsubscribe: send mail to majo...@FreeBSD.org
> with "unsubscribe freebsd-sparc" in the body of the message
------------------------------
Date: Sun, 12 Jan 2003 00:41:44 +0100
From: "Roderick van Domburg" <r.s.a.va...@student.utwente.nl>
Subject: panic: trap: fast data access mmu miss
Running on a Sun Enterprise 250 with a single UltraSparc-II CPU, 512 MB RAM
and three Fujitsu SCSI-II hard disks. I've had this same problem with
sources over the past few (three?) days. I had to copy this dmesg by hand,
so please bear with any possible typos.
- --8<------
picb1: <PCI-PCI bridge> at device 2.0 on pci0
pci1: <PCI bus> on pcib1
isp0: <Qlogic ISP 1020/1040 PCI SCSI Adapter> port 0x1000-0x10ff mem
0x4008000-0x4008fff irq 16 at device 4.0 on pci1
isp0: invalid NVRAM header
sym0: <875> port 0x2000-0x20ff mem 0x410a000-0x410afff,0x4108000-0x41080ff
irq 32 at device 3.0 on pci0
sym0: No NVRAM, ID 7, Fast-20, SE, parity checking
sym1: <875> port 0x2400-0x24ff mem 0x410e000-0x410efff,0x410c000-0x410c0ff
irq 38 at device 3.1 on pci0
panic: trap: fast data access mmu miss
cpuid = 0;
Debugger("panic")
Stopped at Debugger+0x1c: ta %xcc, 1
db> trace
panic() at panic+0x134
trap() at trap+0x414
- -- fast data access mmu miss tar=0 %o7=0xc0248c00 --
getbaddrcb() at getbaddrcb
psycho_dmamap_load() at psycho_dmamap_load+0x30
___dma_getp() at ___dma_getp+0xb8
___sym_malloc() at ___sym_malloc+0x70
__sym_calloc2() at __sym_calloc2+0xc
__sym_calloc_dma() at __sym_calloc_dma+0x64
sym_pci_attach() at sym_pci_attach+0x38
device_probe_and_attach at device_probe_and_attach+0xb8
bus_generic_attach() at bus_generic_attach+0x10
pci_attach() at pci_attach+0x9c
device_probe_and_attach at device_probe_and_attach+0xb8
bus_generic_attach() at bus_generic_attach+0x10
psycho_attach() at psycho_attach+0x9d8
device_probe_and_attach at device_probe_and_attach+0xb8
bus_generic_attach() at bus_generic_attach+0x10
device_probe_and_attach at device_probe_and_attach+0xb8
root_bus_configure() at root_bus_configure+0x18
configure() at configure+0x20
mi_startup() at mi_startup+0x12c
btext() at btext+0x30
db>
------------------------------
Date: Sun, 12 Jan 2003 02:09:50 +0100
From: Thomas Moestl <tmo...@gmx.net>
Subject: Re: panic: trap: fast data access mmu miss
- --UlVJffcvxoiEqYs2
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
On Sun, 2003/01/12 at 00:41:44 +0100, Roderick van Domburg wrote:
> Running on a Sun Enterprise 250 with a single UltraSparc-II CPU, 512 MB RAM
> and three Fujitsu SCSI-II hard disks. I've had this same problem with
> sources over the past few (three?) days. I had to copy this dmesg by hand,
> so please bear with any possible typos.
Please try the attached diff. The crash was due to what I consider a
driver bug (not checking the error in the bus_dmamap_load() callback),
however due to the FreeBSD busdma API being largely undocumented it is
a bit difficult to tell what should be considered legal. Much more
problematic is to assume that the first segment's bus address will be
0 in the error case. This is not currently guaranteed by any
implementation.
The attached patch fixes that, and also passes a valid pointer to the
callback for maximum compatability. It also fixes some other bugs I
came across.
This does however still not address the reason for the
bus_dmamap_load() failure; I'm not really sure why this does
happen. Please look for messages like:
__sym_calloc2: failed to allocate ...
and tell me if you see any of them.
- Thomas
- --
Thomas Moestl <tmo...@gmx.net> http://www.tu-bs.de/~y0015675/
<t...@FreeBSD.org> http://people.FreeBSD.org/~tmm/
PGP fingerprint: 1C97 A604 2BD0 E492 51D0 9C0F 1FE6 4F1D 419C 776C
- --UlVJffcvxoiEqYs2
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="iommu-errbd.diff"
Index: dev/sym/sym_hipd.c
===================================================================
RCS file: /ncvs/src/sys/dev/sym/sym_hipd.c,v
retrieving revision 1.38
diff -u -r1.38 sym_hipd.c
- --- dev/sym/sym_hipd.c 1 Jan 2003 18:48:52 -0000 1.38
+++ dev/sym/sym_hipd.c 12 Jan 2003 01:05:21 -0000
@@ -712,7 +712,10 @@
{
bus_addr_t *baddr;
baddr = (bus_addr_t *)arg;
- - *baddr = segs->ds_addr;
+ if (error != 0)
+ *baddr = 0;
+ else
+ *baddr = segs->ds_addr;
}
static m_addr_t ___dma_getp(m_pool_s *mp)
@@ -728,8 +731,9 @@
if (bus_dmamem_alloc(mp->dmat, &vaddr,
BUS_DMA_NOWAIT, &vbp->dmamap))
goto out_err;
- - bus_dmamap_load(mp->dmat, vbp->dmamap, vaddr,
- - MEMO_CLUSTER_SIZE, getbaddrcb, &baddr, 0);
+ if (bus_dmamap_load(mp->dmat, vbp->dmamap, vaddr,
+ MEMO_CLUSTER_SIZE, getbaddrcb, &baddr, 0))
+ goto out_err;
if (baddr) {
int hc = VTOB_HASH_CODE(vaddr);
vbp->vaddr = (m_addr_t) vaddr;
@@ -744,8 +748,6 @@
bus_dmamap_unload(mp->dmat, vbp->dmamap);
if (vaddr)
bus_dmamem_free(mp->dmat, vaddr, vbp->dmamap);
- - if (vbp->dmamap)
- - bus_dmamap_destroy(mp->dmat, vbp->dmamap);
if (vbp)
__sym_mfree(&mp0, vbp, sizeof(*vbp), "VTOB");
return 0;
Index: sparc64/sparc64/iommu.c
===================================================================
RCS file: /ncvs/src/sys/sparc64/sparc64/iommu.c,v
retrieving revision 1.14
diff -u -r1.14 iommu.c
- --- sparc64/sparc64/iommu.c 6 Jan 2003 21:59:54 -0000 1.14
+++ sparc64/sparc64/iommu.c 12 Jan 2003 00:58:39 -0000
@@ -517,7 +517,7 @@
{
struct resource *res;
struct bus_dmamap_res *bdr;
- - bus_size_t align, bound, sgsize;
+ bus_size_t align, sgsize;
if ((bdr = malloc(sizeof(*bdr), M_IOMMU, M_NOWAIT)) == NULL)
return (EAGAIN);
@@ -531,9 +531,8 @@
sgsize = round_io_page(size) >> IO_PAGE_SHIFT;
if (t->dt_boundary > 0 && t->dt_boundary < IO_PAGE_SIZE)
panic("iommu_dvmamap_load: illegal boundary specified");
- - bound = ulmax(t->dt_boundary >> IO_PAGE_SHIFT, 1);
res = rman_reserve_resource_bound(&iommu_dvma_rman, 0L,
- - t->dt_lowaddr, sgsize, bound >> IO_PAGE_SHIFT,
+ t->dt_lowaddr, sgsize, t->dt_boundary >> IO_PAGE_SHIFT,
RF_ACTIVE | rman_make_alignment_flags(align), NULL);
if (res == NULL)
return (ENOMEM);
@@ -860,7 +859,7 @@
if (error != 0) {
iommu_dvmamap_vunload(is, map);
- - (*cb)(cba, NULL, 0, error);
+ (*cb)(cba, sgs, 0, error);
} else {
/* Move the map to the end of the LRU queue. */
iommu_map_insq(map);
Index: kern/subr_rman.c
===================================================================
RCS file: /ncvs/src/sys/kern/subr_rman.c,v
retrieving revision 1.27
diff -u -r1.27 subr_rman.c
- --- kern/subr_rman.c 27 Nov 2002 03:55:22 -0000 1.27
+++ kern/subr_rman.c 12 Jan 2003 00:43:52 -0000
@@ -229,7 +229,7 @@
*/
do {
rstart = (rstart + amask) & ~amask;
- - if (((rstart ^ (rstart + count)) & bmask) != 0)
+ if (((rstart ^ (rstart + count - 1)) & bmask) != 0)
rstart += bound - (rstart & ~bmask);
} while ((rstart & amask) != 0 && rstart < end &&
rstart < s->r_end);
- --UlVJffcvxoiEqYs2--
------------------------------
Date: Sat, 11 Jan 2003 19:16:26 -0800
From: Kris Kennaway <kr...@obsecurity.org>
Subject: fpsetmask on sparc64
- --17pEHd4RhPHOinZp
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
fpsetmask is not defined in <floatingpoint.h> or
<machine/floatingpoint.h> on sparc64 (it is on i386):
/usr/include/machine/floatingpoint.h:#define fpsetmask(m) ((fp_except=
_t) \
/usr/include/ieeefp.h:extern fp_except_t fpsetmask(fp_except_t);
/usr/include/floatingpoint.h:#define fpsetmask(m) ((fp_except_t) =
=20
This appears to cause the following port failures/warnings:
amphetamine-0.8.10.log:src/Main.cpp:79: `fpsetmask' undeclared (first use t=
his function)
glasteroids-1.0.log:Glasteroids.cxx:82: `fpsetmask' undeclared (first use t=
his function)
lame-devel-3.89b.log:util.c:883: warning: implicit declaration of function =
`fpsetmask'
smalltalk-2.0.8.log:lex.c:814: warning: implicit declaration of function `f=
psetmask'
xmrm-2.0_2.log:morphvec.cc:439: `fpsetmask' undeclared (first use this func=
tion)
Is this an omission, or are the ports wrong?
Kris
- --17pEHd4RhPHOinZp
Content-Type: application/pgp-signature
Content-Disposition: inline
- -----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (FreeBSD)
iD8DBQE+IN4KWry0BWjoQKURAnuDAJwMi0LF+NqdNYHZgrAYK+2xAqLPQACfeKhK
LL8XICSiJnCJBaQRYz4m9aA=
=PfOU
- -----END PGP SIGNATURE-----
- --17pEHd4RhPHOinZp--
------------------------------
Date: Sat, 11 Jan 2003 20:47:20 -0800
From: Kris Kennaway <kr...@obsecurity.org>
Subject: Re: fpsetmask on sparc64
- --WIyZ46R2i8wDzkSu
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Sat, Jan 11, 2003 at 07:16:26PM -0800, Kris Kennaway wrote:
> fpsetmask is not defined in <floatingpoint.h> or
> <machine/floatingpoint.h> on sparc64 (it is on i386):
>=20
> /usr/include/machine/floatingpoint.h:#define fpsetmask(m) ((fp_exce=
pt_t) \
> /usr/include/ieeefp.h:extern fp_except_t fpsetmask(fp_except_t);
> /usr/include/floatingpoint.h:#define fpsetmask(m) ((fp_except_t) =
=20
>=20
> This appears to cause the following port failures/warnings:
>=20
> amphetamine-0.8.10.log:src/Main.cpp:79: `fpsetmask' undeclared (first use=
this function)
> glasteroids-1.0.log:Glasteroids.cxx:82: `fpsetmask' undeclared (first use=
this function)
> lame-devel-3.89b.log:util.c:883: warning: implicit declaration of functio=
n `fpsetmask'
> smalltalk-2.0.8.log:lex.c:814: warning: implicit declaration of function =
`fpsetmask'
> xmrm-2.0_2.log:morphvec.cc:439: `fpsetmask' undeclared (first use this fu=
nction)
>=20
> Is this an omission, or are the ports wrong?
Here's another FP-related failure:
http://bento.freebsd.org/errorlogs/sparc64-5-latest/xaos-3.0.log
FP_X_DNML is defined on i386 in /usr/include/machine/ieeefp.h, but not
on sparc64.
Kris
- --WIyZ46R2i8wDzkSu
Content-Type: application/pgp-signature
Content-Disposition: inline
- -----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (FreeBSD)
iD8DBQE+IPNYWry0BWjoQKURAkSbAKDYFIJRcSo2f0X0bJMsVyBLozYrdQCgp5sc
EGtX2Yx7Zcg6xeKki4wKyT4=
=19Aa
- -----END PGP SIGNATURE-----
- --WIyZ46R2i8wDzkSu--
------------------------------
Date: Sat, 11 Jan 2003 20:40:44 -0800
From: Terry Lambert <tlam...@mindspring.com>
Subject: Re: fpsetmask on sparc64
Kris Kennaway wrote:
> fpsetmask is not defined in <floatingpoint.h> or
> <machine/floatingpoint.h> on sparc64 (it is on i386):
[ ... ]
> Is this an omission, or are the ports wrong?
An OS abstracts the differences in underlying hardware, for the
benefit of the software it hosts. If there is code that compiles
on FreeBSD for one platform, and does not compile on FreeBSD for
another, either the code is hardware-specific, or the OS is not
doing its job.
In this case, I believe the OS is not doing its job, according to
POSIX.
- -- Terry
------------------------------
Date: Sun, 12 Jan 2003 17:29:04 +1100 (EST)
From: Bruce Evans <b...@zeta.org.au>
Subject: Re: fpsetmask on sparc64
On Sat, 11 Jan 2003, Kris Kennaway wrote:
> fpsetmask is not defined in <floatingpoint.h> or
> <machine/floatingpoint.h> on sparc64 (it is on i386):
>
> /usr/include/machine/floatingpoint.h:#define fpsetmask(m) ((fp_except_t) \
> /usr/include/ieeefp.h:extern fp_except_t fpsetmask(fp_except_t);
> /usr/include/floatingpoint.h:#define fpsetmask(m) ((fp_except_t)
>
> This appears to cause the following port failures/warnings:
>
> amphetamine-0.8.10.log:src/Main.cpp:79: `fpsetmask' undeclared (first use this function)
> ...
> Is this an omission, or are the ports wrong?
First answer:
This is a bug in the ports. The non-i386 arches are apparently including
<machine/floatingpoint.h> instead of the documented interface <ieeefp.h>.
I think the ports are only meddling the FP mask to hide their FP errors
when running under FreeBSD-3.x and earlier anyway. They would have
to use <machine/floatingpoint.h> to suppport FreeBSD-2.x since <ieeefp.h>
didn't exist until FreeBSD-3.1. FreeBSD-4.0 and later hide FP errors
by default.
Second answer:
Ports should use the C99 interfaces fe{get,set}*() from <fenv.h>, and then
only if C99 is supported. There might be problems with this too:
- - C99 isn't supported yet.
- - C99 doesn't have fesetmask(). This is partly because it would be
very unportable. It is not an IEEE FP feature. C99 only has
fesetenv(FE_DFL_ENV) to recover from any meddling with the FP
environment.
- - Non-default FP environments should only be used in small sections
of code, since large parts of libraries, etc. are entitled to assume
that the environment is the default. So changing the FP mask to a
non-default value at program startup time would give undefined
behaviour if it were possible.
Bruce
------------------------------
Date: Sun, 12 Jan 2003 17:37:17 +1100 (EST)
From: Bruce Evans <b...@zeta.org.au>
Subject: Re: fpsetmask on sparc64
On Sat, 11 Jan 2003, Kris Kennaway wrote:
> Here's another FP-related failure:
>
> http://bento.freebsd.org/errorlogs/sparc64-5-latest/xaos-3.0.log
>
> FP_X_DNML is defined on i386 in /usr/include/machine/ieeefp.h, but not
> on sparc64.
This is a bug in the port. Denormals are not in IEEE FP. i386 is the
only supported arch that has them.
Bruce
------------------------------
Date: Sun, 12 Jan 2003 01:52:21 -0500
From: Jake Burkholder <ja...@locore.ca>
Subject: Re: fpsetmask on sparc64
Apparently, On Sat, Jan 11, 2003 at 07:16:26PM -0800,
Kris Kennaway said words to the effect of;
> fpsetmask is not defined in <floatingpoint.h> or
> <machine/floatingpoint.h> on sparc64 (it is on i386):
>
> /usr/include/machine/floatingpoint.h:#define fpsetmask(m) ((fp_except_t) \
> /usr/include/ieeefp.h:extern fp_except_t fpsetmask(fp_except_t);
> /usr/include/floatingpoint.h:#define fpsetmask(m) ((fp_except_t)
>
> This appears to cause the following port failures/warnings:
>
> amphetamine-0.8.10.log:src/Main.cpp:79: `fpsetmask' undeclared (first use this function)
> glasteroids-1.0.log:Glasteroids.cxx:82: `fpsetmask' undeclared (first use this function)
> lame-devel-3.89b.log:util.c:883: warning: implicit declaration of function `fpsetmask'
> smalltalk-2.0.8.log:lex.c:814: warning: implicit declaration of function `fpsetmask'
> xmrm-2.0_2.log:morphvec.cc:439: `fpsetmask' undeclared (first use this function)
>
> Is this an omission, or are the ports wrong?
FWIW, the alpha headers are basically identical to the sparc64 ones.
There may be missing ifdefs in the ports or the makefiles.
Jake
------------------------------
Date: Sun, 12 Jan 2003 00:23:42 -0800
From: Terry Lambert <tlam...@mindspring.com>
Subject: Re: fpsetmask on sparc64
Bruce Evans wrote:
> > Is this an omission, or are the ports wrong?
>
> First answer:
> This is a bug in the ports. The non-i386 arches are apparently including
> <machine/floatingpoint.h> instead of the documented interface <ieeefp.h>.
Wow, gotta disagree with that; the problem doesn't magically go
away when you include the standard header file.
> I think the ports are only meddling the FP mask to hide their FP errors
> when running under FreeBSD-3.x and earlier anyway.
They are meddling with it because the FreeBSD default, while it is
permitted by the standard, is different from what most software
expects the default to be.
Yeah, it'd be nice if it weren't there, but the man page itself
specifically uses fpsetmask() in an example (to prevent some trap).
> Second answer:
> Ports should use the C99 interfaces fe{get,set}*() from <fenv.h>, and then
> only if C99 is supported. There might be problems with this too:
> - C99 isn't supported yet.
> - C99 doesn't have fesetmask(). This is partly because it would be
> very unportable. It is not an IEEE FP feature. C99 only has
> fesetenv(FE_DFL_ENV) to recover from any meddling with the FP
> environment.
> - Non-default FP environments should only be used in small sections
> of code, since large parts of libraries, etc. are entitled to assume
> that the environment is the default. So changing the FP mask to a
> non-default value at program startup time would give undefined
> behaviour if it were possible.
This is also really arguable, IMO. The problem with this is that
the assumption that they are "entitled to assume that the environment
is the default" is really bogus.
What this really comes down to is that Intel FP hardware sucks,
and should be redesigned to raise exceptions when they occur,
instead of on the next operation. It's like the old VT100's, or
other therminals with the "AM" attribute which is true, and they
wrap before the 81st character, rather than after the 80th.
I understand the pipeline stall that would happen on an exception,
if this is how they were handed; on the other hand, it's a little
bogus to assume that exceptions aren't going to be rare, what with
them being "exceptional" and all. 8-).
The C99 soapbox is a nice place to stand, if you want to criticize
all other implementations; but as you point out, C99 is not really
there yet, and even if it were, you could not really expect all
code to be changed to conform to it (or any other standard, for
that matter, considering the amount of legacy code everywhere).
- -- Terry
------------------------------
Date: Sun, 12 Jan 2003 03:29:08 -0500
From: Jake Burkholder <ja...@locore.ca>
Subject: Re: fpsetmask on sparc64
Apparently, On Sun, Jan 12, 2003 at 12:25:20AM -0800,
Terry Lambert said words to the effect of;
> Jake Burkholder wrote:
> > > Is this an omission, or are the ports wrong?
> >
> > FWIW, the alpha headers are basically identical to the sparc64 ones.
> > There may be missing ifdefs in the ports or the makefiles.
>
> Isn't that really a lame excuse? Shouldn't
>
> #ifdef __FreeBSD__
>
> be enough to make code compile on all FreeBSD platforms?
I don't know, why don't you try it.
Jake
------------------------------
Date: Sun, 12 Jan 2003 00:13:45 -0800
From: Terry Lambert <tlam...@mindspring.com>
Subject: Re: fpsetmask on sparc64
Kris Kennaway wrote:
> Here's another FP-related failure:
>
> http://bento.freebsd.org/errorlogs/sparc64-5-latest/xaos-3.0.log
>
> FP_X_DNML is defined on i386 in /usr/include/machine/ieeefp.h, but not
> on sparc64.
Use of this manifest value requires a feature test. This is a
bug in the ported software (IMO).
- -- Terry
------------------------------
Date: Sun, 12 Jan 2003 00:25:20 -0800
From: Terry Lambert <tlam...@mindspring.com>
Subject: Re: fpsetmask on sparc64
Jake Burkholder wrote:
> > Is this an omission, or are the ports wrong?
>
> FWIW, the alpha headers are basically identical to the sparc64 ones.
> There may be missing ifdefs in the ports or the makefiles.
Isn't that really a lame excuse? Shouldn't
#ifdef __FreeBSD__
be enough to make code compile on all FreeBSD platforms?
- -- Terry
------------------------------
Date: Sun, 12 Jan 2003 20:24:19 +1100 (EST)
From: Bruce Evans <b...@zeta.org.au>
Subject: Re: fpsetmask on sparc64
On Sun, 12 Jan 2003, Terry Lambert wrote:
> Bruce Evans wrote:
> > > Is this an omission, or are the ports wrong?
> >
> > First answer:
> > This is a bug in the ports. The non-i386 arches are apparently including
> > <machine/floatingpoint.h> instead of the documented interface <ieeefp.h>.
>
> Wow, gotta disagree with that; the problem doesn't magically go
> away when you include the standard header file.
Yes it does (should). Including an implementation detail like
<machine/floatingpoint.h> gives undefined behaviour. In this case,
one aspect of the undefined behaviour is that fpsetmask() is not
declared in the MD file except in the i386 case as a side effect
of being implemented as a macro that calls an inline function there.
In all the other arches, it is an extern function that is only
declared in <ieeefp.h>.
> > I think the ports are only meddling the FP mask to hide their FP errors
> > when running under FreeBSD-3.x and earlier anyway.
>
> They are meddling with it because the FreeBSD default, while it is
^^ iswas (1)
> permitted by the standard, is different from what most software
was (2)
> expects the default to be.
(1) was permitted by C90; is not permitted by C99, but C99 is not supported
yet.
(2) was different before FreeBSD-4.0. Are there any ports that still
support FreeBSD-3?
> Yeah, it'd be nice if it weren't there, but the man page itself
> specifically uses fpsetmask() in an example (to prevent some trap).
The man page still supports FreeBSD-3 :-). It is version-agnostic. The
default setting is very MD, so software that actually cares must not
assume anything about the defaults.
> > [... in C99]
> > - Non-default FP environments should only be used in small sections
> > of code, since large parts of libraries, etc. are entitled to assume
> > that the environment is the default. So changing the FP mask to a
> > non-default value at program startup time would give undefined
> > behaviour if it were possible.
>
> This is also really arguable, IMO. The problem with this is that
> the assumption that they are "entitled to assume that the environment
> is the default" is really bogus.
Anything else would be very expensive both in source code complexity
and runtime costs. The environment would have to be switched for every
library function that uses FP. C99 only requires a few specialized
math functions to be aware of this.
> What this really comes down to is that Intel FP hardware sucks,
> and should be redesigned to raise exceptions when they occur,
> instead of on the next operation. It's like the old VT100's, or
This is not suckagae, but a normal consequence of pipelining. Intel
hardware is relatively nice here. It gives precise exceptions on the
next operation. Less-unmodern hardware like alphas has very imprecise
exceptions unless everything is pessimized using trap barriers. See
- -mtrap-precision in gcc.info. But exceptions are now almost moot on
i386's since they don't cause traps. However, at least some alphas
need to cause traps to be IEEE conformant since traps are needed to
implement some parts of IEEE conformance in software, and the largest
of the -mtrap-precision pessimizations are needed for this to work.
See -mieee-conformant in gcc.info.
> I understand the pipeline stall that would happen on an exception,
> if this is how they were handed; on the other hand, it's a little
> bogus to assume that exceptions aren't going to be rare, what with
> them being "exceptional" and all. 8-).
As far as I understand the hardware issues (not far), the stall would
be necessary after every FP instruction, not just ones which generate
the exception. FP performance would be reduced by approximately a
factor of (pipeline_length * number_of_concurrent_FP_ops_achieved).
I guess speculative execution code get near appearing to not stall
though.
> The C99 soapbox is a nice place to stand, if you want to criticize
> all other implementations; but as you point out, C99 is not really
> there yet, and even if it were, you could not really expect all
> code to be changed to conform to it (or any other standard, for
> that matter, considering the amount of legacy code everywhere).
True. It just gives applications a chance of handling environment-
related FP stuff almost portably.
Bruce
------------------------------
Date: Sun, 12 Jan 2003 05:09:37 -0800
From: Terry Lambert <tlam...@mindspring.com>
Subject: Re: fpsetmask on sparc64
Jake Burkholder wrote:
> > Isn't that really a lame excuse? Shouldn't
> >
> > #ifdef __FreeBSD__
> >
> > be enough to make code compile on all FreeBSD platforms?
>
> I don't know, why don't you try it.
I understand the snide reply. My point was that if FreeBSD had
platform differences, it should hide them from user space
applications: if it's going to be as hard to port to FreeBSD-alpha
from FreeBSD-i386, then you might as well spend your time on a
higher margin platform.
Apparently, Solaris supports fpsetmask(3C) in SVR4 derived
Solaris on SPARC, which means that this is not an Intel-specific
feature, and therefore it's not possible to justify it being an
Intel-specific feature in FreeBSD. In the absolute worst case,
it should be stubbed out, and complain, on SPARC and Alpha, if
it isn't made to work.
Solaris man page:
http://www.FreeBSD.org/cgi/man.cgi?query=fpsetmask&apropos=0&sektion=0&manpath=SunOS+5.8&format=html
- -- Terry
------------------------------
Date: Sun, 12 Jan 2003 05:43:45 -0800
From: Terry Lambert <tlam...@mindspring.com>
Subject: Re: fpsetmask on sparc64
Bruce Evans wrote:
> On Sun, 12 Jan 2003, Terry Lambert wrote:
> > Bruce Evans wrote:
> > > > Is this an omission, or are the ports wrong?
> > >
> > > First answer:
> > > This is a bug in the ports. The non-i386 arches are apparently including
> > > <machine/floatingpoint.h> instead of the documented interface <ieeefp.h>.
> >
> > Wow, gotta disagree with that; the problem doesn't magically go
> > away when you include the standard header file.
>
> Yes it does (should).
We're at cross-purposes here, I think. It doesn't go away, even if
it should; here's ieeefp.h:
#ifndef _IEEEFP_H_
#define _IEEEFP_H_
#include <sys/cdefs.h>
#include <machine/ieeefp.h>
#ifdef __i386__
#include <machine/floatingpoint.h>
#else /* !__i386__ */
__BEGIN_DECLS
extern fp_rnd_t fpgetround(void);
extern fp_rnd_t fpsetround(fp_rnd_t);
extern fp_except_t fpgetmask(void);
extern fp_except_t fpsetmask(fp_except_t);
extern fp_except_t fpgetsticky(void);
extern fp_except_t fpsetsticky(fp_except_t);
__END_DECLS
#endif /* __i386__ */
#endif /* _IEEEFP_H_ */
The function will still be missing from the library, even if there's
a valid prototype in scope, because you included the header file, and
didn't get any of the manifests. To get the manifests, you have to
include the <machine/ieeefp.h>, seperately.
Notice that the only real difference is whether or not the
operations end up using an inline version of the functions, or
expect one to be in the library.
That's a library bug, that they would not be implemented on SPARC.
The second problem where the manifest wasn't defined is a real
problem in the ported code; technically, they are required to
feature test before using the manifest constant.
> Including an implementation detail like
> <machine/floatingpoint.h> gives undefined behaviour. In this case,
> one aspect of the undefined behaviour is that fpsetmask() is not
> declared in the MD file except in the i386 case as a side effect
> of being implemented as a macro that calls an inline function there.
> In all the other arches, it is an extern function that is only
> declared in <ieeefp.h>.
The problem was not one of a prototype not being in scope, which
is basically a stupid pseudo-compiler error that came from not
mandating that that crap get handled at link-time (which is very
easy to do, if you are willing to break legacy object compatability,
just like symbol decoration can go away).
> > > I think the ports are only meddling the FP mask to hide their FP errors
> > > when running under FreeBSD-3.x and earlier anyway.
> >
> > They are meddling with it because the FreeBSD default, while it is
> ^^ iswas (1)
> > permitted by the standard, is different from what most software
> was (2)
> > expects the default to be.
>
> (1) was permitted by C90; is not permitted by C99, but C99 is not supported
> yet.
So it's irrelevent, right?
> (2) was different before FreeBSD-4.0. Are there any ports that still
> support FreeBSD-3?
Not this software, certainly... making it also irrelevent, right?
> > Yeah, it'd be nice if it weren't there, but the man page itself
> > specifically uses fpsetmask() in an example (to prevent some trap).
>
> The man page still supports FreeBSD-3 :-). It is version-agnostic. The
> default setting is very MD, so software that actually cares must not
> assume anything about the defaults.
Exactly. And therfore must call the function to set the FPU into
a known state, with regatd to exception handling, etc.. Which
makes my case, there.
> Anything else would be very expensive both in source code complexity
> and runtime costs.
A push/pop paradigm could do this without any real cost, actually;
when you add threading, things get complicated, but since you are
screwing with signal masks before and after threaded calls, to
get around the fact that the BSD default of system call restart has
been removed in favor of the System V default of system call
non-restart, following a signal, you have an amplification factor of
3 on system call overhead anyway, so additional overhead for threads
is basically totally lost in the noise of all that *other* overhead
you get, just from using threads in the first place.
> The environment would have to be switched for every
> library function that uses FP. C99 only requires a few specialized
> math functions to be aware of this.
Everyone who uses FP has to do it anyway: if they want consistent
results, and the FP doesn't start in a preferred state, then the
answer is that you *always* have to save and restore the state.
You could get around this a little, by doing two things:
1) Cache the current state in a user space global, so that
the code involved can decide to not do the save/restore,
if it's already in the preferred state.
2) FreeBSD could quit being so contrarian, and adopt the
same default state that Linux, Solaris, and SCO use,
which is, now, for programmers, the preferred state.
> > What this really comes down to is that Intel FP hardware sucks,
> > and should be redesigned to raise exceptions when they occur,
> > instead of on the next operation. It's like the old VT100's, or
>
> This is not suckagae, but a normal consequence of pipelining. Intel
> hardware is relatively nice here. It gives precise exceptions on the
> next operation. Less-unmodern hardware like alphas has very imprecise
> exceptions unless everything is pessimized using trap barriers. See
> -mtrap-precision in gcc.info. But exceptions are now almost moot on
> i386's since they don't cause traps. However, at least some alphas
> need to cause traps to be IEEE conformant since traps are needed to
> implement some parts of IEEE conformance in software, and the largest
> of the -mtrap-precision pessimizations are needed for this to work.
> See -mieee-conformant in gcc.info.
The preferred state of the hardware for most programmers is "no
exceptions by default" anyway. FeeBSD tried to be more precise,
and makes programmers go out of their way to get the same imprecision
and behaviour that they expect, because of their code being written
for other platforms. It's not like FreeBSD is the reference platform
for much software, so it's not like this is really a moral high ground,
here.
In any case, trap barriers are not really necessary; implying a
barrier when an exception is raised is enough. As long as you don't
hit an exceptional condition, you are free to pipeline, and, given
that exceptional conditions are, well, "exceptional", and therefore
don't happen very often, it's not like you'd be giving up speed in
the common case. In the barrier case, you are running a trap
handler, anyway (at least, FreeBSD assumes you will be).
Add to this the MMX, bcopy, and other abuse of the FP registers,
and you've got a lot of good reasons to trap on the event. 8-(.
> > I understand the pipeline stall that would happen on an exception,
> > if this is how they were handed; on the other hand, it's a little
> > bogus to assume that exceptions aren't going to be rare, what with
> > them being "exceptional" and all. 8-).
>
> As far as I understand the hardware issues (not far), the stall would
> be necessary after every FP instruction, not just ones which generate
> the exception. FP performance would be reduced by approximately a
> factor of (pipeline_length * number_of_concurrent_FP_ops_achieved).
> I guess speculative execution code get near appearing to not stall
> though.
I keep getting this rationale, but it doesn't really fly for me.
If you are going to raise an exception, you are going to lose
the speculative execution that was done on the basis of the idea
that you were not going to get an exception.
I'm half inclined to say that FP state should be saved and restored
on context switches of a process, after it has once used FP, and
get rid of all this special crap that comes from trying to lazy-bind
FPU context switching. The worst case for this will be the worst
case in any case; in the best case, you will save context, and then
decide that it's still present, so it doesn't need to be restored.
That's an overhead that I think is livable, since it assumes a
loaded system in the first place, context switching away from the
FP-using process, because there's other stuff that wants to run.
> > The C99 soapbox is a nice place to stand, if you want to criticize
> > all other implementations; but as you point out, C99 is not really
> > there yet, and even if it were, you could not really expect all
> > code to be changed to conform to it (or any other standard, for
> > that matter, considering the amount of legacy code everywhere).
>
> True. It just gives applications a chance of handling environment-
> related FP stuff almost portably.
I'm willing to cross that bridge when someone fully implements C99
compliance, and ignore it, until then. It's not really useful to
drive by some place that under construction for 4 years now, and
every day sigh about not being able to use the parking garage, or
complain about the places you can park to get where you need to go
today (IMO). More than 4 years, if you consider that it was possible
to start implementation when C99 was still draft.
- -- Terry
------------------------------
Date: Sun, 12 Jan 2003 16:13:20 +0100
From: "Roderick van Domburg" <r.s.a.va...@student.utwente.nl>
Subject: RE: panic: trap: fast data access mmu miss
> > Running on a Sun Enterprise 250 with a single UltraSparc-II
> > CPU, 512 MB RAM and three Fujitsu SCSI-II hard disks. I've had
> > this same problem with sources over the past few (three?) days.
> > I had to copy this dmesg by hand, so please bear with any
> > possible typos.
>
> Please try the attached diff. The crash was due to what I consider a
> driver bug (not checking the error in the bus_dmamap_load() callback),
> however due to the FreeBSD busdma API being largely undocumented it is
> a bit difficult to tell what should be considered legal. Much more
> problematic is to assume that the first segment's bus address will be
> 0 in the error case. This is not currently guaranteed by any
> implementation.
>
> The attached patch fixes that, and also passes a valid pointer to the
> callback for maximum compatability. It also fixes some other bugs I
> came across.
>
> This does however still not address the reason for the
> bus_dmamap_load() failure; I'm not really sure why this does
> happen. Please look for messages like:
> __sym_calloc2: failed to allocate ...
> and tell me if you see any of them.
Thanks for the patches! Unfortunately however, it still doesn't seem to
attach sym1 quite right, I believe. Your patches did make the booting
process advance further, but the kernel failed to mount root. Here is the
dmesg, once again manually copied. That __sym_calloc2 message is right on
the second line.
If it is of any help, the kernel builds from sources mid-December 2002
worked just fine.
sym1: No NVRAM, ID 7, Fast-20, SE, parity checking
__sym_calloc2: failed to allocate SCRIPTB0[1308]
device_probe_and_attach: sym1 attach returned 6
pcib2: <U2P UPA-PCI bridge> on nexus0
pcib2: Psycho, impl 0, version 4, ign 0x7c0
pci2: <PCI bus> on pcib2
pci2: <display> at device 1.0 (no driver attached)
nexus0: <rsc>, type system-service-processor (no driver attached)
nexus0: <mc>, type memory-controller (no driver attached)
Timecounters tick every 10.000 msec
ipfw2 initialized, divert disabled, rule-based forwarding enabled, default
to deny, logging disabled
Waiting 15 seconds for SCSI devices to settle
Mounting root from ufs:/dev/da0a
setrootbyname failed
ffs_mountroot: can't find rootvp
Root mount failed: 6
Manual root filesystem specification:
[cut]
mountroot>
------------------------------
Date: Sun, 12 Jan 2003 13:49:48 -0500
From: Jake Burkholder <ja...@locore.ca>
Subject: Re: fpsetmask on sparc64
Apparently, On Sun, Jan 12, 2003 at 05:09:37AM -0800,
Terry Lambert said words to the effect of;
> Jake Burkholder wrote:
> > > Isn't that really a lame excuse? Shouldn't
> > >
> > > #ifdef __FreeBSD__
> > >
> > > be enough to make code compile on all FreeBSD platforms?
> >
> > I don't know, why don't you try it.
>
> I understand the snide reply. My point was that if FreeBSD had
My point is that you could help by actually doing something. Your
repeated long emails DO NOT HELP.
Jake
------------------------------
Date: Sun, 12 Jan 2003 20:30:23 +0100
From: =?iso-8859-2?B?UGlvdHIgV2+8bmlhaw==?= <piotr....@cs.put.poznan.pl>
Subject: compiling postgresql7 failed
Hi,
I can't compile Postgresql7... (5.0-RC2, sparc64, gcc version 3.2.1)
Is there any way to avoid such errors? Should I modify C++ code??
- ----------------------------------------
cc -O -pipe -Wall -Wmissing-prototypes -Wmissing-declarations -
I../../../../src/include -I/usr/local/include -c -o xid.o xid.c
cc -O -pipe -Wall -Wmissing-prototypes -Wmissing-declarations -
I../../../../src/include -I/usr/local/include -c -o xlog.o xlog.c
In file included from ../../../../src/include/storage/spin.h:50,
from xlog.c:41:
../../../../src/include/storage/s_lock.h:184: syntax error before '*' token
../../../../src/include/storage/s_lock.h:185: warning: return type defaults
to `int'
../../../../src/include/storage/s_lock.h:185: warning: no previous
prototype for `tas'
- ----------------------------------------
Piotr
------------------------------
Date: Sun, 12 Jan 2003 20:54:27 +0100
From: "Roderick van Domburg" <r.s.a.va...@student.utwente.nl>
Subject: RE: compiling postgresql7 failed
> I can't compile Postgresql7... (5.0-RC2, sparc64, gcc version 3.2.1)
> Is there any way to avoid such errors? Should I modify C++ code??
You need to upgrade your ports collection. This issue has been fixed several
weeks ago.
Roderick
------------------------------
Date: Sun, 12 Jan 2003 12:44:44 -0800 (PST)
From: John Polstra <j...@polstra.com>
Subject: Question about odd stack pointer values on sparc64
Still working on getting Modula-3 going on Sparc64. I think I'm
getting close ...
In GDB I notice that the stack pointer and frame pointer are often
(always?) odd numbers, e.g.:
(gdb) p/x $sp
$1 = 0x7fdffffdec1
(gdb) p/x $fp
$2 = 0x7fdffffdfb1
What is the reason for that? Are the low-order bits simply ignored?
Surely the stack is more aligned than that.
I'm pretty sure this is confusing the M3 garbage collector. It just
might be the proverbial Last Bug. :-)
Thanks,
John
------------------------------
Date: Mon, 13 Jan 2003 07:48:56 +1100 (EST)
From: Bruce Evans <b...@zeta.org.au>
Subject: Re: fpsetmask on sparc64
On Sun, 12 Jan 2003, Terry Lambert wrote:
> Bruce Evans wrote:
> > On Sun, 12 Jan 2003, Terry Lambert wrote:
> > > Bruce Evans wrote:
> > > > > Is this an omission, or are the ports wrong?
> > > >
> > > > First answer:
> > > > This is a bug in the ports. The non-i386 arches are apparently including
> > > > <machine/floatingpoint.h> instead of the documented interface <ieeefp.h>.
> > >
> > > Wow, gotta disagree with that; the problem doesn't magically go
> > > away when you include the standard header file.
> >
> > Yes it does (should).
>
> We're at cross-purposes here, I think. It doesn't go away, even if
> it should; here's ieeefp.h:
>
> #ifndef _IEEEFP_H_
> #define _IEEEFP_H_
>
> #include <sys/cdefs.h>
> #include <machine/ieeefp.h>
^^^^^^^^^^^^^^^^^^^^^^^^^^^
Here are the manifests (sic).
>
> #ifdef __i386__
> #include <machine/floatingpoint.h>
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Here is i386-specific code (which happens to be the implementation of the
functions as inlines).
> #else /* !__i386__ */
> __BEGIN_DECLS
> extern fp_rnd_t fpgetround(void);
> extern fp_rnd_t fpsetround(fp_rnd_t);
> extern fp_except_t fpgetmask(void);
> extern fp_except_t fpsetmask(fp_except_t);
> extern fp_except_t fpgetsticky(void);
> extern fp_except_t fpsetsticky(fp_except_t);
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Here are the declarations of the functions. These are used by the arches
that don't implement them as inlines (which happen to be all non-i386
arches).
Here are also some style bugs (extern, and no tabs).
> __END_DECLS
> #endif /* __i386__ */
>
> #endif /* _IEEEFP_H_ */
>
> The function will still be missing from the library, even if there's
> a valid prototype in scope, because you included the header file, and
> didn't get any of the manifests. To get the manifests, you have to
> include the <machine/ieeefp.h>, seperately.
The functions are not shown above. They are normal functions in libc
for most arches.
> Notice that the only real difference is whether or not the
> operations end up using an inline version of the functions, or
> expect one to be in the library.
>
> That's a library bug, that they would not be implemented on SPARC.
They aren't implemented as inline functions on sparc64's, so no
amount of header inclusion can do more than declare them. Including
wrong headers result in them being completely undeclared.
> ...
> > > > I think the ports are only meddling the FP mask to hide their FP errors
> > > > when running under FreeBSD-3.x and earlier anyway.
> > >
> > > They are meddling with it because the FreeBSD default, while it is
> > ^^ iswas (1)
> > > permitted by the standard, is different from what most software
> > was (2)
> > > expects the default to be.
> >
> > (1) was permitted by C90; is not permitted by C99, but C99 is not supported
> > yet.
>
> So it's irrelevent, right?
It's probably irrelevant. I haven't looked at the ports. They seem to
attempting to make null changes in FreeBSD-4.0 and later.
> > (2) was different before FreeBSD-4.0. Are there any ports that still
> > support FreeBSD-3?
>
> Not this software, certainly... making it also irrelevent, right?
Not quite irrelvant, since they seem to have dead code which has been
wrong since 1998.
> > > Yeah, it'd be nice if it weren't there, but the man page itself
> > > specifically uses fpsetmask() in an example (to prevent some trap).
> >
> > The man page still supports FreeBSD-3 :-). It is version-agnostic. The
> > default setting is very MD, so software that actually cares must not
> > assume anything about the defaults.
>
> Exactly. And therfore must call the function to set the FPU into
> a known state, with regatd to exception handling, etc.. Which
> makes my case, there.
Very few applications have a legitimate use for doing this. I would
expect the ones that do to know which headers to include.
> ...
Bruce
------------------------------
Date: Sun, 12 Jan 2003 13:14:11 -0800 (PST)
From: John Polstra <j...@polstra.com>
Subject: Re: Question about odd stack pointer values on sparc64
Jake Burkholder wrote:
> Apparently, On Sun, Jan 12, 2003 at 12:44:44PM -0800,
> John Polstra said words to the effect of;
>
>> In GDB I notice that the stack pointer and frame pointer are often
>> (always?) odd numbers, e.g.:
[...]
> Its because the stack is offset by -2047, to get the real stack pointer
> add 2047.
Ohhhhh! No _wonder_ M3 hasn't been working right ...
> As for reasons why this was done, apparently it allows a larger region
> of stack to be addressed with 13 bit immediate offsets, also 32 bit sparc
> code doesn't use a stack bias so it can be distinguished by testing the
> alignment of the unmodified stack pointer.
Makes sense. Thanks for the info!
John
------------------------------
End of freebsd-sparc-digest V5 #214
***********************************
To Unsubscribe: send mail to majo...@FreeBSD.org
with unsubscribe freebsd-sparc-digest in the body of the message