I'm building a syscall to kernel Linux, so I need to export a structure to use in user level. I've read some documentation and they said I need to use a *.h below kernel/include/uapi or use make headers_install. But nothing seems to work. gcc doesn't identify the data type I tried to export.
So, what are the prerequisites to use this command and what exactly it makes (what headers it export and under what conditions) ?
Related
Linux kernel source can use make tags to get the tag for editor.
In scripts/tags.sh, line7 and line8 say that "Uses the following environment variables: ARCH, SUBARCH, SRCARCH, srctree, src, obj"
I want to ask What are these variable meaning?
I already read this article,but it just mention the two vairables, SRCARCH and SUBARCH.
Variables you should use
Next variables can be passed to tags.sh (actually you should pass them to make tags cscope command, and Makefile will pass them to tags.sh for you).
ARCH: which architecture to index. You can see all architectures list just by doing ls -l arch/ in your kernel source tree.
SUBARCH: the meaning of this variable depends on your architecture:
if ARCH=arm, SUBARCH will be used to determine arch/arm/mach-* and arch/arm/plat-* directories, and these directories will be indexed
if ARCH=um, use SUBARCH to specify which architecture you actually want to use in your User-Mode Linux (like SUBARCH=arm or SUBARCH=x86)
for the rest of architectures, you can omit this variable
ALLSOURCE_ARCHS: use this to index more than one architecture. Like ALLSOURCE_ARCHS="x86 mips arm" or ALLSOURCE_ARCHS="all". If you only want to index one architecture, omit this variable and use ARCH instead.
COMPILED_SOURCE: set this variable to 1 if you want to index only actually compiled source files. If you want to index all source files, omit setting this variable.
O= (this is actually Makefile parameter): use absolute paths (useful if you want to load created cscope/ctags index files outside of kernel directory, e.g. for development of out-of-tree kernel modules). If you want to use relative paths (i.e. you're gonna do development only in kernel dir), just omit that parameter.
Variables you don't need to touch
SRCARCH: being set from ARCH variable in Makefile and then passed to script. You probably don't need to mess with it, just set ARCH variable correctly
srctree: kernel source tree path. This variable will be passed from Makefile automatically if you're using this script via make cscope tags.
src and obj variables: those are not used by scripts/tags.sh anymore. It was replaced by utilizing KBUILD_SRC variable, which is provided from Makefile automatically, when you provide O=... parameter to it.
Usage
Basically, I'd recommend to only use scripts/tags.sh via make invocation. Example:
$ make O=. ARCH=arm SUBARCH=omap2 COMPILED_SOURCE=1 cscope tags
or
$ make ARCH=x86 cscope tags
I'm running Linux and have a situation like this:
A binary file 'bin1' loads via dlopen 'shared1.so' which is linked with 'shared2.so' and 'shared3.so'.
if 'shared2.so' or 'shared3.so' is missing the program 'bin1' won't run.
There are runs that I know that I won't touch any code from 'shared2.so' and I want 'bin1' to be able to run even when this library is missing, can this be done ?
You could ship program with dummy shared2.so library. You might need to add dummy functions which shared1 expects to find there. This can be done manually or via automatic tool like Implib.so.
Say I have a binary server, and when it's compiled, it's linked from server.c, static_lib.a, and dynamically with dynamic_lib.so.
When server is executed and it loads dynamic_lib.so dynamically, but on the code path, dynamic_lib.so actually expects some symbols from static_lib.a. What I'm seeing is that, dynamic_lib.so pulls in static_lib.so so essentially I have two static_lib in memory.
Let's assume there's no way we can change dynamic_lib.so, because it's a 3rd-party library.
My question is, is it possible to make dynamic_lib.so or ld itself search the current binary first, or even not search for it in ld's path, just use the binary's symbol, or abort.
I tried to find some related docs about it, but it's not easy for noobs about linkers like me :-)
You can not change library to not load static_lib.so but you can trick it to use static_lib.a instead.
By default ld does not export any symbols from executables but you can change this via -rdynamic. This option is quite crude as it exports all static symbols so for finer-grained control you can use -Wl,--dynamic-list (see example use in Clang sources).
I have some non-accessible code that I call, that does dlopen("lib.so", RTLD_LOCAL).
The problem is that I need to control the search path of dlopen(). The answer to this problem is quite typically "set LD_LIBRARY_PATH", but I don't know the actual path to set until after application startup, so I can't put a wrapper script that sets it and then invokes my application.
According to the documentation of ld.so and of dlopen, LD_LIBRARY_PATH is only examined at application startup. If you change it afterwards inside the application with setenv, it won't change the lookup list of dlopen().
I know that specifying the full path to dlopen() would be a strategy, but I don't have access to that dlopen call, so this option is also not possible.
Am I out of options or is there some magic strategy I can't find?
I believe it is not easily possible.
However, if you are crazy enough to patch ld.so from its source code, you might do something.
Maybe you could use some LD_PRELOAD trick.
But if it is a matter of finding which exact file is dlopen-ed, why don't you strace(1) your program to understand which files are mmap-ed?
You can also use pmap or simply cat /proc/$(pidof your-program)/maps
If you can change some lines of source code, consider dladdr(3) to find out where is some dlsym-ed function... And you might also use dl_iterate_phdr(3)
If your LD_LIBRARY_PATH is relative to your application root - you can use wrapper script, which will extract path to itself using $(dirname $0) and set up correct LD_LIBRARY_PATH.
Another trick (but it's not a good idea to do so) is to provide your own lib.so that will be just a proxy to actual lib.so. You can initialize all references on your proxy library load using library init functionality. Please refer to this question.
I am writing a Linux kernel module which need to export some header files to userspace.
I am wondering if there is any standard method which use Kernel package to do required sanitation of headers (For example something like "$(MAKE) -C $(KERNELDIR) M=$(PWD) headers_install" if exist).
Should i take care of headers manually?
Any suggestion?
There is no such functionality out of the box because most kernel modules which need something like that come with an extra "devel" package which contains the (cleaned) header files and probably a shared library to talk to the module.
As for cleaning your headers, I suggest to split the header files into a generic part (which you export) and an internal part (which only the kernel module can see). typedef is your friend.
You can do it by adding 'header-y=' to one of the Kbuild under /include/uapi