-
Notifications
You must be signed in to change notification settings - Fork 3
RTEMS C Expression Shell
License
epicsdeb/rtems-cexp
Folders and files
Name | Name | Last commit message | Last commit date | |
---|---|---|---|---|
Repository files navigation
What is Cexp? ------------- -- Brought to you by Till Straumann <strauman@slac.stanford.edu> -- -- $Id: README,v 1.25 2009/03/12 17:34:22 strauman Exp $ -- The Cexp utility is a C-expression interpreter which gives its user access to all symbols present in the currently executing program. Its primary target is RTEMS, an open source RTOS, but Cexp should compile and run on virtually any platform supported by the BFD library. If Cexp is linked to an executable, it is possible to invoke arbitrary functions and to read/write variables (and hence virtually any memory location) by interpreting C-style expressions. Cexp can access object files using either the pmbfd/pmelf libraries ('poor-man's BFD) that comes with Cexp or libbfd. The latter is more powerful: - not limited to the ELF object format. - supports many more machine types (pmbfd currently only supports 32-bit powerpc, m68k and i386 and 64-bit x86_64). - using BFD / libopcodes, a disassembler comes for free. Otoh, using pmbfd/pmelf has the following advantages: - much smaller memory footprint. - less restrictive license. Linking against the BFD library is subject to the GPL. See LICENSING below for more information. What is New? ------------ - for later versions, consult the ChangeLog file. - 2003/02/14: CEXP_1.2.beta ("Valentine") released. It supports G++ prioritized execution of static constructors/destructors. - 2003/02/13: CEXP_1.1.beta is released. It fixes a bug of the exception handler registration. Makefile.syms has been added and modularized copies of the RTEMS 'cdtest' sample program. Description ----------- CEXP is a simple utility featuring - symbol table - C expression parser/interpreter - type "engine" - user definable variables - recursive invocation/simple scripts - runtime 'module' loader/linker - disassembler (only if linked with BFD) - CEXP is reentrant Cexp knows about the basic C types (no aggregates), i.e. char, char* short, short* long, long* float, float* double, double* long (*)() double (*)() and interprets C-style expressions, e.g. Cexp> printf("Hello world") Cexp> some_variable = 0xdeadbeef Cexp> some_double_variable = *(double*)&some_variable Cexp> a=printf, a && a("The square root of 2 is %g\n",sqrt(2.0)) Symbol Table ------------ A) Using a Symbol Table File - - - - - - - - - - - - - - - On startup, Cexp reads the 'system' symbol table either from the executable itself, or from a stripped-down '.sym' file - such a stripped-down symbol file can be created using the 'objcopy' (preferred, but needs binutils 2.18 or later) or 'xsyms' (deprecated; comes with Cexp) utilities. B) Builtin Symbol Table File - - - - - - - - - - - - - - - The 'xsyms' tool can be used to generate a symbol table in C-source form for subsequent compilation and linkage into the final executable. This usually involves linking the executable twice: 1) compile and link all sources, libraries etc.; build an executable 2) xsyms -C executable mysymtab.c 3) compile mysymtab.c (set -I to Cexp installation 'include' directory or Cexp source directory, since <cexpsyms.h> is included) 4) link application again, but this time add 'mysymtab.c' to the list of sources. NOTES: Step 1) linking succeeds without a symtab.o because there's a weak NULL-ptr alias for the builtin symtab. When building the demo program you can use a builtin symbol table: a) build demo the normal way (corresponds to step 1 above) b) type 'make builtin-symtab' this extracts symbol table info from the executable created in step a) and creates an object file 'cexp-builtin-symtab.o' (steps 2+3 above). c) type 'make' again. This re-links the demo program now using the 'cexp-builtin-symtab.o' object (corresponds to step 4 above). A similar source file can also be generated using the 'ldep' utility (discussed elsewhere, it is part of RTEMS-GeSys). Without access to a symbol table file which also provides Cexp with information about the architecture it is executing on, Cexp might fail to detect the correct BFD CPU architecture which is needed for the disassembler. In such cases, the '-a' command line option can be used to specify the architecture (arch string can be obtained by running 'objdump -f' on the ELF executable). Symbol Type - - - - - - Once the symbol table is read, Cexp guesses the symbol/variable types from the symbol sizes. (Guess is only supported on ELF targets.) In some cases, this guess is obviously wrong, but you can always cast the symbol to the correct type. Arrays are normally 'void' like every symbol for which's type Cexp cannot make a guess. It is still possible, however, to use such a symbol, simply by taking its address and casting to a different pointer type: Cexp> *(((long*)&some_array)+25) evaluates to the unsigned long array element some_array[25]. Alternatively, you can redeclare its type: Cexp> long *some_array ! Cexp> *(some_array + 25) Note the exclamation mark: terminating a variable declaration with an exclamation mark allows you to redefine its type. Only new variables may be declared without the '!'. This protects you from erroneously use existing symbols. Cexp provides a series of lookup functions for symbols. Most noteworthy: lkup(char *regexp) lkaddr(unsigned long addr) These are just normal C functions which can be invoked by Cexp. Note that lkup() takes a regular expression argument allowing for powerful searching. C-Expression Parser / Interpreter --------------------------------- The C expression parser has some restrictions: - no '?' ':' expression - no [], '->' - the '.' operator has a special meaning - see below - no multilevel pointer dereferencing (since e.g. char** is not a valid type, Cexp cannot dereference **addr. You must explicitly cast this: Cexp> *(char*)*(long*)some_char_pointer_pointer which assumes that sizeof(long) == sizeof(char*) for the particular machine. However, most of the other operators are available, including the 'comma' operator and the logical '&&' and '||' with the correct semantics, i.e. conditional evaluation of expression parts e.g. Cexp> (dd=deviceDetect(_some_device_address)) && driverInit(dd) will call the driverInit() function only if deviceDetect() returns a nonzero value. The '.' operator (structure field access) has a special meaning to Cexp: symbol "member" (in an OOP sense) access. Currently, the only member function defined is 'help'. Consult the 'Help' section about details. Function calling: The user is responsible for feeding properly typed arguments; unused arguments will be filled with integral/scalar 0, which on most ABIs is safe. Since the symbol table (on ELF, Cexp is not using .stab but .symtab) provides no info about a function's return type, Cexp assumes all functions to return long. Floating point functions must be cast appropriately: Cexp> ((double(*)())sqrt)(2.345) Or Cexp> double (*sqrt)() Cexp> sqrt(2.345) A lot of type casting can be avoided by re-declaring or using user defined variables, see below. Type Engine ----------- Cexp knows about (and only about) the primitive types listed above. NOTE: Cexp treats ALL integral types as UNSIGNED although no 'unsigned' keyword is used or recognized. The main reason for this is to save typing. Hence char is in fact unsigned char etc. An 'int' type is missing (but could easily added) which means that on some machines (e.g. 64-bit cpus) no 32bit type is currently available... User Variables -------------- Cexp supports (fully typed) user variables which are visible in a global namespace (i.e. visible to other instances of Cexp). The name of user variables must not collide with symbols present in the symbol table. (When loading object files [AKA 'modules'], name clashes are ignored. A symbol in a newly loaded module that conflicts with an already defined user variable silently takes precedence [object file symbols have a higher priority than user variables]. However, after unloading the conflicting module, the user variable becomes again 'visible'.) A user variable is created simply by assigning it a value which also automatically defines its type. hallo="hallo" creates a 'char*' and assigns it the address of a string constant. The string is stored in 'malloc()ated' memory and 'lives' forever. Subsequent use of the same string (strcmp(a,b)==0) results in re-using the already stored instance of the string. String constants must not be written-to! The type of user variables can be modifed, simply by re-declaring them, in a C-style manner: long hallo results in 'hallo' maintaining its value (the address of the string constant) but interpreting it as a long. Hence chppt = &hallo is an 'disguised' char** and *(char*)*chppt yields 'h' User variables can also hold function pointers and hence can be handy abbreviations for long names and casts. E.g. a convenient variable can be set for 'sqrt()' (which returns a double value): s=((double(*)())sqrt) It is then possible to automatically get the correct return type: printf("Let's print a double: %g\n",s(44.34)) The special user variable 'ans' stores the result of the last successfully evaluated expression. E.g: Cexp> 3+4 0x00000007 (7) Cexp> ++ans 0x00000008 (8) Cexp> printf("%u\n",ans) 8 0x00000002 (2) Cexp> The 'ans' variable is special in the sense that unlike other user variables it is not global but local to the executing parser, i.e., parsers running in different task contexts each maintain their own instances of 'ans'. Help Facility ------------- The '.' operator (structure field access) has a special meaning to Cexp: symbol "member" (in an OOP sense) access. Currently, the only member function defined is 'help'. I.e. by typing Cexp> some_symbol.help() You get help information about that symbol. If no help is defined, or if you request 'verbose' help: Cexp> some_symbol.help(1) the symbol address, value and type information are printed (same format as the 'lkup' output). You can add/modify help information to a symbol (e.g. a user defined variable) simply by providing a string argument to the symbol's help member: Cexp> long myvar Cexp> myvar.help("I just created a 'long' variable") Note that help is stored 'per symbol', i.e. when creating an 'alias' as in the example above: Cexp> s=(double (*)())sqrt the help information is not propagated to 's'. If 'sqrt' had help information, it would have to be copied: Cexp> s.help(sqrt.help()) This example shows that the return value of the 'help() member' is the address of the (static) help text string. How to Start/Invoke Cexp - Simple Scripts ----------------------------------------- Cexp has two entry points, cexp_main(int argc, char **argv) and cexpsh(char *arg1,...) i.e. a 'main' style and a 'vararg' style. The 'vararg' version ends up building an argument list and calling cexp_main(). It is mainly intended for recursively invoking 'cexpsh()' e.g. for reading a series of lines from a file. Note that the string argument list submitted to cexpsh() must be NULL terminated. When calling cexpsh() from cexpsh() (e.g. to interpret a script), this is not necessary, however, because any unused arguments (up to the internal maximum of 10 args) are filled with zeroes... The calling syntax of cexp_main/cexpsh is as follows: cexpsh [-s <symbolfile>] [-h] [-d] [-q] [<scriptfile>] -h and -d have the obvious effect of printing usage info and enabling debugging information (only available if configured with --enable-YYDEBUG). The -q ('quiet') flag instructs Cexp not to print any normal output (errors are still reported to stderr) on stdout. This behavior can be desirable when evaluating scripts. Note that (unless you are using a built-in symbol table) the -s option MUST be used the first time 'Cexp' is started and it must be provided with an appropriate symbol file. This can be the executable itself of a stripped version (use the 'xsyms' utility) to reduce memory usage and loading time on RTEMS systems. A basic check is made to protect against version mismatch between the symbol file and the executable. Once Cexp has loaded the system's symbol table, further instances will simply use the global system table if the -s argument is missing. Cexp then reads commands from stdin (using the TECLA library) or alternatively from a script file. Cexp ignores any characters present on a line after it scans the comment tokens '#' or '//'. Example for invoking Cexp from Cexp to evaluate a script: Cexp> cexpsh("script_file") While the former syntax involves recursive execution of Cexp, it is now also possible to let the current instance divert its input to read from a script using the '<' operator: Cexp> < script_file There are slight syntactic differences when using this syntax, though. Evaluation of the file name is not performed by the parser but by a simple preprocessor. The filename doesn't have to be embedded in double quotes (but it can be). Note that no escape sequences are recognized. It is possible, however, to use filenames with embedded whitespace by enclosing the script name in single or double quotes. In this case, the entire string between matching quotes is used. E.g., (RHS string delimiter is '"' -- remember that there are no escape sequences...): < a b c --> read from file "a" < 'a b' "c" --> read from file "a b" < "a'b" --> read from file "a'b" < "a\"b" --> read from file "a\\" (a followed by a single backslash) Loadable Modules / Runtime Loader --------------------------------- When built aginst the pmbfd or BFD library, Cexp is capable of dynamically loading object files into a running program. Cexp keeps track of module dependencies. Note that this only covers symbol table dependencies. Cexp rejects unloading a module 'A' if there is still another module, 'B' loaded which had undefined symbols resolved against 'A's symbols. Obviously, more subtle dependencies, such as threads using a modules text or data cannot be tracked easily and are ignored. An object file (AKA 'module') can be loaded invoking the command: Cexp> someModule=cexpModuleLoad("someModule.o") The loader returns a 'module ID', which in this example is stored in the user variable 'someModule'. If errors occur during the load (such as undefined references or multiple symbol definitions), they are reported and a NULL module ID is returned. After loading, C++ static constructors are executed and exception handler frames are registered. Note that these features are probably only supported on ELF and, especially the exception handling, might only work for gcc compiled code. Unfortunately, even different versions of gcc and/or target architectures involve varying implementations of exception handling - YMMV... An (unused) module can be unloaded by passing its ID to cexpModuleUnload() (prior to unloading, the C++ static destructors are executed): Cexp> cexpModuleUnload(someModule) Two more routines are useful in this context: cexpModuleInfo([ID]) prints info about a specific module (ID) or all currently loaded modules if passed NULL ID. cexpModuleFindByName("regexp") searches the list of modules for a regular expression and reports the IDs of all matches. It returns the first ID found (or NULL if there was no match). Search Path for Loadable Modules - - - - - - - - - - - - - - - - - If set, the PATH environment variable is consulted by the loader when it tries to locate object files by subsequently prepending colon-separated search paths as listed in PATH to the file name. The search starts with the first component and stops as soon as the file is found. An empty search path (two colons in a row or a leading or trailing colon) is equivalent to the current directory ('.'). Note that the current directory is not searched if PATH is set but does not contain the CWD. PATH is ignored if the object name contains a (relative or absolute) directory path already. Example: search '/tmp', '/TFTP/BOOTP_HOST/blah/bin' and finally the CWD: setenv("PATH","/tmp:/TFTP/BOOTP_HOST/blah/bin:",1) Building loadable modules - - - - - - - - - - - - - Note the important difference between a run-time loaded/linked object and a _shared_ object (such as a shared library). The latter, although also 'run-time loaded' is different from the former. A shared object is shared among several entities using disjunct address spaces (e.g. different UNIX processes). Supporting shared objects involves PIC and GOTs. *********************************************************** CEXP does _not_ support shared libraries! An attempt to run a loaded module that was compiled with '-fpic', '-fPIC' and/or linked with the '-shared' options will crash hard. *********************************************************** To illustrate the difference, consider a LINUX system running two instances of the 'cexp' demo. 'cexp' is linked against glibc which is a shared library - both instances of 'cexp' use the _same_ copy of libc residing in physical memory. Let's now assume the both of the demo programs issue cexpModuleLoad("someObjectFile.o") Cexp's run-time loader doesn't support shared objects - hence both instances of 'cexp' will end up with their own copy of 'someObjectFile' which will get loaded twice to physical memory. The main target of Cexp is RTEMS, a real-time OS which has a global address space shared by all threads. Hence, there is no need for shared object support but run-time loading code is still very desirable. The Cexp run-time loader simply accepts _any_ relocatable object file. The simplest modules are just object files: cross-gcc -c -O some_object.c Multiple objects can be combined using the '-r' linker option cross-ld -o some_object.o -r some1.o some2.o some3.o It is also possible to convert entire (static) libraries into loadable objects: cross-ld -o lib_object.o -r --whole-archive libSome.a The 'system' symbol table is itself an object file from where Cexp loads the initial symbol table at startup. The executable itself may be used for that purpose (unless it is a pure binary as it is the case on some embedded systems). Alternatively (for saving memory and time), a stripped-down object file containing only the symbol table may be generated using the 'objcopy' tool, e.g: cross-objcopy --extract-symbol cexp cexp.sym cexp -s cexp.sym This requires binutils 2.18 or later. Alternatively, the 'xsyms' utility that comes with CEXP may be used xsyms cexp cexp.sym but this is deprecated. Weak Symbol Support - - - - - - - - - - Cexp can handle weak symbol references (including weak undefined symbols). HOWEVER, this works only one-way: If a module with a strong symbol is already loaded (or if the base system exports a strong definition) then loading a module with a weak reference works as expected, i.e., the references are bound to the existing strong definition. OTOH, if a weak definition exists (either in the system symbol table or a previosly loaded module) then it is NOT possible to load another module with a strong definition. (If you think about it: all relocations of the already linked and loaded stuff would have to be redone -- including the relocations within the base executable...). When a module with a weak undefined reference is loaded then (provided that no existing definition is found in the system or other modules) a new NULL symbol is created which is otherwise treated like a newly defined COMMON symbol. Loadable Modules 'Magic' - - - - - - - - - - - - - When loading modules, 'Cexp' does some magic operations on special symbols it recognizes. Note that the all-capital names given here are macros - the actual names can be found in the header. CEXPMOD_INITIALIZER_SYM (defined in cexpmodP.h), when present in a loaded module, a routine with this name is invoked by cexpModuleLoad() just after calling C++ constructors. This 'module-constructor' routine [for C++ information see below] can be used to initialize a (non-C++) module. CEXPMOD_FINALIZER_SYM, when present in a loaded module, a routine with this name is invoked just prior to calling C++ destructors and unloading the module. The FINALIZER may reject the unloading attempt by returning a nonzero value. CEXP_HELP_TAB (defined in cexpHelp.h). A module may define (multiple) 'help' tables (their name must begin with the magic CEXP_HELP_TAB string) for providing help information about specific symbols contained in a module. See cexpHelp.h for more information about the help information. cexpModuleLoad() automatically registers this data. Building the 'Main' Application - - - - - - - - - - - - - - - - When linking a traditional application, only objects referenced by the application will be linked into the executable. E.g. an application which does not use 'printf()' will not have that routine available. In the normal case, this is fine. When using a runtime loader like CEXP, there arises a problem: imagine you want to load a piece of code which _does_ use 'printf()': - Cexp resolves the module's undefined symbols, encounters 'printf' but doesn't find it in its symbol table - it rejects loading your module. - It is not possible either to simply link your module against libc! The module might reference other libc objects which _are_ present in the application already - Cexp would complain that their symbols are already defined. Therefore, the 'primary' or 'system' application should be built to include ALL parts of the core libraries (such as the C-library, the RTEMS executive managers etc.) which will possibly be used by modules loaded into the running system. Hence, there is a new task for the system designer which (for a statically linked application) would be automatically performed by the linker: You must now tailor/configure the core parts of your system. This is essentially a memory/functionality tradeoff (Sidenote: vxWorks is configured in such a way, too). This 'tailoring' essentially means that you have to tell the linker what parts of the basic system libraries (RTEMS managers, CPU/BSP support, libc, networking etc.) should forcibly be included into the link. Note that it is only necessary to take into account the libraries needed by CEXP and the OS itself during this process. Any library CEXP does _not_ depend on, directly or indirectly, can of course be dynamically loaded any time later. A new tool 'ldep' is available greatly alleviating the task of analyzing link file interdependency and generating symbol lists etc. It is available as part of the 'GeSys' package (www.slac.stanford.edu/~strauman/rtems/gesys) and comes with more documentation. Some info is available here: http://www/~strauman/rtems/epics/README.config Using the Parser from a Program - - - - - - - - - - - - - - - - In some cases, you might want to access/use symbols in loaded modules from a program rather than through the Cexp shell or a shell script. If the module providing the 'caller' is loaded after the module defining the 'callee' this is transparent. E.g., let a module 'A' define a function 'a()' and module 'B' define a routine 'b()' which shall call 'a()'. If module 'A' was loaded before 'B' then Cexp's linker will resolve the reference and no special treatment is required. If, however, module 'B' must for some reason be loaded before 'A' then 'B' cannot simply call 'a()' since that would result in a linker error. Here's how you can load a module from a program and use symbols exported by that (or any other) module (no error checking shown): void (*p_a)(); /* declare function pointer to 'a()' */ cexpModuleLoad("A",0); /* use file name as module name; PATH is searched */ /* lookup the symbol */ p_a = cexpSymValue(cexpSymLookup("a",0)); /* call function */ if ( !p_a ) /* error; symbol not found */ else p_a(); Another method is using the interpreter (slower, of course). Since the interpreter is re-entrant, this involves dragging around context information: CexpParserCtx c = cexpCreateParserCtx(0); /* these two calls could/should be wrapped into 'cexpParseLine'... */ cexpResetParserCtx(c, "a()"); cexpparse(c); Note that more documentation about these calls can be found in 'cexp.h'. Note also that some of the Cexp library calls require more arguments than apparent from the examples in other sections of this document where the shell is explained! Most routines are geared for shell use and declare the most important arguments first, followed by optional arguments and they use defaults when these optional arguments are NULL. The shell implicitely sets extra arguments to zero so that when you type e.g., 'cexpModuleLoad("file.o")' this effectively is expanded to 'cexpModuleLoad("file.o",NULL)' since cexpModuleLoad() expects two parameters. OTOH, if you code cexpModuleLoad("file.o") in a program then the compiler will warn you and the second argument will be undefined. Therefore, if you want to use library calls from a program you should consult 'cexp.h' for reference. Before you can use the Cexp library, it must be properly initialized: CEXP Liberary Initialization - - - - - - - - - - - - - - - When using the 'cexp_main()' AKA shell entry point, the library is initialized automatically (you might still want to use cexpInit() if you intend to use your own signal handler...). If you want to use Cexp from a program as shown in the examples above, the library must be initialized before using it: cexpInit(0); /* initialize internal data; use default signal handling */ cexpModuleLoad(0,0); /* attach built-in symbol table. If you dont have a built- */ /* in table, you must pass a filename argument (see cexp.h)*/ C++ Information - - - - - - - - Dynamically loading C++ modules requires additional support. 1) static constructors and destructors 2) multiply defined instances of code (templates, multiple inclusion of headers) 3) exception handling Unfortunately, all of these items are highly implementation dependent and it is therefore unlikely that C++ support works for compilers other than gcc. Alas, there are even significant differences between different versions of gcc and target ABI's. IMHO, C++ is unreadable, unportable, bloat-prone and should be avoided if at all possible. That said, let's dive into the details: 1) static constructors and destructors take care of initializing/finalizing static objects such as: BlahClass blahObj(a,b,c); int test=testInitialize(x,y); gcc creates code for initializing/finalizing these kinds of objects and tags this code with symbols similar to '__GLOBAL__.I.xxx' / '__GLOBAL__.D.xxx'. If Cexp encounters such symbols, it builds constructor/destructor lists when loading the module and executes the respective code after loading / prior to unloading. Later versions of gcc use the '__cxa_atexit' callback mechanism which requires CEXP to call '__cxa_finalize()' when a module is unloaded. This seems to be a C++ ABI standard and is supported by Cexp. There are other possible implementations (such as creating special ctor/dtor sections) which are not supported - as I said, there is no general way for handling C++ :-( 2) C++ allows for multiple definitions/instantiations of code (a header included by more than one 'xxx.cc' file may define class members) plus there is the 'template' ''feature'' of C++. These let C++ code size _explode_ keeping hardware manufacturers happy. Gcc deals with this problem by putting every piece and bit of (possibly redundant code and/or data) into a separate '.gnu.linkonce.t.xyzkljsbjj783c' SECTION. The idea is that the linker (which is in our case 'Cexp') eliminates redundant sections. The sad result are bloated object files and Cexp symbol tables (Unfortunately, Cexp must keep _all_ of the zillions of '.gnu.linkonce.x.yzu' symbols around since a redundant copy might be loaded/linked at any time :-0 ) You can help CEXP, however by using proper linker scripts when linking large C++ applications (such as EPICS). If you are sure that your large application is the only (C++) object (sharing common code), you may provide the linker with a script which instructs it to integrate _all_ the "gnu.linkonce.t.xxx" sections into ".text" etc. If you don't believe me - just let CEXP load an EPICS IOC and list all the 'linkonce' symbols: lkup("linkonce") you will be surprised! 3) exception handling (while nice at the abstracion level) is another field that is highly architecture/compiler/version dependent and a seed to bloat. Even reentrancy might not be taken for granted. Gcc uses two flavors of exception handling 'longjmp' and 'eh_frame' style which are (to some extent) both supported by Cexp... As is said: C++ IS THE DEVIL in the detail. While linking C (and even fortran etc.) code compiled with different compilers (e.g. libraries) is seamless under a common ABI, it is very complex if not impossible with C++. Important PowerPC ABI Information --------------------------------- Cexp currently does not support the short data areas according to the SYSV/EABI specifications. Short data sections are merged by Cexp into the normal data segment and hence cannot be accessed via R13/R2. Hence, when compiling loadable modules, the compiler's -msdata flag must not be set to either of 'eabi', 'sysv' or 'use'. If you try to load code compiled with an improper -msdata setting, you will get a 'Relocation of unsupported size/type requested' error for the relocation type 'R_PPC_EMB_SDA21' or 'R_PPC_SDAREL16' or similar. PowerPC Branch Relocation Information ------------------------------------- When generating PPC code, gcc usually (i.e., unless giving the -mlongcall option which -- according to the gcc documentation -- may some day disappear) emits branch instructions which cannot jump farther than +/-32MB from the current PC location. This is a problem on systems with more that 64MB of memory. Since the space required for loadable modules is allocated from the regular 'malloc'-heap there is no guarantee that all modules (and the base executable) are all located closely enough together to be reachable and the loader may thus fail complaining that a R_PPC_REL24 relocation cannot be resolved. In order to solve this problem, Cexp now supports 'memory segments' and tries to load all text sections into a separate segment which is smaller than 32M and entirely reachable from the base executable. There are different ways for configuring Cexp's PPC text segment: 1) Do not reserve/use a dedicated text segment (OK for boards with less than 32M of memory). 2) Automatically reserve memory for the text segment within the base executable's '.bss' section. 3) Application provides memory via a two global variables 4) Application provides memory via linker script. The Cexp '--enable-text-segment' configuration option is used to define the desired behavior when Cexp is 'configure'd. 1) Configure with '--enable-text-segment=no' 2) Specify the desired amount of memory to be automatically reserved (in bytes): --enable-text-segment=<number_gt_zero> e.g. --enable-text-segment=0x800000 or simply (for a default of 8MB) --enable-text-segment=yes 3) Configure with --enable-text-segment=0 (which is also the default, i.e, you may omit the configuration option). The application must provide two variables unsigned long cexpTextRegionSize = <desired size>; unsigned char cexpTextRegion[<desired size>]; 4) Configure with --enable-text-segment=0 (which is also the default, i.e, you may omit the configuration option). The application provides two symbols (most likely from a linker script) defining the start and end of the text segment (keep in mind that this region AND the text sections of the base executable MUST be closer than 32MB together) _cexpTextRegionStart, _cexpTextRegionEnd NOTE: Some BSP's linker script ('linkcmds') for no good reason limit the size of an executable to <4MB by defining a MEMORY {} region -- often named 'CODE' -- in the linker script which is only 4MB in size. When you try to reserve a reasonably sized text segment on such a system (e.g., 16MB on a board with 512MB of memory) then linking the application will fail because it wouldn't fit into the small 'CODE' region. You can simply fix this by increasing the size of this region to 32MB, e.g., the fixed MEMORY definition of the powerpc/shared linkcmds would look like this: MEMORY { VECTORS : ORIGIN = 0x0 , LENGTH = 0x3000 CODE : ORIGIN = 0x3000 , LENGTH = 32M - 0x3000 } (the original LENGTH of CODE was 4MB.) LICENSING & DISCLAIMERS ----------------------- Consult the separate LICENSE file for details.
About
RTEMS C Expression Shell
Resources
License
Stars
Watchers
Forks
Packages 0
No packages published