CEXP on ARM

[Till Straumann]

Jay Monkman wrote:
> Till,
> 
> I want to use your CEXP stuff on ARM. I downloaded 1.5, and I'm having some
> problems.
> 
> If I build it the host demo, I get this when I run it:
> 	11:08:32:.../cexp/cexp-1.5> cd build-host/
> 	11:08:37:.../cexp-1.5/build-host> ./xsyms cexp cexp.sym
> 	11:08:44:.../cexp-1.5/build-host> ./cexp -s cexp.sym
> 	opening object file: No such file or directory

Cexp searches the PATH for all object files including the symbol table.
Your PATH probably doesn't contain '.' --> try
   ./cexp -s ./cexp.sym

> 	Unable to load system symbol table
> 	usage: ./cexp [-h] [-v] [-d] [-s <symbol file>] [-a <cpu_arch>] [<script file>]
> 	       C expression parser and symbol table utility
> 	       -h print this message
> 	       -v print version information
> 	       -q quiet evaluation of scripts
> 	       -a set default CPU architecture for disassembler
> 	          (effective with builtin symtable only)
> 	       -d enable parser debugging messages
> 	       Author:    Till Straumann <strauman@@slac.stanford.edu
> 	       Licensing: EPICS open license - consult the LICENSE file for details
> 
> 
> 
> When I try to build it for ARM, it doesn't compile I get this error:
> 	11:10:22:.../cexp-1.5> make cross-arm-rtems4.7
> TGT_CONFIG_OPTS='--prefix=/home/jtm/Projects/tqi/rtems/install'
> 	...
> 	make[3]: Entering directory
> `/home/jtm/Projects/tqi/rtems/cexp/cexp-1.5/build-arm-rtems4.7/libtecla'
> 	make[4]: Entering directory
> `/home/jtm/Projects/tqi/rtems/cexp/cexp-1.5/build-arm-rtems4.7/libtecla'
> 	mkdir normal_obj
> 	cp ../../libtecla/keytab.h normal_obj/keytab.h
> 	arm-rtems4.7-gcc -c -O  -DPACKAGE_NAME="" -DPACKAGE_TARNAME=""
> -DPACKAGE_VERSION="" -DPACKAGE_STRING="" -DPACKAGE_BUGREPORT="" -DSTDC_HEADERS=1
> -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1
> -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1-I../../libtecla/../ -o
> normal_obj/getline.o ../../libtecla/getline.c
> 	../../libtecla/getline.c:73: error: static declaration of 'sigismember' follows
> non-static declaration
> /opt/ldtools/rtems4.7/lib/gcc/arm-rtems4.7/4.0.1/../../../../arm-rtems4.7/include/sys/signal.h:150:
> 	error: previous declaration of 'sigismember' was here
> 	../../libtecla/getline.c: In function 'gl_read_character':
> 	../../libtecla/getline.c:2464: warning: passing argument 3 of 'tcsetattr'
> discards qualifiers from pointer target type
> 	make[4]: *** [normal_obj/getline.o] Error 1
> 	make[4]: Leaving directory
> `/home/jtm/Projects/tqi/rtems/cexp/cexp-1.5/build-arm-rtems4.7/libtecla'
> 
> 
> So it looks like libtecla is defining a function in newlib? Unfortunately, their
> implementations differ. If I comment out tecla's sigismember(), it builds (but I
> haven't tested it yet).

I think this could be OK. You will be using the rtems/posix API version.
I renamed the tecla version to my_sigismember and then use a macro
#define sigismember my_sigismember
inside 'getline.c'. Will be fixed in the next version.

Be prepared for a lot of 'name clashing' warnings. I have to rename the
'cexp' main entry point since it clashes with posix cexp (shame on me).

I have not tested CEXP on an ARM yet but I'm interested in the outcome
and certainly willing to help.

There is one thing you probably have to add: macros for dealing with the
cache. Edit 'bfdstuff.c' and search for where 'FLUSHINVAL_LINE' &friends
are defined:

a) Add a test for your CPU (#elif defined(xxx))
b) define CACHE_LINE_SIZE (if there are different flavors of your CPU 
define to the smallest)
c) add definition for FLUSHINVAL_LINE(addr).
    It is important on machines with separate data and instruction
    caches. It should make sure the cache line starting at 'addr' is
    written from the data cache into memory and invalidated in the
    instruction cache. So that the next instruction fetch from 'addr'
    finds the new text there...
d) add definition for FLUSHFINISH(). This can be a synchronization
    instruction to enforce completion of a preceding cache flushing
    operation.

HTH

-- T.

> 
> Do you have any suggestions?
> 
> Thanks.