I was surprised to see that adding an a-priori non defined "double sin(double)" function in a C code that is JIT'ed actually worked... This is explained in LLVM doc, the JIT engine automatically falls back to dlsym("sin") which works as my code was linked with libm
However, I want to avoid this and have no built-in function in my JIT'ed code! How can I disable this behavior?
Thanks
You can call ExecutionEngine::DisableSymbolSearching(true) to disable automatically resolving with the linked code.
Related
I am compiling a project with a modified version of clang using link time optimization (lto) and O2 optimization level. O0 and O1 are doing fine, but sadly O2 removes some calls to functions. Is there a way to tell the optimization to omit specific functions?
I have already tried using volatile variables as well as __attribute__ ((optimize("0"))) without success.
Solutions only available directly on llvm IR level are also welcome.
Edit: Maybe I should explain the situation with a little more detail.
The modified clang adds calls to a custom runtime lib which is build together with clang.
Some of this inserted calls get optimized away.
I believe __attribute(used)__ (GCC) or llvm.used (LLVM) is what you're looking for.
Adding __attribute__((noinline)) will keep the so-designated functions from disappearing. You could also prevent it globally with -fno-inline.
I am suffering with a bizarre issue came up in the code am working in Code Composer.
That is,in the code am working on there are some inline functions called,through an .inl file.Everything seem fine so far,the problem comes when instead of calling and executing that function,a Visual studio (or other default program for defined for editing your code) comes up and in the screen and the pointer passed to the function becomes null while it was not...
Thanks very much!
You can check the disassembly for your code. The assembly for the inline function should be directly inserted there. Check to see if that is happening. If not, it is your compiler that has an issue.
Why don't you try putting the inline functions in a .hpp file and see if you get the same problem?
I am trying to embed a plplot graphics inside a gtk window at OSX. I used plplotcanvas but so far i have no success at all. At the wiki there is one example (http://archive.tcltk.co.kr/doc/plplot-html-5.9.4/gui.html) but i can find nothing else. The version i am using is 5.10.0.
Anyone knows how to do it or any advise?. At the examples on the wiki the compiler can not find plplotcanvas.h after change the libraries the compiler says the same for every function:
plem.c:62:2: warning: implicit declaration of function 'plplot_canvas_plwid' is invalid in C99 [-Wimplicit-function-declaration]
plplot_canvas_plwid(canvas,2);
It is the same with every function of plplotcanvas. Thanks in advance guys.
Either you got a version mismatch of libs and API you use, a typo, or you simply forgot to include appropriate headers.
For a more detailed diagnosis you need to post some (relevant) code chunks.
There are plenty of examples for plplot usage, each screenshot links to a full code example
I want to modify glibc. So I have downloaded a version of it and made some changes in the code. For example I've made changes to memset. However, I don't see any difference if I use the .so file produced by the compilation (using LD_PRELOAD) as compared to when I don't do any LD_PRELOAD. memset behaves like it does. Why is that so? Is that maybe the compiler is inlining memset and not using anything from the shared object? I don't understand this. I even made changes to printf, but still nothing. Why is that so. How can I modify glibc (for testing purposes), so that I do see a change?
Moreover, when I tried to change pthread_create (and ofcourse LD_PRELOAded libpthread.so) by introducing printf( "pthread_create") in the beginning of that function, I just get a segmentation fault. What is going on here? Also if I check the difference in the libc.so after making changes in glibc source, I see no difference in the produced versions. What is happening here. This is driving me nuts!
GCC provides built-in versions of several functions, including memset() and printf(). It does not link to glibc's implementation of these functions.
Try passing the -fno-builtin compiler option to inhibit this behavior.
Is there a way with gcc and GNU binutils to mark some functions such that they will generate an error at link-time if used? My situation is that I have some library functions which I am not removing for the sake of compatibility with existing binaries, but I want to ensure that no newly-compiled binary tries to make use of the functions. I can't just use compile-time gcc attributes because the offending code is ignoring my headers and detecting the presence of the functions with a configure script and prototyping them itself. My goal is to generate a link-time error for the bad configure scripts so that they stop detecting the existence of the functions.
Edit: An idea.. would using assembly to specify the wrong .type for the entry points be compatible with the dynamic linker but generate link errors when trying to link new programs?
FreeBSD 9.x does something very close to what you want with the ttyslot() function. This function is meaningless with utmpx. The trick is that there are only non-default versions of this symbol. Therefore, ld will not find it, but rtld will find the versioned definition when an old binary is run. I don't know what happens if an old binary has an unversioned reference, but it is probably sensible if there is only one definition.
For example,
__asm__(".symver hidden_badfunc, badfunc#MYLIB_1.0");
Normally, there would also be a default version, like
__asm__(".symver new_badfunc, badfunc##MYLIB_1.1");
or via a Solaris-compatible version script, but the trick is not to add one.
Typically, the asm directive is wrapped into a macro.
The trick depends on the GNU extensions to define symbol versions with the .symver assembler directive, so it will probably only work on Linux and FreeBSD. The Solaris-compatible version scripts can only express one definition per symbol.
More information: .symver directive in info gas, Ulrich Drepper's "How to write shared libraries", the commit that deprecated ttyslot() at http://gitorious.org/freebsd/freebsd/commit/3f59ed0d571ac62355fc2bde3edbfe9a4e722845
One idea could be to generate a stub library that has these symbols but with unexpected properties.
perhaps create objects that have the name of the functions, so the linker in the configuration phase might complain that the symbols are not compatible
create functions that have a dependency "dont_use_symbol_XXX" that is never resolved
or fake a .a file with a global index that would have your functions but where the .o members in the archive have the wrong format
The best way to generate a link-time error for deprecated functions that you do not want people to use is to make sure the deprecated functions are not present in the libraries - which makes them one stage beyond 'deprecated'.
Maybe you can provide an auxilliary library with the deprecated function in it; the reprobates who won't pay attention can link with the auxilliary library, but people in the mainstream won't use the auxilliary library and therefore won't use the functions. However, it is still taking it beyond the 'deprecated' stage.
Getting a link-time warning is tricky. Clearly, GCC does that for some function (mktemp() et al), and Apple has GCC warn if you run a program that uses gets(). I don't know what they do to make that happen.
In the light of the comments, I think you need to head the problem off at compile time, rather than waiting until link time or run time.
The GCC attributes include (from the GCC 4.4.1 manual):
error ("message")
If this attribute is used on a function declaration and a call to such a function is
not eliminated through dead code elimination or other optimizations, an error
which will include message will be diagnosed. This is useful for compile time
checking, especially together with __builtin_constant_p and inline functions
where checking the inline function arguments is not possible through extern
char [(condition) ? 1 : -1]; tricks. While it is possible to leave the function
undefined and thus invoke a link failure, when using this attribute the problem
will be diagnosed earlier and with exact location of the call even in presence of
inline functions or when not emitting debugging information.
warning ("message")
If this attribute is used on a function declaration and a call to such a function is
not eliminated through dead code elimination or other optimizations, a warning
which will include message will be diagnosed. This is useful for compile time
checking, especially together with __builtin_constant_p and inline functions.
While it is possible to define the function with a message in .gnu.warning*
section, when using this attribute the problem will be diagnosed earlier and
with exact location of the call even in presence of inline functions or when not
emitting debugging information.
If the configuration programs ignore the errors, they're simply broken. This means that new code could not be compiled using the functions, but the existing code can continue to use the deprecated functions in the libraries (up until it needs to be recompiled).