I try to call functions and use types of 'hrtimer' and 'ktime' but I got error messages like:
unknown type name ‘ktime_t’
HRTIMER_MODE_ABS undeclared
when i include the header file, for example, for linux/ktime.h I got:
linux/ktime.h: No such file or directory compilation terminated.
is there is any flag to add to the makefile? for now i use -lrt.
Symbols like ktime_t and HRTIMER_MODE_ABS are used inside the kernel to implement hrtimers.
When you want to use hrtimers from your program, just use the normal timer functions like timer_create or better timerfd_create.
Related
I have downloaded libgcrypt library source code and I want to customize this standard shared library by adding my function inside one particular
source code file .
Although compilation/build process of customized shared library is successful, but it shows error at linking time.
Here is what I have done .
inside /src/visibility.c file, I have added my custom function,
void MyFunction(void)
{
printf("This is added just for testing purpose");
}
I have also include function prototype inside /src/gcrypt.h
void MyFunction(void);
#build process
./configure --prefix=/usr
sudo make install
nm command find this custom function.
nm /usr/lib/libgcrypt.so | grep MyFunction
000000000000dd70 t MyFunction
Here is my sample code to access my custom function.
//aes_gcrypt_example.c
#include <stdio.h>
#include <gcrypt.h>
#include <assert.h>
int main()
{
MyFunction();
return 0;
}
gcc aes_gcrypt_example.c -o aes -lgcrypt
/tmp/ccA0qgAB.o: In function `main':
aes_gcrypt_example.c:(.text+0x3a2): undefined reference to `MyFunction'
collect2: error: ld returned 1 exit status
I also tried by making MyFunction as extern inside gcrypt.h, but in that case also I am getting same error.
Why is this happening ?
Is the customization of standard library is not allowed ?
If YES, then is there any FLAG to disable to allow customization ?
If NO, what mistake I am making ?
It would be great help if someone provide some useful link/solution for the above mentioned problem. I am using Ubuntu16.04 , gcc 4.9.
Lower-case t for the symbol type?
nm /usr/lib/libgcrypt.so | grep MyFunction
000000000000dd70 t MyFunction
Are you sure that's a visible function? On my Ubuntu 16.04 VM, the linkable functions defined in an object file have T (not t) as the symbol type. Is there a stray static kicking around and causing confusion? Check a couple of other functions defined in libgcrypt.so (and documented in gcrypt.h) and see whether they have a t or a T. They will have a T and not t. You'll need to work out why your function gets a t — it is not clear from the code you show.
The (Ubuntu) man page for nm includes:
The symbol type. At least the following types are used; others
are, as well, depending on the object file format. If lowercase,
the symbol is usually local; if uppercase, the symbol is global
(external).
The line you show says that MyFunction is not visible outside its source file, and the linker agrees because it is not finding it.
Your problem now is to check that the object file containing MyFunction has a symbol type T — if it doesn't the problem is in the source code.
Assuming that the object file shows symbol type T but the shared object shows symbol type t, you have to find what happens during the shared object creation phase to make the symbol invisible outside the shared object. This is probably because of a 'linker script' that controls which symbols are visible outside the library (or maybe just compilation options). You can search on Google with 'linker script' and various extra words ('tutorial', 'provide', 'example', etc) and come up with links to the relevant documentation.
You may need to research documentation for LibTool, or for the linker BinUtils. LibTool provides ways of manipulating shared libraries. In a compilation command line that you show in a comment, there is the option -fvisibility=hidden. I found (mostly by serendipitous accident) a GCC Wiki on visibility. See also visibility attribute and code generation options.
I was unable to find following vim completer feature. Say you write a code and you specify a type before including appropriate header file defining this type e.g.:
int main(){
uint8_t a = 0, b = 5;
...
return 0;
}
What you end up with is:
use of undeclared identifier 'uint8_t'
warning in VIM (I use YouCompleteMe) and a compilation error:
error: unknown type name ‘uint8_t’
What I'm looking for is a completer that suggests you something like
use of undeclared identifier 'uint8_t' did you include stdint.h?
If no such feature exists so far, what is the reason?
In lh-cpp I had a small feature, that given a ctags database will be able to add the inclusion statement related to the symbol under the cursor. Now I've extracted the feature to lh-dev.
I also remember to have defined an associative map that knows where a few symbols from the standard library come from, so far I only use it to automatically add the inclusion statement for types we inherit from in my C++ class snippets. What is sure, is that it could also be used for fixing missing includes (not everybody want to parse the standard library with ctags).
Note however, my scripts don't try to automatically detect all missing includes to add them. It's much too complex in real C++ projects.
You may need to add directory path to the -I option list of your compiler, or add the directory path to VIM's path option variable
:help 'path
If you don't know wich path to include, locate stdint.h could be a good start.
Related Link.
I need to change the sk_rcvlowat of program applications to to performance test. Is there a way to change the socket options from command line? Otherwise, we have to change all the source code of application program and re-compile them. I guess that each socket is associated with an inode, so that we can change the socket option via the inode.
By the way, please can anyone show me where the "socket file" located when the process created it. I have already checked /proc/<pid>/fd/<fd[X]> but they are only symbolic links like this one 10 -> socket:[13895]
Any suggestions are appreciated. Thanks in advance.
You can create a wrapper library, which will intercept all calls to setsockopt and will be able to change some parameters. This works if your application have the call to setsockopt. In another case, you can wrap different function, e.g. socket using the same approach. In wrapper of socket you need to create a socket with __socket and then change any parameter you want.
Wrapper library must be a dynamic one, with setsockopt function. This function is allowed to be overloaded by glibc. Then, start your programm as follows:
LD_PRELOAD=path_to_wrapper_library/libwrap.so ./you_program
The library will be injected (linked) into programm and will replace the setsockopt function.
This works only with dynamically linked programms (check it with ldd ./you_program - there will be some /lib/*.so if it is dynamically linked).
Original function can be called from your code with __ prefix: __setsockopt or using dlsym(RTLD_NEXT, "setsockopt");.
Some examples (not a setsockopt, but the idea of preload wrapper): http://scaryreasoner.wordpress.com/2007/11/17/using-ld_preload-libraries-and-glibc-backtrace-function-for-debugging/ or http://developers.sun.com/solaris/articles/lib_interposers_code.html
Compile to dynamic library with:
gcc wrap.c -fPIC -shared -ldl -o libwrap.so
I'm trying to use Valgrind on a program that I'm working on, but Valgrind generates a bunch of errors for one of the libraries that I'm using. I'd like to be able to tell it to suppress all errors which involve that library. The closest rule that I can come up with for the suppression file is
{
rule name
Memcheck:Cond
...
obj:/path/to/library/thelibrary.so
}
This doesn't entirely do the job, however. I have to create one of these for every suppression type that comes up (Cond, Value4, Param, etc), and it seems to still miss some errors which have the library in the stack trace.
Is there a way to give Valgrind a single suppression rule to make it completely ignore a particular library? And even if there is no way to make such a rule which covers all suppression types, is there at least a way to create a rule which ignores all errors of a particular suppression type from a particular library?
For most of the suppression types, you omit the wildcard, like so:
{
name
Memcheck:Cond
obj:/path/to/lib/lib.so.10.1
}
{
name
Memcheck:Free
obj:/path/to/lib/lib.so.10.1
}
{
name
Memcheck:Value8
obj:/path/to/lib/lib.so.10.1
}
Note that you must list each type of error separately, you can't wildcard them. You must also list the entire pathname of the library (as shown by valgrind, with any "decorations" like version numbers).
Also, leaks are handled differently -- for those you need something that looks like this:
{
name
Memcheck:Leak
fun:*alloc
...
obj:/path/to/lib/lib.so.10.1
...
}
It appears that it is necessary to include a separate suppression record for each type of error (Cond, Value4, Param, etc). But based on my testing with valgrind-3.6.0.SVN-Debian, I believe you can use the following simplified form for each type of error...
{
<insert_a_suppression_name_here>
Memcheck:Cond
...
obj:/path/to/library/thelibrary.so.*
...
}
{
<insert_a_suppression_name_here>
Memcheck:Leak
...
obj:/path/to/library/thelibrary.so.*
...
}
The three dots are called frame-level wildcards in the Valgrind docs. These match zero or more frames in the call stack. In other words, you use these when it doesn't matter who called into the library, or what functions the library subsequently calls.
Sometimes errors include "obj:" frames and sometimes they only use "fun:" frames. This is based, in general, on whether or not that function is included in the library's symbol table. If the goal is to exclude the entire library, it may work best if the library does not include symbols so that you can exclude based on the library filename instead of having to create separate suppressions for each function call within the library. Hopefully, Valgrind is clever enough to suppress errors based on library filename even when it does know the function name, but I haven't verified this.
If you do need to add suppressions based on individual functions within the library, you should be able to use the same form...
{
<insert_a_suppression_name_here>
Memcheck:Leak
...
fun:the_name_of_the_function
...
}
Note: You can include --gen-suppressions=all on the valgrind command-line in order to see the exact form and names (including any C++ mangling) required to suppress each error. You can use that output as a template for your suppression records -- in which you would usually want to replace most lines with ... in order to simplify the process of suppressing all errors that might occur in association with a specific library or function call.
Note: <insert_a_suppression_name_here> is a placeholder in which you can type whatever descriptive text that you want. It is required to not be blank.
nobar's answer almost worked for me, but I was getting a syntax error:
==15566== FATAL: in suppressions file "suppresion.error.txt" near line 4:
==15566== bad or missing extra suppression info
==15566== exiting now.
For system calls, I needed to add an extra line as the docs state:
Param errors have a mandatory extra information line at this point,
which is the name of the offending system call parameter.
So I ended up with this and it worked:
{
<sup_mmap_length>
Memcheck:Param
mmap(length)
...
fun:function_from_offending_lib
...
}
I have a programme I which I want to implement button class. I have declared all my variable in button.h and defined all methods in button.cpp and I am calling these functions in WINMAIN the following error appears.
keylogger.obj : error LNK2005: "struct HBITMAP__ * hOldBmp" (?hOldBmp##3PAUHBITMAP__##A) already defined in Button.obj
The error is for multiple defination hOldBmp but It is only defined in button.h
"Only defined in button.h" is exactly your problem. Unless you declared it as extern there and put the definition into a C++ source file (not header file), every translation unit will get their own definition of the variable.
Seems like a common error: you include the implementation of this hOldBmp pointer from two .obj files, so from two cpp files. So both obj files contain code to implement this pointer. The linker cannot decide which implementation to use in the final binary.
Solution: leave only the declaration in the header file. You may declare it extern or make it a static member variable of the button class. Put the definition in the cpp file.