mirabilos added the comment:

@skrah: “I don't think we should support this platform officially.”

Please don’t break what works. We have almost complete (about three quarters of 
roughly 10'000 source packages) Debian unstable working on m68k, with several 
versions of Python in use. Thanks!

@pitrou: “x86 can align on a byte boundary and doesn't trigger the assert.”

That’s because most compilers on i386 do “natural alignment” – in fact, most 
compilers on most platforms do. “natural alignment” means 4-byte quantities get 
aligned on 4-byte boundaries, 8-byte quantities on 8-byte boundaries, etc.

On m68k, the lowest alignment for almost all larger-than-a-byte data types is 2 
byte, even though that one is strict. This means that, for example, an int is 
often only 2-byte aligned.

@alanh: “GCC has the -malign-int but mentions this isn't in best interest of 
m68k ABI compatibility if it's used.”

Indeed, because that would break the C and kernel/syscall ABI.

@all: what _precisely_ is the assertion needed to check for?

@pitrou: “since it is there to warn about misalignment on platforms which *are* 
alignment-sensitive”

Well, m68k is. Just the numbers differ. (It also has int, long and pointer at 
32 bit.)

We had a similar issue in the Linux kernel, where it used the lower two bits of 
an address for flags (urgh…) which could only be solved by using GCC’s 
__attribute__((__aligned__(4))) on the quantities in question, but that may or 
may not be the required case here, which is why I’m asking.

I can test any trees on my VMs, but that takes a day or two, of course, at 
50-200 BogoMIPS. You can do that yourself by running a VM as well, the Debian 
Wiki has instructions, if anyone is interested.

Otherwise, it’ll just get tested as soon as it hits Debian (unstable, usually 
we don’t build experimental packages except on explicit request by the 
packagers, due to lack of time / horsepower)…

Thanks doko for linking this issue!

----------
nosy: +mirabilos

_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue17237>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Reply via email to