On Tue, 24 Feb 2004, Jarkko Hietaniemi wrote:
> I am unfortunately running out of time to look more into the matter of
> bytecode reading being broken in Alpha. However, here are some notes
> for those who want to try, as of src/byteorder.c 1.20 and
> src/packfile.c 1.142. First of all note that I'm no Parrot or PBC
> guru, I'm mostly going by what I think I can understand from
> docs/parrotbyte.pod, version 2003.11.22.
>
> (1) What is failing is ./parrot t/native_pbc/{integer_1,number_{1,2}.t},
> all are saying:
>
> PackFile_unpack: Not a Parrot PackFile!
> Magic number was [0x4c524550] not [0x013155a1]
> Parrot VM: Can't unpack packfile t/native_pbc/integer_1.pbc.
> error:imcc:main: Packfile loading failed
That looks rather similar to what I get on SPARC. Here are
three variations I just got:
Solaris/SPARC/Sun cc, longsize=4:
# PackFile_unpack: Not a Parrot PackFile!
# Magic number was [0x20a54100] not [0x013155a1]
# Parrot VM: Can't unpack packfile t/native_pbc/number_1.pbc.
Linux/SPARC/gcc-3.3.3 20040125 (prerelease) (Debian), longsize=4
# PackFile_unpack: Not a Parrot PackFile!
# Magic number was [0x00469a30] not [0x013155a1]
Linux/SPARC/gcc-3.3.3 20040125 (prerelease) (Debian), longsize=8
# PackFile_unpack: Not a Parrot PackFile!
# Magic number was [0x10000200] not [0x013155a1]
And, just to round out the report, on x86 with long-long opcodes,
(what you get if you build perl-5.8.3 with -Duse64bitint)
Linux/x86/gcc version 3.3.2 (Debian), longlongsize=8
# Failed test (t/native_pbc/integer.t at line 35)
# got: 'BYTECODE_-: Size in directory 32 doesn't match size at offset
(0x2d5f) -1064971727
# ^B: Size in directory 1431849286 doesn't match size at offset (0x2) 20010401
# section: sections are not back to back
# (: Size in directory 8 doesn't match size at offset (0x28) 0
# section: sections are not back to back
Clearly something very strange is going on. Alas, I don't have time
to investigate either.
--
Andy Dougherty [EMAIL PROTECTED]
