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

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

[Chris Johns]

On 2/10/2014 11:57 am, Pavel Pisa wrote:

Hello all,

when have tested recent master branch (fbe59f7c6756edc2952b13167893b85fe6e7aecb)
build configured for lpc17xx_ea_ram BSP, I am experiencing next error for my
code with networking enabled. It seems to be related to add of ping command.

Even addition of -lm to my LDFLAGS does not help

GCC call from OMK based makefile

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
 \
   -lbar -lnfs -lm  -o 
/home/pi/repo/rtems/build/arm-lpc17xx_ea_ram/omk-template/_compiled/lpc17xx_ea_ram/bin/appnet

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/lpc17xx_ea_ram/cpukit/libmisc/../../../../../../../../git/rtems/c/src/../../cpukit/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/lpc17xx_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

I have investigated how collect is called and even tried to modify it by adding 
libm.a

/usr/arm-rtems4.11/gcc/4.9.1/bin/../libexec/gcc/arm-rtems4.11/4.9.1/collect2 \
   -dc -dp -N -o 
/home/pi/repo/rtems/build/arm-lpc17xx_ea_ram/omk-template/_compiled/lpc17xx_ea_ram/bin/appnet
 \
   /opt/rtems4.11/arm-rtems4.11/lpc17xx_ea_ram/lib/start.o \
   
/usr/arm-rtems4.11/gcc/4.9.1/bin/../lib/gcc/arm-rtems4.11/4.9.1/thumb/armv7-m/crti.o
 \
   
/usr/arm-rtems4.11/gcc/4.9.1/bin/../lib/gcc/arm-rtems4.11/4.9.1/thumb/armv7-m/crtbegin.o
 \
   -e _start \
   
-L/home/pi/repo/rtems/build/arm-lpc17xx_ea_ram/omk-template/_compiled/lpc17xx_ea_ram/lib
 \
   
-L/usr/arm-rtems4.11/gcc/4.9.1/bin/../lib/gcc/arm-rtems4.11/4.9.1/thumb/armv7-m 
\
   
-L/usr/arm-rtems4.11/gcc/4.9.1/bin/../lib/gcc/arm-rtems4.11/4.9.1/../../../../arm-rtems4.11/lib/thumb/armv7-m
 \
   -L/opt/rtems4.11/arm-rtems4.11/lpc17xx_ea_ram/lib 
-L/usr/arm-rtems4.11/gcc/4.9.1/bin/../lib/gcc/arm-rtems4.11/4.9.1 \
   -L/usr/arm-rtems4.11/gcc/4.9.1/bin/../lib/gcc \
   
-L/usr/arm-rtems4.11/gcc/4.9.1/bin/../lib/gcc/arm-rtems4.11/4.9.1/../../../../arm-rtems4.11/lib
 \
init.o task_1.o -lbar -lnfs \
/usr/arm-rtems4.11/lib/thumb/armv7-m/libm.a \
--start-group -lgcc --start-group -lrtemsbsp -lrtemscpu -lc -lgcc 
--end-group \
-T /opt/rtems4.11/arm-rtems4.11/lpc17xx_ea_ram/lib/linkcmds --end-group \

/usr/arm-rtems4.11/gcc/4.9.1/bin/../lib/gcc/arm-rtems4.11/4.9.1/thumb/armv7-m/crtend.o
 \

/usr/arm-rtems4.11/gcc/4.9.1/bin/../lib/gcc/arm-rtems4.11/4.9.1/thumb/armv7-m/crtn.o

What seems to be problem cause is the fact, that bsp_specs adds libraries
group including librtemscpu.a after libm.a. Because libm.a is not in the group
then repeated search for sqrt() is not run after ping inclussion.
Adding libm at the end of manually crafted collect2 line helps

/usr/arm-rtems4.11/lib/thumb/armv7-m/libm.a

Sequence of link specification

%{qrtems: --start-group  -lrtemsbsp -lrtemscpu  -lc -lgcc --end-group %{!qn

is compiled in GCC driver /usr/arm-rtems4.11/gcc/4.9.1/bin/gcc, which is
defined in GCC sources

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.



This is a great summary of the issue. We really cannot change this as it 
stands until after 4.11 is released.



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.




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