Hi,
I am very new to nim, so please excuse me if this question is already answered somewhere else.
Is there someone that has ever cross-compiled a nim program for VxWorks on a PowerPC processor (using gcc)? If not, what would I need to do so? I have a (windows) gcc that can cross-compile C and C++ code to run it on a PowerPC (on a VxWorks 6.9 OS).
I tried adding the following two lines to my nim.cfg file:
powerpc.vxworks.gcc.exe = "powerpc-wrs-vxworks-gcc.exe" powerpc.vxworks.gcc.exe = "powerpc-wrs-vxworks-gcc.exe"
Where "powerpc-wrs-vxworks-gcc.exe" is on the path and is the compiler that I normally use to crosscompile my C and C++ code.
Then I ran:
nim.exe c --cpu:powerpc --os:vxworks --listFullPaths E:Nimexampleshallo.nim
However I got the following error:
command line(1, 1) Error: unknown OS: 'vxworks'
Also, I tried just compiling for windows and I also got an error:
E:Nimbin>nim.exe c --listFullPaths E:Nimexampleshallo.nim e:nimconfignim.cfg(49, 2) Hint: added path: 'C:Usersmyusername.babelpkgs' [Path] e:nimconfignim.cfg(50, 2) Hint: added path: 'C:Usersmyusername.nimblepkgs' [Path] Hint: used config file 'E:Nimconfignim.cfg' [Conf] Hint: system [Processing] Hint: hallo [Processing] CC: hallo CC: stdlib_system
- cygwin warning:
- MS-DOS style path detected: e:nimexamplesnimcachehallo.c Preferred POSIX equivalent is: /cygdrive/e/nim/examples/nimcache/hallo.c CYGWIN environment variable option "nodosfilewarning" turns off this warning.
- Consult the user's guide for more details about POSIX paths:
- http://cygwin.com/cygwin-ug-net/using.html#using-pathnames
In file included from e:nimexamplesnimcachehallo.c:8:0:
- E:Nimlib/nimbase.h:385:13: error: size of array ‘assert_numbits’ is negative
- typedef int assert_numbits[sizeof(NI) == sizeof(void*) && NIM_INTBITS == sizeof
- (NI)*8 ? 1 : -1];
- ^
In file included from e:nimexamplesnimcachestdlib_system.c:8:0:
- E:Nimlib/nimbase.h:385:13: error: size of array ‘assert_numbits’ is negative
- typedef int assert_numbits[sizeof(NI) == sizeof(void*) && NIM_INTBITS == sizeof
- (NI)*8 ? 1 : -1];
- ^
- Error: execution of an external program failed; rerun with --parallelBuild:1 to
- see the error message
Any help will be appreciated.
Neither vxworks nor cygwin are supported. To add support, edit compiler/platform.nim, bootstrap, test it and make a PR please.
EDIT: We can make these adjustements for you, but without you testing it, it's a futile effort.
Hi Araq,
I am not sure which sort of adjustments I would need to do. Can you walk me through them? I am OK with testing your suggestions and reporting the results here.
Also, what do you mean by bootstrap? Do you mean compiling nim under cygwin or under VxWorks?
Thanks for the update Araq.
Could you please give me a little more info (e.g. some web page) describing how to bootstrap on the development machine? My guess is that I should download the latest nim source code and compile it on my machine? Is that what you mean? Is it necessary that I compile it _on my machine? Why?
If I must compile on my machine, I must first get nim to compile anything in it since nim is written in nim, right? As I said on the second part of my original post that does not work for me. Compiling the hallo.nim example file fails as follows:
E:Nimbin>nim.exe c --listFullPaths E:Nimexampleshallo.nim e:nimconfignim.cfg(49, 2) Hint: added path: 'C:Usersmyusername.babelpkgs' [Path] e:nimconfignim.cfg(50, 2) Hint: added path: 'C:Usersmyusername.nimblepkgs' [Path] Hint: used config file 'E:Nimconfignim.cfg' [Conf] Hint: system [Processing] Hint: hallo [Processing] CC: hallo CC: stdlib_system
In file included from e:nimexamplesnimcachehallo.c:8:0:
In file included from e:nimexamplesnimcachestdlib_system.c:8:0:
Cheers,
Angel
If I must compile on my machine, I must first get nim to compile anything in it since nim is written in nim, right?
Right.
As I said on the second part of my original post that does not work for me. Compiling the hallo.nim example file fails as follows
Your version of GCC and your Nim compiler disagree on how many bits a pointer should have. Install Nim plus the GCC that we ship with Nim, or simply switch from the 32 bit installation to the 64 installation or vice versa.
Hi again Araq,
I managed to compile the latest version of nim on the git repository on a separate Windows PC (I won't have access to the original PC until next week).
I have a few questions and comments:
Other than that, I hope to try the vxworks support next week and report back here. Thanks!
I was finally able to try compiling nim on the machine that I use to compile my VxWorks binaries. It was a bit hard because nim kept finding the wrong gcc. I managed to overcome the problem by changing the nim.cfg file so that nim would use the MinGW gcc that is provided with the nim installer.
The compiled nim.exe understands the --os:vxworks flag. However, doing:
nim.exe c --cpu:powerpc --os:vxworks hallo.nim
works, but it generates a regular windows executable (hallo.exe). It seems that I must also add the two following lines to my nim.cfg file:
powerpc.vxworks.gcc.exe =
"E:/WindRiver/gnu/4.1.2-vxworks-6.8/x86-win32/bin/ccppc.exe"
powerpc.vxworks.gcc.linkerexe =
"E:/WindRiver/gnu/4.1.2-vxworks-6.8/x86-win32/bin/ldppc.exe"
Note that I am quite sure that the second one is wrong. I normally use the WindRiver workbench to compile my VxWorks projects. In the workbench, under the "Linker" tool panel I can see the following config:
echo "building $@";rm -f %OutFile%;nmppc %Objects% | tclsh $(WIND_BASE)/host/resource/hutils/tcl/munch.tcl -c ppc -tags $(VSB_DIR)/tags/ppc/PPC32/common/dkm.tags > $(OBJ_DIR)/ctdt.c;%ccompilerprefix% $(TOOL_PATH)ccppc %DebugModeFlags% $(CC_ARCH_SPEC) -fdollars-in-identifiers -Wall -Wsystem-headers $(ADDED_CFLAGS) %Includes% $(ADDED_INCLUDES) %Defines% $(DEFINES) -o $(OBJ_DIR)/ctdt.o -c $(OBJ_DIR)/ctdt.c;%linkerprefix% $(TOOL_PATH)ccppc -r -nostdlib -Wl,-X %ToolFlags% -o %OutFile% $(OBJ_DIR)/ctdt.o %Objects% %Libraries% $(LIBPATH) $(LIBS) $(ADDED_LIBPATH) $(ADDED_LIBS) && if [ "$(EXPAND_DBG)" = "1" ]; then plink "$@";fi
So my guess is that the config above is wrong. Also note how this depends on the existance of a ctdt.c file that The Workbench seems to generate on its own...
Anyway, just in case and to see how far it would get I tried compiling and as expected I got a bunch of errors:
e:\Nim-devel\examples>..\bin\nim.exe c --cpu:powerpc --os:vxworks --parallelBuild:1 hallo.nim
e:\nim-devel\config\nim.cfg(52, 2) Hint: added path: 'REDACTED_USER_PATH\.babel\pkgs\'
[Path]
e:\nim-devel\config\nim.cfg(53, 2) Hint: added path: 'REDACTED_USER_PATH\.nimble\pkgs\
' [Path]
Hint: used config file 'e:\Nim-devel\config\nim.cfg' [Conf]
Hint: system [Processing]
Hint: hallo [Processing]
In file included from e:\windriver\gnu\4.1.2-vxworks-6.8\x86-win32\bin\../../lib
/gcc/powerpc-wrs-vxworks/4.1.2/include-fixed/limits.h:122,
from e:\windriver\gnu\4.1.2-vxworks-6.8\x86-win32\bin\../../lib
/gcc/powerpc-wrs-vxworks/4.1.2/include-fixed/syslimits.h:7,
from e:\windriver\gnu\4.1.2-vxworks-6.8\x86-win32\bin\../../lib
/gcc/powerpc-wrs-vxworks/4.1.2/include-fixed/limits.h:11,
from e:\Nim-devel\lib/nimbase.h:156,
from e:\nim-devel\examples\nimcache\compiler_hallo.c:8:
e:/windriver/gnu/4.1.2-vxworks-6.8/lib/gcc/../../lib/gcc/powerpc-wrs-vxworks/4.1
.2/include-fixed/limits.h:122:61: error: no include path in which to search for
limits.h
e:\nim-devel\examples\nimcache\compiler_hallo.c:10:19: error: stdio.h: No such f
ile or directory
Environment variables WIND_LIC_PROXY and/or WIND_HOME not set
Environment variables WIND_LIC_PROXY and/or WIND_HOME not set
Environment variables WIND_LIC_PROXY and/or WIND_HOME not set
Environment variables WIND_LIC_PROXY and/or WIND_HOME not set
Environment variables WIND_LIC_PROXY and/or WIND_HOME not set
Environment variables WIND_LIC_PROXY and/or WIND_HOME not set
proxyClient: cannot create REDACTED_FILENAME, exiting
In file included from e:\windriver\gnu\4.1.2-vxworks-6.8\x86-win32\bin\../../lib
/gcc/powerpc-wrs-vxworks/4.1.2/include-fixed/limits.h:122,
from e:\windriver\gnu\4.1.2-vxworks-6.8\x86-win32\bin\../../lib
/gcc/powerpc-wrs-vxworks/4.1.2/include-fixed/syslimits.h:7,
from e:\windriver\gnu\4.1.2-vxworks-6.8\x86-win32\bin\../../lib
/gcc/powerpc-wrs-vxworks/4.1.2/include-fixed/limits.h:11,
from e:\Nim-devel\lib/nimbase.h:156,
from e:\nim-devel\examples\nimcache\stdlib_system.c:8:
e:/windriver/gnu/4.1.2-vxworks-6.8/lib/gcc/../../lib/gcc/powerpc-wrs-vxworks/4.1
.2/include-fixed/limits.h:122:61: error: no include path in which to search for
limits.h
e:\nim-devel\examples\nimcache\stdlib_system.c:10:20: error: setjmp.h: No such f
ile or directory
e:\nim-devel\examples\nimcache\stdlib_system.c:12:20: error: string.h: No such f
ile or directory
e:\nim-devel\examples\nimcache\stdlib_system.c:14:22: error: sys/mman.h: No such
file or directory
e:\nim-devel\examples\nimcache\stdlib_system.c:16:19: error: stdio.h: No such fi
le or directory
e:\nim-devel\examples\nimcache\stdlib_system.c:18:20: error: stdlib.h: No such f
ile or directory
e:\nim-devel\examples\nimcache\stdlib_system.c:20:20: error: signal.h: No such f
ile or directory
e:\nim-devel\examples\nimcache\stdlib_system.c:200: error: expected specifier-qu
alifier-list before 'jmp_buf'
e:\nim-devel\examples\nimcache\stdlib_system.c:323: error: expected ')' before '
*' token
e:\nim-devel\examples\nimcache\stdlib_system.c: In function 'osallocpages_26614'
:
e:\nim-devel\examples\nimcache\stdlib_system.c:1007: error: 'MAP_ANONYMOUS' unde
clared (first use in this function)
e:\nim-devel\examples\nimcache\stdlib_system.c:1007: error: (Each undeclared ide
ntifier is reported only once
e:\nim-devel\examples\nimcache\stdlib_system.c:1007: error: for each function it
appears in.)
e:\nim-devel\examples\nimcache\stdlib_system.c: In function 'markstackandregiste
rs_70040':
e:\nim-devel\examples\nimcache\stdlib_system.c:1688: error: 'jmp_buf' undeclared
(first use in this function)
e:\nim-devel\examples\nimcache\stdlib_system.c:1688: error: expected ';' before
'registers'
e:\nim-devel\examples\nimcache\stdlib_system.c:1698: error: 'registers' undeclar
ed (first use in this function)
e:\nim-devel\examples\nimcache\stdlib_system.c: At top level:
e:\nim-devel\examples\nimcache\stdlib_system.c:4026: error: expected ')' before
'*' token
e:\nim-devel\examples\nimcache\stdlib_system.c: In function 'writetostderr_16401
':
e:\nim-devel\examples\nimcache\stdlib_system.c:4031: error: 'stderr' undeclared
(first use in this function)
e:\nim-devel\examples\nimcache\stdlib_system.c: In function 'signalHandler':
e:\nim-devel\examples\nimcache\stdlib_system.c:4631: error: 'SIGINT' undeclared
(first use in this function)
e:\nim-devel\examples\nimcache\stdlib_system.c:4638: error: 'SIGSEGV' undeclared
(first use in this function)
e:\nim-devel\examples\nimcache\stdlib_system.c:4645: error: 'SIGABRT' undeclared
(first use in this function)
e:\nim-devel\examples\nimcache\stdlib_system.c:4652: error: 'SIGFPE' undeclared
(first use in this function)
e:\nim-devel\examples\nimcache\stdlib_system.c:4659: error: 'SIGILL' undeclared
(first use in this function)
e:\nim-devel\examples\nimcache\stdlib_system.c: In function 'registersignalhandl
er_20207':
e:\nim-devel\examples\nimcache\stdlib_system.c:4685: error: 'SIGINT' undeclared
(first use in this function)
e:\nim-devel\examples\nimcache\stdlib_system.c:4686: error: 'SIGSEGV' undeclared
(first use in this function)
e:\nim-devel\examples\nimcache\stdlib_system.c:4687: error: 'SIGABRT' undeclared
(first use in this function)
e:\nim-devel\examples\nimcache\stdlib_system.c:4688: error: 'SIGFPE' undeclared
(first use in this function)
e:\nim-devel\examples\nimcache\stdlib_system.c:4689: error: 'SIGILL' undeclared
(first use in this function)
Environment variables WIND_LIC_PROXY and/or WIND_HOME not set
Environment variables WIND_LIC_PROXY and/or WIND_HOME not set
Environment variables WIND_LIC_PROXY and/or WIND_HOME not set
Environment variables WIND_LIC_PROXY and/or WIND_HOME not set
Environment variables WIND_LIC_PROXY and/or WIND_HOME not set
Environment variables WIND_LIC_PROXY and/or WIND_HOME not set
proxyClient: cannot create REDACTED_FILENAME, exiting
Error: execution of an external program failed
There are several problems:
So it seems that even before linking there are some issues.
Any ideas?
Cheers,
Angel
Any ideas?
Well -d:noSignalHandler --deadCodeElim:on should get rid of a few dependencies and you can always try --os:standalone instead of --os:vxworks. I know nothing about vxworks, so I couldn't configure it properly.
The WIND_LIC_PROXY and WIND_HOME environment variables are related to the WindRiver license. I don´t know why nim does not pick them up.
This seems to be your major problem. Run nim from a console that sets these environment variables. You can check via the batch command (!) echo %WIND_HOME% if they exist.
I fixed the problem with the environment variables (VxWorks comes with a development shells that sets them for you) and reran the compilation of hallo.nim and the result is as follows:
e:\Nim-devel\examples>..\bin\nim.exe c --cpu:powerpc --os:vxworks --parallelBuild:1 -d:noSignalHandler --deadCodeElim:on hallo.nim
e:\nim-devel\config\nim.cfg(52, 2) Hint: added path: 'REDACTED_USER_PATH\.babel\pkgs\'
[Path]
e:\nim-devel\config\nim.cfg(53, 2) Hint: added path: 'REDACTED_USER_PATH\.nimble\pkgs\
' [Path]
Hint: used config file 'e:\Nim-devel\config\nim.cfg' [Conf]
Hint: system [Processing]
Hint: hallo [Processing]
In file included from E:\WindRiver\vxworks-6.9/target/h/regs.h:67,
from E:\WindRiver\vxworks-6.9/target/h/setjmp.h:55,
from e:\nim-devel\examples\nimcache\stdlib_system.c:10:
E:\WindRiver\vxworks-6.9/target/h/arch/ppc/regsPpc.h:44: error: expected specifier-qualifier-list before 'UINT32'
In file included from E:\WindRiver\vxworks-6.9/target/h/signal.h:102,
from E:\WindRiver\vxworks-6.9/target/h/setjmp.h:56,
from e:\nim-devel\examples\nimcache\stdlib_system.c:10:
E:\WindRiver\vxworks-6.9/target/h/sigevent.h:36: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'sigeventInit'
E:\WindRiver\vxworks-6.9/target/h/sigevent.h:38: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'sigeventNotify'
E:\WindRiver\vxworks-6.9/target/h/sigevent.h:39: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'sigeventDelete'
In file included from E:\WindRiver\vxworks-6.9/target/h/setjmp.h:56,
from e:\nim-devel\examples\nimcache\stdlib_system.c:10:
E:\WindRiver\vxworks-6.9/target/h/signal.h:410: error: expected ')' before 'rtpId'
E:\WindRiver\vxworks-6.9/target/h/signal.h:464: error: expected ')' before '__tid'
E:\WindRiver\vxworks-6.9/target/h/signal.h:465: error: expected ')' before 'tid'
In file included from e:\nim-devel\examples\nimcache\stdlib_system.c:10:
E:\WindRiver\vxworks-6.9/target/h/setjmp.h:92: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'void'
E:\WindRiver\vxworks-6.9/target/h/setjmp.h:95: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'void'
Error: execution of an external program failed
The failing code is at the top of regsPpc.h (I removed the header comments):
#ifndef __INCregsPpch
#define __INCregsPpch
#ifdef __cplusplus
extern "C" {
#endif
#define GREG_NUM 32 /* has 32 32/64-bit data registers */
#ifndef _ASMLANGUAGE
typedef struct /* REG_SET */
{
_RType gpr[GREG_NUM]; /* general purpose registers */
_RType msr; /* machine state register */
_RType lr; /* link register */
_RType ctr; /* count register */
_RType pc; /* program counter */
UINT32 cr; /* condition register */
The problem is that UINT32 is not defined in regsPpc.h not there is any include that would contain that define. UINT32 is defined in a file called "types/vxTypesOld.h". My guess is that the VxWorks code must be careful to include the files in the right order so that vxTypesOld.h is included before including regsPpc.h.
Looking at the "stdlib_system.c" I see that it contains several includes. Maybe playing with the order in which they are included would fix the problem? I did in fact try to modify the stdlib_system.c file that I found in the nimcache folder, but it seemed to me that nim was not using my modified version of that file (but I may have done something wrong, of course).
BTW, my guess is thta VxWorks is most similar to Unix. I don't know if that would help you improve the built-in support for VxWorks? What other information would you need to improve the default VxWorks settings?
The problem is that UINT32 is not defined in regsPpc.h not there is any include that would contain that define. UINT32 is defined in a file called "types/vxTypesOld.h". My guess is that the VxWorks code must be careful to include the files in the right order so that vxTypesOld.h is included before including regsPpc.h.
Ok, edit lib/nimbase.h then so that it includes these headers in the right order. Maybe they have at least an include guard so including them twice works... BTW I would report "header files require a specific include order" as a bug to VxWorks.
What other information would you need to improve the default VxWorks settings?
Well I already made it "posix like". But:
/* VxWorks related includes */
#if defined(__VXWORKS__)
# include <sys/types.h>
# include <types/vxWind.h>
# include <tool/gnu/toolMacros.h>
#endif
# Configuration for the VxWorks 6.9 compiler (to generate RTP applications)
@if vxworks:
gcc.options.always = "-mrtp -fno-strict-aliasing -D_C99 -D_HAS_C9X -std=c99 -fasm -Wall -Wno-write-strings"
gcc.options.linker = "-L E:/WindRiver/vxworks-6.9/target/lib/usr/lib/ppc/PPC32/common -mrtp -fno-strict-aliasing -D_C99 -D_HAS_C9X -std=c99 -fasm -Wall -Wno-write-strings"
@end
Note that I had to hard-code the path to the VxWorks library. I tried using "$WIND_BASE/target/lib/usr/lib/ppc/PPC32/common" instead (and several similar variations such as %WIND_BASE% and $(WIND_BASE)) but none work. How could I avoid using the hard-coded path?
Note that in VxWorks you can generate two types of artifacts: Dynamic Kernel Modules (DKMs) and RTP (user) applications. RTPs are basically executables, while DKMs are loaded into the kernel using the loadModule function, which adds the symbols in the DKM to the kernel space (and thus are accessible from all other DKMs). This configuration is meant to generate RTPs. I am not sure how I would go about generating a DKM, since they have no main function and also they require a more complex link step (it is in fact a multi-step operation).
With these changes, I managed to generate several RTPs from the examples as well as a couple of small tests of my own. I ran them on one of our dev boards and they worked great! :-D
What would be the best way to get this into an official nim build (once the usage of the hard-coded library path can be avoided)? A pull request on github? Or maybe you can just take it from this email?
Also, regarding your questions:
I don't think there is mmap but it does support virtual memory.
You mean stdio and friends? If so, yes.
It is a regular PowerPC which could easily run some other OS (e.g. Linux). It is quite powerful (multicore, multi GB of memory, over 1 GHz of frequency). However VxWorks is meant to be used for real time applications so for real use you may need to be able to do some manual memory allocation or control when the GC runs (which I believe is possible in nim, right?)
I believe it does.
Anyway, this is really, really cool! :-D
How could I avoid using the hard-coded path?
Nim's config system doesn't support environment variables for now, but you can have project specific configuration files and in these hard coded paths are at least acceptable. YMMV of course. I will add support for env vars for you.
What would be the best way to get this into an official nim build (once the usage of the hard-coded library path can be avoided)? A pull request on github? Or maybe you can just take it from this email?
Pull request on github will be handled quicklier. ;-)
Anyway, this is really, really cool!
Yup. :-)
This is approximate. I am not really an expert in VxWorks. In the WindRiver workbench environment, this is done through a script like the following one:
echo "building $@";rm -f %OutFile%;nmppc %Objects% | tclsh $(WIND_BASE)/host/resource/hutils/tcl/munch.tcl -c ppc -tags $(VSB_DIR)/tags/ppc/PPC32/common/dkm.tags > $(OBJ_DIR)/ctdt.c;%ccompilerprefix% $(TOOL_PATH)ccppc %DebugModeFlags% $(CC_ARCH_SPEC) -fdollars-in-identifiers -Wall -Wsystem-headers $(ADDED_CFLAGS) %Includes% $(ADDED_INCLUDES) %Defines% $(DEFINES) -o $(OBJ_DIR)/ctdt.o -c $(OBJ_DIR)/ctdt.c;%linkerprefix% $(TOOL_PATH)ccppc -r -nostdlib -Wl,-X %ToolFlags% -o %OutFile% $(OBJ_DIR)/ctdt.o %Objects% %Libraries% $(LIBPATH) $(LIBS) $(ADDED_LIBPATH) $(ADDED_LIBS) && if [ "$(EXPAND_DBG)" = "1" ]; then plink "$@";fi
I guess that I could create a script that does all those steps and then I could refer to it on the nim.cfg file. However, that would mean that the user would need to manually create that script. Is there some other way in which I could configure nim to do this?
1. Yes. I added the new '%=' syntax to set a configuration variable that does environment interpolation: some.configvar %= "foo;bar;$envvar".
It seems we missed each other. I checked nim's github repo and I saw that change had not been made yet. So I sent you a pull request in which I hard coded the VxWorks library path. Then I came here to tell you about it and found out that you had just pushed that new feature!
What do you prefer me to do? Do you want me to wait for you to accept that pull request and then send you a new one that changes the nim.cfg file to use the environment interpolation.
2. We should introduce a --define symbol for that.
You mean something that let you do:
nim c --define:dkm app.nim
Or
nim c --define:mode=dkm app.nim
That would be nice!
3. I think you should write a script that invokes nim.
You mean a script that would do the munch and final link steps after nim compiles and does the first link step?
Alternatively nim can staticExec scripts.
Do you mean to generate the linker script on the fly?
If possible I'd like to make it possible for a somewhat clueless user to compile a VxWorks DKM using a vanilla nim installation (no changes needed to the nim config or custom scripts needed).
4. Name generation is quite deterministic, so yes, there would be collisions, but then C has the same problem, so whatever tool is used that hacks the produced code by the C compiler, will work out of the box with Nim too.
There is actually not such thing I believe (if I understood you correctly). When writing kernel modules you just have to be very careful to not overwrite any existing symbol (which does happen some times, unfortunately). The C++ symbols are mangled of course, and namespaces help, but extern C symbol names must be unique.
What worries me the most are the functions that nim uses under the hood and which will be shared by all nim compiled programs. Even the symbols that we would declare in our own nim files could be problematic because we would not get the benefit of C++ namespaces and all C functions would be visible in the kernel.
Maybe a solution would be for nim to prepend all symbols names (including the ones defined in stdlib_system, etc) with some unique ID (e.g. the application name or some userdefined id). Kind of like a poor-man's namespace. Would that work?
Maybe a solution would be for nim to prepend all symbols names (including the ones defined in stdlib_system, etc) with some unique ID (e.g. the application name or some userdefined id). Kind of like a poor-man's namespace. Would that work?
No idea what this "names must be unique" restriction really means. If we have 2 kernel modules in Nim which both use some internal helper nimCopyString does that produce a conflict? And if so, how would a name like stdlib_nimCopyString help? And how do C++'s namespaces help? Or name mangling?
And if you mean that we need something like kernelA_nimCopyString and kernelB_nimCopyString then that's quite some work and I cannot imagine how anybody can claim VxWorks supports developing in C as this would make using any kind of C library impossible.
Maybe a solution would be for nim to prepend all symbols names (including the ones defined in stdlib_system, etc) with some unique ID (e.g. the application name or some userdefined id). Kind of like a poor-man's namespace. Would that work?
No idea what this "names must be unique" restriction really means. If we have 2 kernel modules in Nim which both use some internal helper nimCopyString does that produce a conflict? And if so, how would a name like stdlib_nimCopyString help? And how do C++'s namespaces help? Or name mangling?
I guess the problem is not as bad as I made it sound. It is a problem, but depending on how nim internals work it may only affect you in the same way that it affects regular C applications (in that you must choose unique names for your top level functions).
Anyway, let me try to explain the problem in a bit more detail. Note that I'm not a super-expert, I've written several VxWorks DKMs but I have not hacked on the VxWorks internals myself. Hopefully the following will not contain too much miss-information nor make too much a fool of myself :-P:
TL;DR: All DKMs share a single system symbol table and are linked at load time. This creates the possibility of global symbol aliasing which is bad.
VxWorks kernel modules (DKMs) are quite different from regular applications:
When kernel modules are loaded, they are linked to the existing environment (i.e. using the current contents of the system symbol table). Once a link from a module to an external symbol is created, that link cannot be changed (well, unless you reload the module).
At load time all the global symbols that a module defines are loaded into the kernel (a.k.a. system) symbol table. Depending on the loader config, when two modules define two identical symbols two things can happen:
DKMs are usually created in order to extend the kernel, providing additional symbols (usually functions) that can be used by other modules or applications in the system.
Depending on how your code works, one or the other alternative may be better. For example, if you declare a global counter that is supposed to be increased whenever a particular function is called, and another module defines a global variable with the same name, the default load behavior would make your counter show the wrong value.
In any case you must be careful that your DKM "entry points" (the functions that will be used by other entities) are unique, to avoid aliasing.
How do namespaces help in this context? By making symbol names more unique.
Now, coming back to nim and your particular question. If we have 2 kernel modules in Nim which both use some internal helper nimCopyString, the default load behavior will make it so that each module uses its own copy of nimCopyString. My guess is that is what you would want, since that is the behavior that most resembles how a regular application would work. That being said, not knowing how that function works I cannot be 100% sure. I was particularly worried about nim internal functions that may need to track stuff, such as the garbage collector, etc.
And if you mean that we need something like kernelA_nimCopyString and kernelB_nimCopyString then that's quite some work and I cannot imagine how anybody can claim VxWorks supports developing in C as this would make using any kind of C library impossible.
That is what I meant, as a way to completely side step the issue. I may have overstated the problem though.
I don't particularly like VxWorks, but there are probes in space right this moment that are running some version of VxWorks. It is quite likely that they are running code that was written in C :-)