On Tue, Oct 18, 2011, Thomas Preud'homme wrote:
> > TCC itself will build fine on armel and armhf using their calling
> > conventions for the tcc binary itself; the code generated by tcc
> > however depends on which architecture it was built on and currently
> > seems to only support the arm and armel cases (OABI and EABI with or
> > without VFP code, but soft-float calling conventions).
> Ah ok, I see my mistake. I saw it only as optimisation but completely forgot
> it's an ABI change. Maybe it's not too much work then. Unfortunetely I will
> not have time to look into it in the next weeks. But I'll try to look at it
> as
> soon as possible.
Note that one can still generate code using VFP instructions on armel,
which is what gcc does (it's called softfp in gcc speech). I believe
that's what tcc does on armel today when built on a buildd with VFP.
> > BTW, this will likely cause issue in the future as armhf might remove
> > /lib/ld-linux.so.3 (it's using the multiarch path instead of this one).
> Ok, this is a much easier change. I didn't know the linker itself could be in
> a multiarch path. Isn't the multiarch triplet Debian specific (as opposed to
> the GNU triplet)?
GNU triplets are tricky: i386-linux-gnu and i486-linux-gnu are actually
the same ABI, but with different levels of optimizations and ISA
requirements (but you can call i386-linux-gnu libraries from
i486-linux-gnu ones and vice-versa). arm-linux-gnueabi unfortunately
doesn't say whether it's hardfp or soft float or softfp; upstreams says
that this is because the same arm-linux-gnueabi toolchain can generate
soft/softfp/hard-float code.
At some point, multiarch triplets were specified and proposed to have
one unique triplet per ABI in an OS vendor neutral way, but the dpkg
maintainers proposed using the oldest CPU of a family as an unique
triplet instead of multiarch triplets, and creating new ones where
missing, so we now have i386-linux-gnu for the Debian i386
architecture, arm-linux-gnueabi for armel and arm-linux-gnueabihf for
armhf and we're hoping other distros will follow this convention.
Concerning EABI, it mandates /lib/ld-linux.so.3 for both armel and
armhf but because the pathname is already used for armel and armhf was
the new port and multiarch was around the corner, the plan is to use
/lib/arm-linux-gnueabihf/ld-linux.so.3 for armhf. That violates EABI,
maybe we'll get it updated someday to allow for two different runtime
linkers for armel and armhf to be installed at the same time (like
amd64's ld-linux-x86-64.so.2.
> Actually tcc can do cross-compilation. The Makefile is planned to be able to
> build ${arch}-tcc binaries for this purpose. Maybe one day I'll build a tcc-
> cross package for that but that's quite far on my TODO list to be honest.
> I'll
> talk to upstream about selecting the ABI, I don't know how he will react to
> this.
Ok; well IMHO the current cpuinfo checks in Makefile for ARM are bad;
this should be specified by the end-user entirely. It's fine to
autodetect the default though, but it's quite important for a C
compiler's optimization level to be well defined because one might be
building armel binaries on an ARMv7 buildd but running them on an ARMv5
machine, or one might be cross-compiling; also consider builds in a
QEMU linux-user chroot where cpuinfo relates to the build environment,
not the host one :-/ the QEMU case is a bit extreme though
I'm not sure how tcc bootstraps itself, maybe it's always built with
gcc or maybe it's building itself once with gcc each time the package
is built, and then a second time with a bootstrap tcc, or maybe it's
bootstrapped in other ways (e.g. manually). In any case, perhaps a
better source for the defaults is the toolchain used to build tcc, that
is if I build tcc with a gcc targetting ARMv5 + VFP and soft-float
calling convention, then maybe tcc should detect and use this as a
default configuration? That's the recommended practice for other
non-compiler packages so that one can just change the toolchain default
targets and rebuild the archive to get optimized binaries -- of course
that doesn't work across ABI changes.
> It would be fine if tcc was only a normal compiler. Unfortunetely tcc also
> support executing source code via -run switch. This would then be broken
> since
> it doesn't generate code in the correct ABI. Actually tcc would act as a
> cross
> compiler in this case and packaging it as tcc would be misleading. So I'll
> add
> armhf when this bug will be solved.
Makes sense; thanks!
--
Loïc Minier
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
