I faced a situation that I need some tables to be filled in one source file (for example fill.cu) and then be used in different kernels in different source files.
I tried declaring a pointer __device__ float *myTable; as 'extern' in fill.h header file and adding that to others.cpp and defining that pointer in fill.cu and allocate and fill it there.
This way, I got linker error indicating that myTable has been already defined in fill.cpp.
After many unsuccessful try, I decided to put all kernels that need this table in same source file, this way everything works fine until I added an cudaMalloc in main function before allocating my table in fill.cpp.
This way I noticed that table values and data allocated in main are overlapped and using cuda debugging tools of MS visual studio 2015, I found that 2 allocated pointer are same!!!
Please advice how to declare a global pointer in cuda without conflict.
The traditional CUDA linkage model requires that all device symbols, textures, functions, etc. are defined and used within the scope of the same translation unit. It sounds like your code structure is violating this requirement.
You have two choices:
Continue to the same code structure, but provide wrapper functions which your main can call to perform operations on statically declared device variables, rather than directly manipulating device symbols with the CUDA API from other code.
Use separate compilation. Here, you define the device symbol you want to access in exactly one file and declare the same symbol as externeverywhere else you need to use that symbol. You must explicitly use several nvcc options to compile your device code and use a separate device code linking stage.
Both approaches are well documented.
Related
I'm modifying a code written in c++ in order to add several features required by my company. I need to modify as less as possible this code, because it's a public code get from a Git repository, and we want to avoid to deviate from the original source code in case we need to synchronize our code with possible new versions in the future.
In this code, a structure is initialized with a call to std::memset. And I had need to add a shared pointer to this structure.
I notice no issue about that, the code compiles, links and works as expected, and I get even no warnings while the compilation.
But is it safe to achieve that this way? May a std::shared_ptr be correctly initialized if it is part of a structure initialized with std::memset? Or are side effects or hazardous issues which prevent to do that?
Basically, I want to be able to generate class definitions, compile the system, and save it for reuse. Would that involve a code walker, or is there a simpler option?
(save-lisp-and-die "isn't going to work for me")
Expanding to explain. I'm generating systems based on OpenAPI definitions, so a system roughly corresponds to an API client.
There will be dozens, if not hundreds of these.
The idea is to NOT keep them all in the image, but load at run time as required.
I see two possible routes here, and to some extent, I suspect they mainly differ in "the last mile" (as it were).
The route you seem to have settled on, run-time definition of classes and functions.
A route whereby you generate your function/class forms, but don't go the full way to get them "Live" in the image and instead emit the form(s) to a file.
I suspect that it would be possible to have most of the generating code shared between the two and for the first route have a wrapping macro that effectively returns a PROGN, and in the second calls a function to pretty-print what the macro would have returned on a stream.
Saying that, building a tailored environment and saving it to a "core" file is a pretty good way of getting excellent startup times.
Problem Solved!!! See below for solution
I was about to post this question and decided to check the web one more time. This site https://www.freepascal.org/docs-html/prog/progsu40.html
has this statement: The {$I filename} or {$INCLUDE filename} directive tells the compiler to read further statements from the file filename. The statements read there will be inserted as if they occurred in the current file.
This is exactly what I want to do with Arduino. How do I do it?
My Skill Set:
Writing code since 1967. Yes, I survived Y2K, which was a real thing; so I'm not new to programming/debugging. Mainframes and PC's. Very solid COBOL and SAS skills. Good skills with Borland/Lazarus Object Pascal. Weak C/C++ skills.
Background:
I have two working Arduino programs that are used on a model railroad. Prog1 uses infrared sensors to light LEDs that indicate the position of a train in a tunnel. I built the IRSensor class to handle a single sensor. Prog2 uses push-buttons to set a route through several track switches. Each track switch is set via a servo. I extended the Servo class to TOServo, which encapsulate most of the commonality in each track switch.
Now I'm working on a different model railroad and need merge Prog1 and Prog2 into a single program. Building Prog3 via copy/paste from programs 1 & 2 has proved unwieldy.
Problem:
How do I tell the Arduino pre-processor/compiler to "insert filename here; do not compile, pre-compile, or otherwise process the filename unless it is wrapped around the file asking for the insertion"?
What I've tried:
I built Prog3 by separating the code for Prog2 into 3 sections -- Main program storage & code and 2 include statements (Storage definitions and executable code for TOServo). These include statements pull in code that define or access an array of TOServo. I've used several suffixes (.h/.ino and .h/.cpp and .c/.c), and they all generate 'not declared in this scope' errors.
Finally:
Thanks for your help.
SOLUTION
My .ino file had grown large & unwieldy. The 'solution' was to move a large segment of code and matching declarations to external .h/.cpp files, and to access those files via #include statements. The program would not compile (undefined variables); they were, in fact, defined but the compiler couldn't find them. After many attempts to fix or rearrange the code, finally two things dawned on me.
1)The Arduino pre-compiler changes (rearranges?) my code so that C++ and the Arduino CPU can work together. This means that the code I see is not always the code the compiler sees.
2)My .h/.cpp files define and manage an array of servo objects. I could convert those files into an object that I access from the main .ino file.
So I've solved my problem. Thanks to all those who have posted in many forums/sites, especially to Tarick Welling who stayed with me to the end.
I read on this answer the following statement:
"Keep in mind that the compiler can and does move code from one chunk into other chunk output files if it determines that it is only used by that chunk."
Is there any way to switch that off?
I have a 'main' chunk and an 'optional' chunk, and I'm finding the code from the optional chunk is being moved entirely into the main.
My optional code will only be called from the main code, but only if it's determined that we actually want to load the optional stuff (based on a flag that's external to both.)
I want to minimize the size of the main code for cases where the optional stuff isn't needed, but it doesn't seem to be possible with closure as far as I can see.
EDIT:
To split the code I use the -chunk options on the (java) commandline. The 'main' one I point at several folders ('src/Infra/*.js' etc) and use 'auto' for the numFiles for the chunk. The 'optional' I point at three specific files, no wildcard, and specify 3 as numFiles.
To load the 'optional' script the 'main' writes a script tag to the page and has a Promise resolve when it loads. 'optional' is supposed to instantiate the class it defines, and push a reference to that instance to an array in the global namespace, then main reads the ref from the array, and calls an init() method on it, passing in some dependencies.
Is there a better-supported (and equally compact) way of doing it?
EDIT2: in case anyone has a similar issue, I resolved it using the "nameCache" feature of uglifyjs, so the separate components don't necessarily need to be compiled at the same time.
The compiler does not move code "up" the module graph. What's happening is the compiler somehow believes that symbols defined in your optional chunk are directly required.
This most frequently occurs because you are using dependency management and modules. When the compiler sorts dependencies, if any of the "optional" files are directly imported via require for CommonJS, import for ES6 or goog.require for Closure. In this case the compiler adds them to the main module.
To be more specific, I'd actually have to see code.
I want to analyze a file from a large project to create a Program Dependence Graph using Frama-C, but keep getting odd errors such as:
/usr/include/bits/fcntl-linux.h:305:[kernel] user error: Length of array is zero. This extension is unsupported
If I try to use the libc implementation provided by frama-c, compilation fails due to missing headers such as sys/file.h.
I am trying to analyze files from the Lynx project, specifically the file in src/WWW/Library/Implementation/HTTP.c, using GCC version 4.8.1
What I really need is to be able to generate a PDG for this source file (which of course has various dependencies) but I think if I could get even a somewhat incomplete graph by skipping over undefined functions, that would be a great first step.
You need to provide your own "file.h" file in a directory "sys" placed anywhere in the path GCC searches when pre-processing for Frama-C.
For reference, here is the implementation of sys/file.h on another system. You may also be interested in this other StackOverflow question about sys/file.h.
For Frama-C's value analysis, assigns clauses alongside the prototypes go a long way:
/*# assigns *f \from ui, s, *fo; */
void finit(struct file *f, u_int ui, short s, void *p, struct fileops *fo);
Note that I have no idea what function finit() does and whether the above is a correct assigns clause for it. In fact, this is the whole point: neither does Frama-C out of the box, and since this lowish-level, lessish-portable system call is used in the code you wish to analyze, someone will have to know. I am afraid it is going to have to be you. On the plus side, you only need to provide the types, macros and function prototypes that the code you wish to analyze uses.