search

danicampora / micropython

The Micro Python project
MIT License
1 stars 1 forks source link

Using 'MICROPY_LONGINT_IMPL_LONGLONG' corrutps the stack #5

Closed danicampora closed 9 years ago

danicampora commented 9 years ago

@dpgeorge @pfalcon I was trying to use MICROPY_LONGINT_IMPL_LONGLONG for the CC3200 port (the compiled code size is around 1K less), but as soon as an integer needs to be returned by python, the software crashes with a hard fault, probably because of a stack corruption because I am not able to get any useful information from the stack dump in the hard fault handler. Is it possible that I have some incompatible settings in my "mpconfigport.h'? If you have any insights please let me know. Thanks!

pfalcon commented 9 years ago

No idea. Try to reproduce this on a host?

danicampora commented 9 years ago

Thanks for the quick reply. I will try tomorrow on Linux and on the stmhal board. I am going to bed now...

Sent from my iPhone

On Dec 21, 2014, at 11:29 PM, Paul Sokolovsky notifications@github.com wrote:

No idea. Try to reproduce this on a host?

— Reply to this email directly or view it on GitHub.

dpgeorge commented 9 years ago

esp8266 port uses LONGLONG, and, as far as I can remember, works fine.

pfalcon commented 9 years ago

Well, got one idea - compiler might use LDRD/STRD instruction to access long long, and that might have 8-byte alignment restriction (this would vary on core type by core type basis), whereas we definitely don't have it.

danicampora commented 9 years ago

The fault register from the CC3200 tells me that is not due to a unaligned access, in fact I also tried compiling with '-mno-unaligned-access ' and the results are exactly the same.I found that the code crashes in "objint.c" line: 184 {int c = num % base;}, and when stepping into the dissasembly the problem is inside some divide function of the builtin libraries of the compiler... I hate this kind of things...

By the way, after playing a bit with the compiler options, I am now getting several repetitions of this warning from the linker:

"warning: .... uses 32-bit enums yet the output is to use variable-size enums; use of enum values across objects may fail"

Any clue?

On Sun, Dec 21, 2014 at 11:58 PM, Paul Sokolovsky notifications@github.com wrote:

Well, got one idea - compiler might use LDRD/STRD instruction to access long long, and that might have 8-byte alignment restriction (this would vary on core type by core type basis), whereas we definitely don't have it.

— Reply to this email directly or view it on GitHub https://github.com/danicampora/micropython/issues/5#issuecomment-67788880 .

dpgeorge commented 9 years ago

and when stepping into the dissasembly the problem is inside some divide function of the builtin libraries of the compiler.

Well, this will be a modulo operation on a long long, which could possibly be buggy.

"warning: .... uses 32-bit enums yet the output is to use variable-size enums; use of enum values across objects may fail"

That should be ok, since we don't need full 32-bits for enums. This warning should go away if you compile uPy source code with the same options as the other parts of the code.

danicampora commented 9 years ago

Thanks for the reply. I already got the warning gone, but the hardfault is still there, so I will stick to MPZ for now.

On Dec 22, 2014, at 2:18 PM, Damien George notifications@github.com wrote:

and when stepping into the dissasembly the problem is inside some divide function of the builtin libraries of the compiler.

Well, this will be a modulo operation on a long long, which could possibly be buggy.

"warning: .... uses 32-bit enums yet the output is to use variable-size enums; use of enum values across objects may fail"

That should be ok, since we don't need full 32-bits for enums. This warning should go away if you compile uPy source code with the same options as the other parts of the code.

— Reply to this email directly or view it on GitHub.

danicampora commented 9 years ago

This was a linker issue.