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

[Pavel Pisa]

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.

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.
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).

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.

Best wishes,

             Pavel