On Mon, Oct 17, 2011, Thomas Preud'homme wrote:
> > It would be nice if TCC supported the hard-float ABI used on armhf
> > (uses the FPU regs to pass floating point values).
> My question might be stupid but are you talking about the code tcc generate
> or
> the code in which tcc is compiled? I guess you're talking about the code in
> which tcc itself is compiled since tcc has only one ABI for generated code as
> far as I know.
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).
> > In fact, it would be nice if TCC allowed selection of the ARM ABI it's
> > targetting, e.g. ARMv4...ARMv7, Thumb/ARM mode, OABI vs. EABI, soft VFP
> > / hard VFP / no VFP.
> >
> > (Note that currently the supported ABI is the one of the buildd, which
> > might be higher than the base requirement to run the Debian port.)
> I guess you are refering to the line
> NATIVE_DEFINES+=$(if $(shell grep -l "^Features.* \(vfp\|iwmmxt\) "
> /proc/cpuinfo),-DTCC_ARM_VFP)
> in Makefile. Did I miss some other line?
That's what tailors the tcc build to target this or that ABI, yes;
actually there are two defines:
NATIVE_DEFINES+=$(if $(wildcard /lib/ld-linux.so.3),-DTCC_ARM_EABI)
NATIVE_DEFINES+=$(if $(shell grep -l "^Features.* \(vfp\|iwmmxt\) "
/proc/cpuinfo),-DTCC_ARM_VFP)
As EABI mandates /lib/ld-linux.so.3.
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).
> I would happily work on it as I'm myself using armhf since recently but I
> don't know enough about the different ARM ABI so could you suggest me a list
> of
> ABI and the feature I should put inside (or point me to a documentation for
> this second part)?
With pleasure; the only other ABI that tcc doesn't support at build
time is the EABI hard-float variant; that's like soft-float, except
that when you call functions with float arguments, you pass them via
FPU registers rather than serialized as VFP on the stack. This calling
convention is described in the EABI spec, I think it's called "AAPCS",
it's what you get when calling gcc with -mhard-float on armel or what
you get by default on armhf.
Some information about the armhf port is at:
http://wiki.debian.org/ArmHardFloatPort
and the armel port was the one introducing EABI in Debian:
http://wiki.debian.org/ArmEabiPort
this second page has links to some version of the specs at the bottom
of the page.
It would be good if tcc was using if()s rather than #ifdefs, as to
select the ABI at runtime rather than build-time, but I don't know
whether tcc is expected to support that. It doesn't seem to be meant
to do weird things like cross-compilation either. :-)
> By the way, should I wait for this bug to be solved before adding armhf to
> the
> list of supported architecture as requested by you in bug #645673 or directly
> upload with armhf enabled and work in a second time on this issue?
Up to you; if you enable armhf in control, it will build and run, but
the generated code will only run on armel AFAICT; that's an acceptable
and useful interim situation, unless packages build-depend on tcc.
--
Loïc Minier
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
