Platforms with 16-bit int
#17537
Replies: 1 comment
-
I did file an issue #17540 -- in the related branch, which I haven't PR'd yet, an I16LP32 build also works much better. See the issue for more info. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
During some of my work on mpprint, we discussed the use of flags passed as
unsigned
. The C standard only requires this type to be 16 bits, and apparently this is actually the case in thepic16bit
port.Unfortunately, the pic16bit port is not even compile-tested during CI because it requires a non-free toolchain. So, I set out to see if there WAS a toolchain that could work that way and might be able to build & run during CI.
Long story short(-ish): m68k gcc with
-mshort
makes int 16 bits. The linux/libc headers are totally broken in this mode, because they unconditionally typedefunsigned int uint32_t
. So, I built my own gcc and newlib-based runtime that can run under qemu-m68k. And some basic things, such as>>> 3+3
(prints6
) actually work!however I very quickly run into problems. I'm not opening this as an issue because at the moment nobody else could reproduce it, and I'm not convinced it's not a problem in my toolchain. However, I think the problem is in the micropython core.
Here, micropython is trying to print the
int
type itself, but it's about to crash instead:In
type_print
,self->name
is of typeunsigned short
. A short is promoted to int (also 16 bits) and then it becomes part of the...
args inmp_vprintf
.In
mp_vprintf
, an argument is retrieved withqstr qst = va_arg(args, qstr);
butqstr
issize_t
, a 32-bit type.This is undefined behavior, but the concrete behavior here is that it got back a 32-bit value that combines the correct value (0x5e in the high bits) with some unrelated values from the stack (0x3faf in this case).
Upon continuing, an assertion error occurs:
So I'm asking myself "how did this ever work" but with a side helping of "wait, how do LP64 platforms work" because again sizeof(size_t) will be different than sizeof(int).
I went and wrote a godbolt.. https://godbolt.org/z/nrj6xa8er
with x64 msvc v19.43, this prints
so it "works, kinda, sometimes, maybe due to luck". I have a sinking feeling that if there were a printf with 4
%q
arguments it might just fail on x64 windows.Beta Was this translation helpful? Give feedback.
All reactions