Perl on Cray PVP (SV1 or YMP) Bug

[p5pRT]

Migrated from rt.perl.org#1916 (status was 'resolved')

Searchable as RT1916$

[p5pRT]

From sam@osc.edu

I have discovered the following bug installing Perl 5.005_03 on a
Cray SV1.

The routine filter_add saves the address of a function in a variable
which is typed DIR *. When the address in retrieved, the address has the
2 low order bits removed. While this is somewhat surprising to me I guess
it is legit. If one views the function address as a machine packet address,
then the low 2 bits are the packet offset (one of four 16-bit instruction
packets). Packets are not byte aligned, so the pointer is converted to
a word aligned byte pointer. This is done by shifting right 2 places.
The byte within word for a Cray byte pointer are stored in the high 4 bits
of a 64-bit value and are zero in this case.

Example​:

OSCA$ cat ptest.c
#include <stdio.h>

typedef int(*fptr)(void);

typedef struct {
  int x;
} *sptr;

main()
{
  fptr f;
  sptr s;

  f = (fptr)0xffffffff;
  printf("f​: %8.8x\n", f);

  s = (sptr)f;
  printf("s​: %8.8x\n", s);

  f = (fptr)s;
  printf("f​: %8.8x\n", f);
}

OSCA$ ./a.out
f​: ffffffff
s​: 3fffffff
f​: fffffffc

My temporary workaround is to cause the function to align such that the low 2
bits are not significant.

--Sam
Sam Bair
Ohio Supercomputer Center
1224 Kinnear Road
Columbus, OH 43212-1163
sam@​osc.edu
614-292-2478
614-292-7168 (FAX)

[p5pRT]

From [Unknown Contact. See original ticket]

This one actually looks like it might have been fixed, but I'm not familiar
enough with the source to tell.

-spp

------- Forwarded Message

Stephen,

I don't have the time at the moment to try a new version. However, my
opinion is that a pointer to a function (or to anything for that matter)
should not be stored in pointer to something else. Whether or not the
bug goes away might reflect the state of the compiler. I feel the code
should be changed and the problem should remain open until it is fixed.
I suppose this is only a problem on word addressed machines and will
disappear when word addressed Crays disappear. Until then it should get
a mention in release notes.

I would have offered a code fix except I am not too familiar with Perl and
I thought I might break something else trying to fix this code. I know
I am not being the best citizen in this regard but what can I say?

- --Sam

On Mon, 11 Dec 2000, Stephen P. Potter wrote​:

Sam-
In an attempt to clean up the perl bug database, I ran across this report
from you from last year. Could you tell me if you still consider this bug
to be valid (have you seen the same/similar problem in the newest release
of perl), or whether you believe the bug should be closed.

Hi,

I have discovered the following bug installing Perl 5.005_03 on a
Cray SV1.

The routine filter_add saves the address of a function in a variable
which is typed DIR *. When the address in retrieved, the address has the
2 low order bits removed. While this is somewhat surprising to me I guess
it is legit. If one views the function address as a machine packet
address,
then the low 2 bits are the packet offset (one of four 16-bit instruction
packets). Packets are not byte aligned, so the pointer is converted to
a word aligned byte pointer. This is done by shifting right 2 places.
The byte within word for a Cray byte pointer are stored in the high 4 bits
of a 64-bit value and are zero in this case.

Example​:

OSCA$ cat ptest.c
#include <stdio.h>

typedef int(*fptr)(void);

typedef struct {
int x;
} *sptr;

main()
{
fptr f;
sptr s;

     f = \(fptr\)0xffffffff;
     printf\("f​: %8\.8x\\n"\, f\);

     s = \(sptr\)f;
     printf\("s​: %8\.8x\\n"\, s\);

     f = \(fptr\)s;
     printf\("f​: %8\.8x\\n"\, f\);

}

OSCA$ ./a.out
f​: ffffffff
s​: 3fffffff
f​: fffffffc

My temporary workaround is to cause the function to align such that the
low 2
bits are not significant.

Sam Bair
Ohio Supercomputer Center
1224 Kinnear Road
Columbus, OH 43212-1163
sam@​osc.edu
614-292-2478
614-292-7168 (FAX)

------- End of Forwarded Message

[p5pRT]

From @jhi

On Mon, Dec 11, 2000 at 11​:16​:21AM -0500, Stephen P. Potter wrote​:

This one actually looks like it might have been fixed, but I'm not familiar
enough with the source to tell.

I think this was fixed by 6315 and 6324.

[p5pRT]

From The RT System itself

See also 20000803.005,
fixed in 6510 and others.

[p5pRT]

From [Unknown Contact. See original ticket]

Lightning flashed, thunder crashed and Jarkko Hietaniemi <jhi@​iki.fi> whispered
:
| On Mon, Dec 11, 2000 at 11​:16​:21AM -0500, Stephen P. Potter wrote​:
| > This one actually looks like it might have been fixed, but I'm not familiar
| > enough with the source to tell.
|
| I think this was fixed by 6315 and 6324.

Also, possibly 6510.

Closed.

-spp