Hey
On Wed, Jan 08, 2014, Thomas Preud'homme wrote:
> So you'll be happy to hear that support for armhf will be greatly improved in
> upcoming tcc release (there was quite some bug in the current version).
Nice :-)
> However I still encounter a problem that when both armel and armhf libraries
> are installed, ldd shows that armel one are used. I tried playing with EABI
> version (set it from 4 to 5) but then ldd says the file is not a dynamic
> binary.
Interesting; this might be worth raising on debian-arm@; I think there's
another ELF header that one has to set to indicate the hard-float
variant of EABI; Steve McIntyre had worked on this some while ago.
> > 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.
>
> You'll also be happy to hear that there is progress on this front. I've just
> pushed a patch to be able to select the float ABI at runtime. For now it's
> limited to softfp and hard since soft is not supported now (as you noticed,
> tcc produces VFP code even on armel). Supporting ARMv4…ARMv7 as well as
> Thumb/ARM will not be done neither since tcc is not an optimizing compiler.
> ARMv4 is always used, no matter what. On the other hand I'd like to be able
> to
> select the ABI (OABI Vs EABI) at runtime as well but it requires a bit more
> change as for now this switch relies heavily on macros.
Note that OABI is probably not interesting anymore at this point;
support for OABI will progressively be removed, so likely not worth
targeting in a compiler right now.
BTW you mention TCC uses VFP instructions: note that usage of VFP
instructions is not equal to ABI; that is, you may use soft-float
calling conventions while using VFP instructions between calls. In fact
you may even use hard-float calling conventions in a soft-float library
/ binary as long as you're calling into the same compiled code and not
calling into another object.
GCC offers these three options to distinguish the use cases:
* hardfp: might use VFP depending on optimization levels; always calls
functions in other object files with hard-float calling conventions
but might call with soft-float calling conventions within the same
object
* soft: never uses VFP, always calls functions with soft-float calling
conventions
* softfp: might use VFP, always calls functions in other object files
with soft-float calling conventions but might call with hard-float
calling conventions within the same object
And it allows selecting the VFP level independently.
> You must realize that the manpower on tcc is quite small so we are limited in
> what we can add to tcc. I myself have been more versed in bug fixing as they
> are many.
Understood :-)
Cheers and happy new year!
--
Loïc Minier
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
