Problem with built-ins

[pir...@gmail.com]

I have been able to port p14p to use multiboot as basis and boot with
QEmu, but i'm getting an error that i can't be able to solve.

When launching my port, at the point it calls pm_run() it shows the
next traceback:

Traceback (most recent call first):
File "../lib/__bi.py", line 25, in __bi
AttributeError detected by interp.c:1315

Looking at the source code, the line 25 of __bi.py is "def abs(n):",
and in fact, it's the first python line on the file, and the line 1315
at interp.c it's related to LOAD_ATTR bytecode raising an
AttributeError as default option, since the object type that it's
being used for the attributes it's a None object. Using some traces on
the code it seems built-ins are not being correctly loaded, raising
the error at dict_setItem() at global.c:207 (i think is because
PM_PBUILTINS is NULL), previously raising another one at
global_loadBuiltins() at global.c:199 when calling
interpret(INTERP_RETURN_ON_NO_THREADS). I have found this last one
putting a PM_RETURN_IF_ERROR(retval); after it (it shouldn't have
one?) giving in both cases the same traceback.

Besides the fact that's running on QEmu using a multiboot header and
i'm using a print "hello world" line as main.py, the virtual machine
code it's the same that the V09 from the Mercurial repository. Anyone
knows what's the problem and how i can be able to solve it? It's just
the last pieze of the puzzle that i need to have p14p working on
x86... :-D

Host:
Pentium Dual-Core E5500 64bits
4GB RAM
Linux Ubuntu 11.04 64bits

Platform:
QEmu virtual machine 32bits, launched from command line using --kernel
parameter using main.out as kernel image
Multiboot header from Multiboot Specification example code
(http://www.gnu.org/software/grub/manual/multiboot/multiboot.html#Examples)
P14p desktop platform used as basis with default values (heap = 0x2000)
Compilation extra flags: -nostdinc -fno-builtin -nostdlib
-fno-stack-protector -m32
Using home-made stdlib for p14p required functions

Full code at http://code.google.com/r/piranna-p14p/source/browse

--
"Si quieres viajar alrededor del mundo y ser invitado a hablar en un
monton de sitios diferentes, simplemente escribe un sistema operativo
Unix."
– Linus Tordvals, creador del sistema operativo Linux

[dvdnotjon]

Here's my first theory

Ubuntu 11.04 (natty narwhal) uses Python2.7 from Debian.

Python2.7 emits bytecodes that p14p VM pymite does not support

(eg POP_JUMP_IF_TRUE) and these are appearing in the compiled lib builtins. 

I guess that the interpreter run to add built-ins is stumbling over such a bytecode

(case UNUSED_72:) landing in the default clause of the interpreter switch and bailing out,

but the returned exception is ignored.

The LOAD_ATTR error is then a secondary error.

I suggest trying Python2.6.7 or earlier.

Didn't have Ubuntu 11.04 64-bit handy, but to test this theory I tried v10 with Python2.7.2 on windows7 64-bit (but 32 bit pymite.exe) which crashed in LOAD_ATTR. Switched back to Python2.6 and no crash and pymite says Hello.

It'd be nice if pmImgCreator checked the bytecode version by inspecting the code.magic.

http://stackoverflow.com/questions/7807541/is-there-a-way-to-know-by-which-python-version-the-pyc-file-was-compiled 

My second theory (improbable)

The main.out QEmu kernel startup is not placing consts where  El Piraña's x86 code can find them so "__bi" is wrong value or bytecodes

are random values which quits the interpreter while adding byte codes and give similar secondary error  symptom.

   

[pir...@gmail.com]

Are you saying that with python 2.7 you have been able to reproduce the bug, and also check that with python 2.6 it works? They are awesome news!!! :-D Now it's too late at Spain, but i promise i'll try it tomorrow!!! :-)

Sended from my Android cell phone, please sorry the lack of format on the text and my fat thumbs :-P

--
You are subscribed to the "python-on-a-chip" (or p14p for short) Google Group.
Site: http://groups.google.com/group/python-on-a-chip

[pir...@gmail.com]

Ok, just a little try here at work (we are at lunch time): it
works!!!! :-D I have been looking at the code for the common place and
i only needed to change pmImgCreator.py shebang from #!/usr/bin/env
python to #!/usr/bin/env python2.6, and now the trace has dissapeared
:-D Dvdnotjon, thank you very much ;-)

Ok, so now i'll go to clean up my code and upload it. It's from the
branch v09, but since it was so easy to solve, i don't think i will
have problems updating it to v10 :-)

2012/2/15 pir...@gmail.com <pir...@gmail.com>:

--

[Dean Hall]

Python 2.6 is REQUIRED at this time.

Python 2.7 has bytecodes that are NOT supported. CPython 2.7's bytecodes are similar to CPython 3.0 and I tried to port to CPython 3.0, but ran into a wall (details are here: http://code.google.com/p/python-on-a-chip/issues/detail?id=14 see, especially, the attachment: dwh-WhyNotPython30.txt )

!!Dean

[pir...@gmail.com]

> Python 2.6 is REQUIRED at this time.
>

I think it would be an interesting thing to have it in huge words in a very visible place like the main page of the readme files... ;-) And if it's there yet, my apologices, i didn't saw it :-(

> Python 2.7 has bytecodes that are NOT supported.  CPython 2.7's bytecodes are similar to CPython 3.0 and I tried to port to CPython 3.0, but ran into a wall (details are here: http://code.google.com/p/python-on-a-chip/issues/detail?id=14  see, especially, the attachment: dwh-WhyNotPython30.txt )
>

Good forensics! :-D Would you be able to take a look for 2.7? Python 3 is desirable (and with compile time modulable unicode support would be a plus :-P), but i think a full fledget Python 2.7.2 would be a good treat being the last of the 2.x series if it's not so much difficult to add support for it... :-)

[Dean Hall]

I am mistaken, CPython 2.7 does not have the LOAD_BUILD_CLASS bytecode that held me back from porting to CPython 3.1. I will look into CPython 2.7 to see if it adds features that are useful.

!!Dean

[pir...@gmail.com]

> I am mistaken, CPython 2.7 does not have the LOAD_BUILD_CLASS bytecode that held me back from porting to CPython 3.1.  I will look into CPython 2.7 to see if it adds features that are useful.
>

Ok ;-) Here you have a rat lab to experiment if you need it... :-D