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
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
