Problem to resolve "sqrt" symbol from shell/main_ping.c for lpc17xx_ea_ram BSP

[Chris Johns]

On 2/10/2014 6:53 pm, Pavel Pisa wrote:
> Hello Chris,
>
> thanks for confirmation.
>
> On Thursday 02 of October 2014 05:34:25 Chris Johns wrote:
>> On 2/10/2014 11:57 am, Pavel Pisa wrote:
>>> Error reported
>>>
>>> /opt/rtems4.11/arm-rtems4.11/lpc17xx_ea_ram/lib/librtemscpu.a(libshell_a-
>>> main_ping.o): In function `g_finish':
>>> /home/pi/repo/rtems/build/arm-lpc17xx_ea_ram/rtems/arm-rtems4.11/c/lpc17x
>>> x_ea_ram/cpukit/libmisc/../../../../../../../../git/rtems/c/src/../../cpuk
>>> it/libmisc/shell/main_ping.c:1642: undefined reference to `sqrt'
>>> collect2: error: ld returned 1 exit status
>>> make[3]: ***
>>> [/home/pi/repo/rtems/build/arm-lpc17xx_ea_ram/omk-template/_compiled/lpc1
>>> 7xx_ea_ram/bin/appnet] Error 1 make[2]: *** [binary-pass-this-dir] Error 2
>>> make[1]: *** [binary-pass-appnet-subdir] Error 2
>>> make: *** [binary-pass] Error 2
>> ....
>>> gcc-4.9.1/gcc/config/rtems.h
>>>
>>> #undef LIB_SPEC
>>> #define LIB_SPEC "%{!qrtems: " STD_LIB_SPEC "} " \
>>> "%{!nostdlib: %{qrtems: --start-group \
>>>    -lrtemsbsp -lrtemscpu \
>>>    -lc -lgcc --end-group %{!qnolinkcmds: -T linkcmds%s}}}"
>>>
>>> If float funtions support is needed by rtems core libraries then
>>> "-lm" or "libm.a" has to be included in this define.
>> ...
>>> The problem is caused by "ping" statistic/standard deviation computation
>>> in there
>>
>> It is and it was a mistake on my part. My zynq testing has a NEON and
>> -lm was being linked so I was not aware of the issue.
>
> The -lm does not help for soft-float targets because it is processed
> before qrtems group (even if put as the last option to GCC driver)
> because arguments are reorganized before passing to collect2
> and even if -qrtems is far before -lm on command line it appears
> in reverse order. What helps is to explicitly add -lrtemsbsp -lrtemscpu -lm
> on application link command line. I.e.
>
> arm-rtems4.11-gcc --pipe -B/opt/rtems4.11/arm-rtems4.11/lpc17xx_ea_ram/lib/ \
>    -specs bsp_specs -qrtems -march=armv7-m -mthumb \
>    -I /home/pi/repo/rtems/build/arm-lpc17xx_ea_ram/omk-template/_compiled/lpc17xx_ea_ram/include \
>    -Wall -O2 -g    init.o task_1.o \
>    -L/home/pi/repo/rtems/build/arm-lpc17xx_ea_ram/omk-template/_compiled/lpc17xx_ea_ram/lib \
>    -lnfs -lrtemsbsp -lrtemscpu -lm \
>    -o /home/pi/repo/rtems/build/arm-lpc17xx_ea_ram/omk-template/_compiled/lpc17xx_ea_ram/bin/appnet
>
> But sqrt is translated to FSQRTD instruction on Zinq most probably
> or can be part of arch specific/optimized libgcc with hard float in
> the worst case which is in search group.
>
>>> cpukit/libmisc/shell/main_ping.c:1642
>>>
>>> 	if (nreceived && timing) {
>>> 		double n = nreceived + nrepeats;
>>> 		double avg = tsum / n;
>>> 		double vari = tsumsq / n - avg * avg;
>>> 		(void)printf(
>>> 		    "round-trip min/avg/max/stddev = %.3f/%.3f/%.3f/%.3f ms\n",
>>> 		    tmin, avg, tmax, sqrt(vari));
>>> 	}
>>>
>>> I expect that problem can be hidden on hardware floating point
>>> targets because sqrt is inlined/translated directly to FPU
>>> instructions.
>>>
>>> If the politics is not to require/pull in FPU support for core
>>> libraries then I suggest to replace whole statistic computation
>>> by fixed point/fraction based code or at least use integer/long based
>>> sqrt replacement.
>>
>> Or just remove the need for the stddev. Is it really needed ?
>
> What is policy of shell regarding floating-point task mode
> requirement. I know that RTEMS setups float context to all
> tasks on many architectures now but if there architectures
> with hard float which can declare task lightweight without
> FPU context then this requirement for shell should be
> declared in changelog and documentation.

Good question. I do not know. I suppose by default no commands provided 
by RTEMS should use floats and it should be disabled.

The shell can be extended by user commands and they may need to use 
floats so I suppose it should be something a user could enable.

>
> On the other hand I am sure if there is any need for double/
> floating point computation in ping at all.
> I think that I can convert all computations to uint64_t
> in nanosecond units and play a little with fraction output
> to have exactly same output as actual float based code.

This would be fantastic. It should not need any FPU support.

> I have even implemented fast 64-bit integer square root
> for some our motion control systems so it can be used
> there. (I am not aware of integer square root in C99 standard
> but if it is there then even better).

Lets leave it out. The ping command is not fully functional and so 
spending extra efforts is not really worth it.

>
> If you think that this is the right way to move then I hope
> to find time to do that. But probably after October 12
> because we are really busy with presentation/demonstration
> preparation for Real-Time Linux Workshop in Dusseldorf now.
>

I understand. I am buried at the moment and will be until next week.

Chris