Re: ARM EABI port: minimum CPU choice
Riku Voipio wrote:
Since maemo atleast already compiles some of their apps and libs with
thumb code.
That is irrelevant. "Maemo is the application development platform for
the Nokia 770 Internet Tablet" which runs something called "Internet
Tablet OS 2006". We do not need to be able to install Nokia Tablet
binaries into ARM Debian systems or vice versa, and they wouldn't work
anyway.
Anyway, your view (Riku) is coloured by the fact that you are trying
to make the armel port with the emdebian people and your personal
hobby-horse scratchbox, you already have a half-baked repository of
"armel" binaries compiled for armv5t using the CodeSourcery compiler,
and are in a hurry to get something (*anything!*) working as soon as
possible for some reason. Sadly your haste has produced a repository
of 147 random packages but no libc6 package (!). I don't see how it
can work. libc comes first along with a working toolchain as I
understand it, and everything else depends on libc.
My question is about the ARM Debian distribution, not emdebian, and
whether we can satisfy the specific Debian policy "Debian runs on as
wide a range of hardware as possible" without wasting time and
creating danger of bugs by modifying GCC just to support what seems to
me to be a minor feature of very little value -->in the context of
mainline Debian<--. emdebian devs and users will always have their own
optimised repositories for their specific devices.
ARM Debian for ARM is the Debian system compiled for ARM
processors, not something special and different tailored for tiny
systems and the latest cellphones. It should run the same as it does
on all the other processors, and it should run the same on all the ARM
processors that it can support, which is armv4 and above.
The "armv4 thumb interwork compatability" trick is cute, but it
requires getting armv4t instructions (BX) through GCC and the
assembler while they are running in compile-for-armv4 mode among other
difficulties. It's nice in theory but is still far from ideal, and I
see trouble and brokenness forever down that path, while pure armv4
without thumb interworking will work faster on every processor.
In fact, one way to make sure that the Debian does run properly on as
many ARM CPUs as possible is to mandate armv4 and ban Thumb. Thumb
also creates the risk of making packages that work on the dev system
they're compiled on but don't work on half the ARM processors out
there in the real world - something that seems to have happened
already to the current ARM port (on armv4t, firefox bombs with
"illegal instruction" on ARMv4t, and aptitude segfaults at random)
Oh, and Paul, yes, I'm sure thumb and thumb2 are whizzo when people
are compiling for a specific small device, which is what CS customers
do on the whole, but my question remains "is Thumb compatibility
really worth all the trouble and risk and bloat in the context of
generic Debian?" I think not.
M
Reply to: