I have llvm compiler that supports Riscv vector intrinsic coding and a core on FPGA that is RV32IMV... I have written a C code for the core but when I compile it I get the following error:
error: undefined symbol: __udivdi3
I think it is because I don't have the necessary library added to my linker file for this purpose
but after I searched for the error I found this:
Undefined reference to '__divdi3'
At the end of this post, the author says:
Alternatively, you could write your own implementations of those
functions, or crib the source from GCC, but I don't see why you would
prefer either of those options.
Can anyone suggest a piece of code that implements this function so that I can add it to my code?
I have already added this pices of code for memcpy and it works fine:
void* memcpy(void* dest, const void* src, size_t n)
{
for (size_t i = 0; i < n; i++)
{
((char*)dest)[i] = ((char*)src)[i];
}
}
I was developing an embedded project an was struggling to compile it because of this error:
mipsel-linux-gnu-ld: main.o: in function 'fooBar':main.c:(.text+0x3ec): undefined reference to 'memcpy'
This error is caused by every operation similar to this, in which I assign the value of a pointer to a non-pointer type variable.
int a = 0;
int *ap = &a;
int c = *ap; //this causes the error
Here's another example:
state_t *exceptionState = (unsigned int) 0x0FFFF000;
currentProcess->cpu_state = *exceptionState; //this causes the error
I have already included the flag -nostdlib in the makefile...
Thank you in advance!
I have already included the flag -nostdlib in the makefile...
Take that flag out. It blocks linkage to standard library calls. The compiler might actually generate references to the memcpy function, even if your code doesn't explicitly call it.
If you absolutely need -nostdlib, I suppose you could define your own version of memcpy - if that's the only function the linker is complaining about. It won't be as optimized, but it would work. add the following code to the bottom of one of your source files:
void *memcpy(void *dest, const void *src, size_t n)
{
for (size_t i = 0; i < n; i++)
{
((char*)dest)[i] = ((char*)src)[i];
}
}
The fact that you have included -nostdlib is what's causing your problem.
If you copy a structure the compiler may call the standard C runtime function memcpy() to do it. If you link with -nostdlib then you're telling the linker to not include the standard C runtime library.
If you have to use -nostdlib then you'll have to provide your own implementation of memcpy().
I am designing hardware to do floating point arithmetic in compliance with the IEEE-754 standard. SoftFloat is a library (written by John Hauser - UC Berkeley) which is a reference model (in C++) of IEEE-754 floating point behavior. It implements functions to do all the floating point computations specified by the standard. I want to use SoftFloat to generate test cases for my hardware implementation. The link for the author's page is http://www.jhauser.us/arithmetic/SoftFloat.html.
I downloaded the zip file from the link on that page (http://www.jhauser.us/arithmetic/SoftFloat-3e.zip), unzipped it, and used to provided Makefile to build it. I am running under bash on Windows10. At the end of the build process, I end up with an archive "softfloat.a".
One of the functions which SoftFloat implements is fused floating-point multiply-add. Per the documentation, this can be invoked by calling the function f32_mulAdd, and a template for it is in the provided header file softfloat.h.
In my main code (sf.cc), I include that header, define arguments to that function using types defined in the same header, and build the code with:
gcc -o sf -I. sf.cc softfloat.a
This gives the following error:
/tmp/ccALxpC8.o: In function `main':
sf.cc:(.text+0x4f): undefined reference to `f32_mulAdd(float32_t, float32_t, float32_t)'
collect2: error: ld returned 1 exit status
f32_mulAdd IS defined in softfloat.h (I checked), and the archive file softfloat.a DOES contain f32_mulAdd.o (checked with ar -t softfloat.a) and f32_mulAdd.c in the SoftFloat source code DOES define the function (as "float32_t f32_mulAdd( float32_t a, float32_t b, float32_t c)") and my call to that function is consistent with the definition, so I don't understand why I get this message. If anyone has used SoftFloat please chime in.
The source code in which I call the SoftFloat function f32_mulAdd is as follows (I want to get this to compile/link cleanly first, then I will add statements to initialize the variables multiplier, multiplicand and addend to specific values):
#include "platform.h"
#include "internals.h"
#include "softfloat.h"
#include "softfloat_types.h"
int float_rounding_mode = 0;
int main()
{
uint8_t rounding_mode;
uint8_t exceptions;
uint32_t multiplier, multiplicand, addend, result;
float32_t f_multiplier, f_multiplicand, f_addend, f_result;
f_multiplier.v = multiplier;
f_multiplicand.v = multiplicand;
f_addend.v = addend;
softfloat_roundingMode = rounding_mode;
softfloat_exceptionFlags = 0;
softfloat_detectTininess = softfloat_tininess_beforeRounding;
f_result = f32_mulAdd(f_multiplier, f_multiplicand, f_addend);
result = f_result.v;
exceptions = softfloat_exceptionFlags & 0x1f;
return 0;
}
The key is to change the header file inclusion to:
extern "C" {
#include "softfloat.h"
}
Also, softfloat.h was the only header file required.
There is no need to use a softfloat library.
The GCC compiler already have a floating point implementation.
For-eg - You can just do a A + B on float types and you should get the result.
You can also control the rounding mode using std::fesetround() and get the exceptions by using.
I am compiling a test program to test the fftw3 (ver3.3.4). Since it is not installed with root previlidge the command I used is:
gcc -lm -L/home/my_name/opt/fftw-3.3.4/lib/ -I/home/my_name/opt/fftw-3.3.4/include/ fftwtest.c
where the library is installed in
/home/my_name/opt/fftw-3.3.4/
My code is the 1st tutorial on fftw3's website:
#include <stdio.h>
#include <fftw3.h>
int main(){
int n = 10;
fftw_complex *in, *out;
fftw_plan p;
in = (fftw_complex*) fftw_malloc(n*sizeof(fftw_complex));
out = (fftw_complex*) fftw_malloc(n*sizeof(fftw_complex));
p = fftw_plan_dft_1d(n, in, out, FFTW_FORWARD, FFTW_ESTIMATE);
fftw_execute(p); /* repeat as needed */
fftw_destroy_plan(p);
fftw_free(in); fftw_free(out);
return 0;
}
when I compiled the program it returns me following errors:
/tmp/ccFsDL1n.o: In function `main':
fftwtest.c:(.text+0x1d): undefined reference to `fftw_malloc'
fftwtest.c:(.text+0x32): undefined reference to `fftw_malloc'
fftwtest.c:(.text+0x56): undefined reference to `fftw_plan_dft_1d'
fftwtest.c:(.text+0x66): undefined reference to `fftw_execute'
fftwtest.c:(.text+0x72): undefined reference to `fftw_destroy_plan'
fftwtest.c:(.text+0x7e): undefined reference to `fftw_free'
fftwtest.c:(.text+0x8a): undefined reference to `fftw_free'
collect2: ld returned 1 exit status
A quick search implies that I am not linking to the library correctly, but interestingly it does not complain about the declaration of fftw_plan and fftw_complex. In fact if I remove all functions starting with "fftw_", keeping only the declaration, it will pass the compilation.
So where did I go wrong? Is the linking correct? Any suggestion would be appreciated.
You have told the linker where to find the library through -L, but you haven't told it which library to link to. The latter you do by adding -lfftw3 at the end of the line, before -lm.
Additionally, the -L flag needs to be listed after fftwtest.c.
You need to also add that you link to the fftw library.
Add something like:
-lfftw
It depends on what the library file is actually called. (Note how you do that for the math library with -lm.)
Suppose you created a main() to deal with an exercise you asked your students.
Every student is supposed to write their own function, with the same API. And a single file will be created, with all functions and the main calling them.
Lets say: int studentname(int a, int b) is the function pattern.
One way I deal with it was using a vector of pointer to functions int (*func[MAX])(). But you need to fulfill the vector one by one func[0]=studentname;.
I wonder, is there a way a function can be called by its name somehow?
Something like: int student1(int a , int b), student2(), etc.
And in main somehow we could just call sscanf(funcname,"student%d",i); funcname();.
Do you have any other idea? Maybe
int studentname(int a, int b, char *fname)
{
strcpy(fname, "studentname");
Anything creative will do! :)
Thanks!
Beco
PS. I tried just a vector of functions, but C won't allow me! :)
int func[2]()={{;},{;}};
This way I could just give to each student a number, and voilá... But no way. It was funny though.
Edited: I'm using linux.
Edited 2: Thanks! I've accepted an answer that helped me, but I've also documented a complete example as an answer bellow.
Maybe a bit overcomplicating it, but spontaneous idea:
Compile all student source files into one shared library with the students' functions being exports.
Then enumerate all exposed functions, call and test them.
As an alternative:
Write a small tool that will compile all "student units" using a preprocessor define to replace a predefined function name with an unique name ("func1", "func2", etc.).
Then let the tool write a small unit calling all these functions while performing tests, etc.
And yet another idea:
Use C++ to write a special class template that's going to register derived classes in a object factory and just embed student's code using extern "C". Depending on the implementation this might look a bit confusing and overcomplicated though.
Then use the factory to create one instance of each and run the code.
Example for the approach with dlopen() and dlsym() (whether only one function per library or all - doesn't matter):
void *pluginlib = dlopen("student1.so", RTLD_NOW); // RTLD_NOW will load the file right away
if (!pluginlib)
; // failed to load
studentproc func = (studentproc)dlsym(pluginlib, "student1"); // this loads the function called "student1"
if (!func)
; // failed to resolve
func("hello world!"); // call the lib
dlclose(pluginlib); // unloads the dll (this will make all further calls invalid)
Similar to what #Jamey-Sharp proposed:
ask each student to provide .c file with entry function of a given name/signature
compile each .c into a shared library, named by the student name, or given whatever unique name. This step can be easily automated with make or simple script.
make a simple host application which enumerates all .so files in a given directory, and uses dlopen() and dlsym() to get to the entry point function.
now you can simply call each student's implementation.
BTW, that's how plug-ins are implemented usually, isn't it?
Edit: Here's a working proof of concept (and a proof, that each student can use the same name of the entry point function).
Here's student1.c:
#include <stdio.h>
void student_task()
{
printf("Hello, I'm Student #1\n");
}
Here's student2.c:
#include <stdio.h>
void student_task()
{
printf("Hello, I'm Student #2\n");
}
And here's the main program, tester.c:
#include <stdio.h>
#include <dlfcn.h>
/* NOTE: Error handling intentionally skipped for brevity!
* It's not a production code!
*/
/* Type of the entry point function implemented by students */
typedef void (*entry_point_t)(void);
/* For each student we have to store... */
typedef struct student_lib_tag {
/* .. pointer to the entry point function, */
entry_point_t entry;
/* and a library handle, so we can play nice and close it eventually */
void* library_handle;
} student_solution_t;
void load(const char* lib_name, student_solution_t* solution)
{
/* Again - all error handling skipped, I only want to show the idea! */
/* Open the library. RTLD_LOCAL is quite important, it keeps the libs separated */
solution->library_handle = dlopen(lib_name, RTLD_NOW | RTLD_LOCAL);
/* Now we ask for 'student_task' function. Every student uses the same name.
* strange void** is needed for C99, see dlsym() manual.
*/
*(void**) (&solution->entry) = dlsym(solution->library_handle, "student_task");
/* We have to keep the library open */
}
int main()
{
/* Two entries hardcoded - you need some code here that would scan
* the directory for .so files, allocate array dynamically and load
* them all.
*/
student_solution_t solutions[2];
/* Load both solutions */
load("./student1.so", &solutions[0]);
load("./student2.so", &solutions[1]);
/* Now we can call them both, despite the same name of the entry point function! */
(solutions[0].entry)();
(solutions[1].entry)();
/* Eventually it's safe to close the libs */
dlclose(solutions[0].library_handle);
dlclose(solutions[1].library_handle);
return 0;
}
Let's compile it all:
czajnik#czajnik:~/test$ gcc -shared -fPIC student1.c -o student1.so -Wall
czajnik#czajnik:~/test$ gcc -shared -fPIC student2.c -o student2.so -Wall
czajnik#czajnik:~/test$ gcc tester.c -g -O0 -o tester -ldl -Wall
And see it works:
czajnik#czajnik:~/test$ ./tester
Hello, I'm Student #1
Hello, I'm Student #2
I'd take a different approach:
Require every student to use the same function name, and place each student's code in a separate source file.
Write one more source file with a main that calls the standard name.
Produce a separate executable from linking main.c with student1.c, then main.c with student2.c, and so on. You might be able to use wildcards in a makefile or shell script to automate this.
That said, at least on Unix-like OSes, you can do what you asked for.
Call dlopen(NULL) to get a handle on the symbols in the main program.
Pass that handle and the function name you want to dlsym. Coerce the resulting pointer to a function pointer of the right type, and call it.
Here is an ugly preprocessor hack:
#Makefile
FILE_NAME=student
${FILE_NAME}: main.c
cc -Wall -DFILE_NAME=\"${FILE_NAME}.c\" -o $# main.c -lm
Teacher's main.c:
#include <math.h>
#include <stdio.h>
#include FILE_NAME
char *my_name(void);
double my_sin(double val);
int main(void)
{
double dd;
dd = my_sin(3.1415923563);
printf("%s: %f\n", my_name(), dd);
return 0;
}
Student's .c File:
#include <math.h>
char * my_name(void);
double my_sin(double val);
char * my_name(void)
{
return "Wildplasser-1.0";
}
double my_sin(double val)
{
return sin (val);
}
The trick lies i the literal inclusion of the student's .c file.
To avoid this, you could also use a different make line, like:
cc -Wall -o $# ${FILE_NAME}.c main.c -lm
(and remove the ugly #include FILENAME, of course)
Thanks you all. I've accepted an answer that gave me the inspiration to solve the question. Here, just to document it, is my complete solution:
File shamain.c
/* Uses shared library shalib.so
* Compile with:
* gcc shamain.c -o shamain -ldl -Wall
*/
#include <stdio.h>
#include <stdlib.h>
#include <dlfcn.h>
int main(void)
{
void *libstud;
int (*student[2])(int, int);
char fname[32];
int i,r;
libstud = dlopen("./shalib.so", RTLD_NOW);
if (!libstud)
{
fprintf(stderr, "error: %s\n", dlerror());
exit(EXIT_FAILURE);
}
dlerror(); /* Clear any existing error */
for(i=0; i<2; i++)
{
sprintf(fname, "func%d", i);
*(void **) (&student[i]) = dlsym(libstud, fname); /* c99 crap */
//student[i] = (int (*)(int, int)) dlsym(libstud, fname); /* c89 format */
}
for(i=0; i<2; i++)
{
r=student[i](i, i);
printf("i=%d,r=%d\n", i, r);
}
return 0;
}
File shalib.c
/* Shared library.
* Compile with:
* gcc -shared -fPIC shalib.c -o shalib.so -Wall
*/
#include <stdio.h>
int func0(int one, int jadv)
{
printf("%d = Smith\n", one);
return 0;
}
int func1(int one, int jadv)
{
printf("%d = John\n", one);
return 0;
}
It is a while since I have used shared libraries, but I have a feeling you can extract named functions from a DLL/shlib. Could you create a DLL/shared library containing all of the implementations and then access them by name from the main?
Per #william-morris's suggestion, you might have luck using dlsym() to do a dynamic lookup of the functions. (dlsym() may or may not be the library call to use on your particular platform.)