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]