Le mardi 18 octobre 2011 16:27:46, Loïc Minier a écrit : > 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). 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. > > > > 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). 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)? > > > 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. Ok great, this will help me *a lot*. Thanks for the pointers. > > 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. :-) 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. > > > 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.
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. Thanks for your input. Best regards.
signature.asc
Description: This is a digitally signed message part.
