I'm trying to understand how glibc initializes errno without the preprocessor substituting the errno symbol.
I first tried to implement a simple version myself based on csu/errno-loc.c and csu/errno.c:
myerrno.h
#ifndef MYERRNO_H
#define MYERRNO_H
extern int *myerrno_location(void);
#define myerrno (*myerrno_location())
#endif
myerrno.c
#include "myerrno.h"
static int myerrno = 0;
int *myerrno_location(void){
return &myerrno;
}
However, when I try to compile I receive the following error messages:
myerrno.c:3:1: error: function ‘myerrno_location’ is initialized like a variable
myerrno.c:3:12: error: static declaration of ‘myerrno_location’ follows non-static declaration
myerrno.h:4:13: note: previous declaration of ‘myerrno_location’ was here
I can tell that the preprocessor is substituting (*myerrno_location(void)) when it encounters myerrno on line 3 -- and naturally this is expected behavior.
I don't understand why this isn't a problem for glibc. How do thread-safe implementations of errno get around this preprocessor substitution issue without renaming the static errno variable?
Fixing your issue is as easy as changing the name of your static variable.
static int myerrno_variable = 0;
int *myerrno_location(void){
return &myerrno_variable;
}
Notice that your version is still not thread safe since all threads are accessing the same myerrno_variable. A real implementation would return a thread specific memory location. In GCC, there is an extension that provides the __thread storage class. C.11 provides its own version of that called thread_local, but it is only available if thread support is provided by the implementation (which can be checked by looking if __STDC_NO_THREADS__ is defined or not).
static __thread int myerrno_variable_gcc; /* if using GCC */
static thread_local int my_errno_variable_c11; /* if __STD_NO_THREADS__ isn't defined */
On a POSIX system without a thread local feature, an implementation could use pthread_getspecific() to get a pointer to thread specific data that was allocated for each thread, and set with pthread_setspecific(). See the manual for more information.
Related
SYNOPSIS section in perror's man page is:
#include <stdio.h>
void perror(const char *s);
#include <errno.h>
const char * const sys_errlist[];
int sys_nerr;
int errno; /* Not really declared this way; see errno(3) */
according to man page specification, SYNOPSIS section indicates that
For functions, it shows any required data declarations or #include directives, followed by the function declaration.
The following code:
#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>
int main()
{
char *ls_args[2] = {"nonsense", NULL};
execv(ls_args[0], ls_args); // no return
perror("execve failed");
return 2;
}
outputs error message execve failed: No such file or directory, with corresponding errno being 2
since errno is a global variable (actually a macro) defined in errno.h, and errno.h header is not included, how does this code trigger errno modification?
What does #include <errno.h> ... int errno; mean in the SYNOPSIS section? seems like perror() can be called without this portion of code, thanks!
According to the C standard, the macro errno is declared in errno.h and you must include errno.h explicitly if you want to write a portable program which uses errno. The manpage synopsis is telling you that. (It is not saying that you need to include errno.h in order to use perror. Sometimes the Synopsis section tells you about other related library facilities.)
Nothing in the standard specifies what the definition of the errno macro is, or exactly where in the implementation you can find any objects referenced by the expansion of that definition. The implementation of perror obviously needs to be able to access whatever object errno refers to, but since it doesn't need to be portable, it is completely unspecified how that works.
In particular, recent C standards require that the object errno refers to be thread-local, so that every thread has its own errno object. (If this were not the case, the mechanism would be essentially unusable in multithreaded code.) The precise implementation of thread-local storage is also not specified by the standard, and on a particular implementation it might be mapped onto some facility provided by the underlying operating system.
I have written a multithread server program in C, which echoes back all the data that a client sends.
Initially, I used poll() function in my program to detect POLLRDHUP event, for that I defined _GNU_SOURCE macro (This event is defined here).
Later I updated my code & removed poll() function, however I forgot to remove _GNU_SOURCE macro.
Now my code is finally complete (and a little long to post, more than 250 lines). Before removing macro I was compiling my program using:
gcc multi_thread_socket_v4.c -Wall -Werror -g -lpthread -o multi_thread_socket
and it worked fine: No errors, no warnings
After I removed the macro definition, and compiled using same command-line, the output of gcc was:
multi_thread_socket_v4.c: In function ‘main’:
multi_thread_socket_v4.c:194: warning: implicit declaration of function ‘pthread_mutexattr_settype’
multi_thread_socket_v4.c:194: error: ‘PTHREAD_MUTEX_ERRORCHECK’ undeclared (first use in this function)
multi_thread_socket_v4.c:194: error: (Each undeclared identifier is reported only once
multi_thread_socket_v4.c:194: error: for each function it appears in.)
I have included all the required libraries as it worked fine initially.
I peeked into pthread.h at /usr/include/pthread.h and found out this:
/* Mutex types. */
enum
{
PTHREAD_MUTEX_TIMED_NP,
PTHREAD_MUTEX_RECURSIVE_NP,
PTHREAD_MUTEX_ERRORCHECK_NP,
PTHREAD_MUTEX_ADAPTIVE_NP
#ifdef __USE_UNIX98
,
PTHREAD_MUTEX_NORMAL = PTHREAD_MUTEX_TIMED_NP,
PTHREAD_MUTEX_RECURSIVE = PTHREAD_MUTEX_RECURSIVE_NP,
PTHREAD_MUTEX_ERRORCHECK = PTHREAD_MUTEX_ERRORCHECK_NP,
PTHREAD_MUTEX_DEFAULT = PTHREAD_MUTEX_NORMAL
#endif
#ifdef __USE_GNU
/* For compatibility. */
, PTHREAD_MUTEX_FAST_NP = PTHREAD_MUTEX_TIMED_NP
#endif
};
and this:
#ifdef __USE_UNIX98
/* Return in *KIND the mutex kind attribute in *ATTR. */
extern int pthread_mutexattr_gettype (__const pthread_mutexattr_t *__restrict
__attr, int *__restrict __kind)
__THROW __nonnull ((1, 2));
/* Set the mutex kind attribute in *ATTR to KIND (either PTHREAD_MUTEX_NORMAL,
PTHREAD_MUTEX_RECURSIVE, PTHREAD_MUTEX_ERRORCHECK, or
PTHREAD_MUTEX_DEFAULT). */
extern int pthread_mutexattr_settype (pthread_mutexattr_t *__attr, int __kind)
__THROW __nonnull ((1));
I checked out here to check if __USE_UNIX98 is a feature test macro, but it was not there.
So please help me understanding the reasons for the error, because the function & the macro where gcc shows error are defined in POSIX standard. I do not know what more info regarding my problem will be required so please tell me, I will update my question.
You should use
#define _POSIX_C_SOURCE 200112L
if you want to use POSIX features such as pthread_mutexattr_settype ... see http://pubs.opengroup.org/onlinepubs/007904975/functions/xsh_chap02_02.html
Another possibility is
#define _XOPEN_SOURCE 700
See http://man7.org/linux/man-pages/man7/feature_test_macros.7.html and http://pubs.opengroup.org/onlinepubs/9699919799/
Setting _GNU_SOURCE includes POSIX and lots of other definitions.
P.S. I would expect that including <pthread.h> includes <features.h>, which by default defines _POSIX_C_SOURCE as 200112L, but it's possible that you have defined something that overrides that ... see /usr/include/features.h on your system for details of the symbols and their usage.
It doesn't, your problem likely lies elsewhere.
I just compiled a trivial program with the following content:
#include <pthread.h>
int main(int argc, char **argv)
{
pthread_mutexattr_t attr;
pthread_mutexattr_init(&attr);
pthread_mutexattr_settype(&attr, PTHREAD_MUTEX_ERRORCHECK);
return 0;
}
This compiles perfectly with gcc -pthread -Wall -Werror a.c.
It's possible that another part of your program causes this, by eg. doing something silly like defining _PTHREAD_H, or some other minor sabotage.
You might want to try to get a minimal test case by using a tool like delta or creduce, which will probably make the problem evident.
When you're using old libraries (e.g. 2.1.x) you should use
#define __USE_UNIX98
Using a macro beginning with "__" it's not usually a good idea, but sometimes it's the only way... see also this discussion
from here
48 struct snd_card *snd_cards[SNDRV_CARDS];
49 EXPORT_SYMBOL(snd_cards);
I am not getting whats the meaning of it and why that is used. I tried to search about it but not understanding the meaning of that.
It makes a symbol accessible to dynamically loaded modules (provided that said modules add an extern declaration).
Not long ago, someone asked how to use it.
Here is a good explanation.
https://www.quora.com/What-is-the-difference-between-extern-and-EXPORT_SYMBOL-in-Linux-kernel-codes
Extern is a C storage class keyword. In the kernel, as in any other C
code, it tells the compiler that the definition of the variable or
function it qualifies is implemented in another “file”, or rather,
more accurately Translation unit (programming) - Wikipedia. The
translation unit that does define it should not use the static
qualifier. Therefore, the symbol table has an entry corresponding to
it. At link time, the symbol is resolved as normal. There is nothing
kernel specific about “extern”.
EXPORT_SYMBOL() is a macro the Linux kernel headers define. It has not
much in common with extern. It tells the kbuild mechanism that the
symbol referred to should be part of the global list of kernel
symbols. That, in turn allows kernel modules to access them. Code that
is built into the kernel itself (as opposed to a module) can, of
course, access any non-static symbol via an extern declaration, in
accordance with regular C. The EXPORT_SYMBOL() mechanism allows us to
export a symbol for use by loadable modules as well. An interesting
thing is that a symbol thus exported by one module becomes accessible
to another module that may depend on it!
To summarise, extern is not kernel specific. It is used to qualify a
declaration to a non-static symbol from another translation unit.
EXPORT_SYMBOL() is specific to the Linux kernel. It is used in the
translation unit of the definition to make the symbol available to
loadable modules.
So EXPORT_SYMBOL is just a mechanism like extern, but it's for reference between loadable modules not file.
To move forwards, we can guess it's achived by the extern because extern is form C which is the foundation.
Here is a clue.
https://elixir.bootlin.com/linux/v4.6.7/source/include/linux/export.h#L56
#define EXPORT_SYMBOL(sym) \
__EXPORT_SYMBOL(sym, "")
/* For every exported symbol, place a struct in the __ksymtab section */
#define __EXPORT_SYMBOL(sym, sec) \
extern typeof(sym) sym; \
__CRC_SYMBOL(sym, sec) \
static const char __kstrtab_##sym[] __attribute__((section("__ksymtab_strings"), aligned(1))) = VMLINUX_SYMBOL_STR(sym); \
extern const struct kernel_symbol __ksymtab_##sym; \
__visible const struct kernel_symbol __ksymtab_##sym __used __attribute__((section("___ksymtab" sec "+" #sym), unused)) = { (unsigned long)&sym, __kstrtab_##sym }
First declare a extern sym.
Then a string __kstrtab_##sym = = VMLINUX_SYMBOL_STR(sym).
Last a extern struct kernel_symbol __ksymtab_##sym = { (unsigned long)&sym, __kstrtab_##sym }. &sym record the real address of the sym such as a function or variable, _kstrtab##sym record the name string.
Not an answer per se but a demonstration, as promised from my comment, that exported symbols are not required to be non-static. The below 2 modules demonstrate this:
/* mod1.c */
#include <linux/module.h>
static int mod1_exp_func(int i)
{
pr_info("%s:%d the value passed in is %d\n",
__func__, __LINE__, i);
return i;
}
EXPORT_SYMBOL(mod1_exp_func); /* export static symbol */
static int __init mod1_init(void)
{
pr_info("Initializing simple mod\n");
return 0;
}
static void __exit mod1_exit(void)
{
pr_info("This module is exiting\n");
}
module_init(mod1_init);
module_exit(mod1_exit);
MODULE_LICENSE("GPL v2");
And the second module
/* mod2.c */
#include <linux/module.h>
extern int mod1_exp_func(int);
static int __init mod2_init(void)
{
pr_info("Initializing mod2\n");
pr_info("Calling exported function in mod1\n");
mod1_exp_func(3);
return 0;
}
static void __exit mod2_exit(void)
{
pr_info("mod2 exiting\n");
}
module_init(mod2_init);
module_exit(mod2_exit);
MODULE_LICENSE("GPL v2");
These were tested on CentOS 6 & CentOS 7: kernels 2.6.32 and 3.10 (respectively). Loading mod1.ko and then mod2.ko will result in the value passed to mod1_exp_func() being printed to the kernel log buffers.
In object-oriented languages (C++) you can execute code before main() by using a global object or a class static object and have their constructors run the code you want.
Is there any way to do this in C? I don't have any specific problem I'm trying to solve, I'm just curious. One thing this might be useful for is automatically initializing a library.
You can do it with __attribute__ ((constructor)). I've tested the following example with both gcc and clang. That being said, it's not part of the language.
#include <stdio.h>
void __attribute__ ((constructor)) premain()
{
printf("premain()\n");
}
int main(int argc, char *argv[])
{
printf("main()\n");
return 0;
}
It does the following:
$ ./test
premain()
main()
GCC documents it at: https://gcc.gnu.org/onlinedocs/gcc-8.3.0/gcc/Common-Function-Attributes.html#Common-Function-Attributes
There are ways using __attribute__ but those are very specific to your compiler and code that is written using these are not really portable. On the other hand, the C language does not provide any start-up modules/libraries.
In C, logically main() is the first function called by the OS. But before calling main(), the OS calls another function called start-up module to setup various environment variables, initialize (un-initialized) static variables, build a stack frame (activation record) and initialize the stack pointer to the start of the stack area and other tasks that have to be done before calling main().
Say if you are writing code for embedded systems where there is no-or-minimal OS to do the above mentioned work, then you should explore these options which are compiler dependent. Other than GCC, Turbo-C and Microsoft C compilers provides facilities to add code in a particular hardware machine (f.e. 8086 machines).
In other words, the start-up modules are not meant for the programmers.
With gcc, you can do so by using the constructor function attribute, e.g.
__attribute__ ((__constructor__))
void foo(void) {
...
}
This will invoke foo before main.
Note: This is probably not portable to other compilers.
You can initialize global variables but not call functions within these initializations.
If your compiler can compile cpp files you can add a file with a class that call in the costructor your initialization code. The class must be allocated statically. For example:
#include "ext.h"
class cext
{
public:
cext()
{
ExtInit();
}
~cext(){};
};
cext g_cext;
The ExtInit() function must be defined as extern "C" in file ext.h.
#ifdef __cplusplus
extern "C" {
#endif
void ExtInit (void);
#ifdef __cplusplus
}
#endif
I was wondering if there is a way of finding which function called the current function (at runtime) in C.
I know you could use __FUNCTION__ in gcc, but is there a way without using the C preprocessor?
Probably not.
Cheers
No, there isn't. C isn't a particularly introspective language - things like the name of a function (or pieces of your call stack) simply aren't available at runtime in any sane fashion.
If, for some reason, you are looking for a lot of work for very little benefit, then you can build your programs with debug symbols, and you can write stack-walking and debug symbol lookup code. Then you might be able to find this out on the fly. But be careful, because the symbols you'll see in the debug info will be decorated with type info if you've got any C++ involved.
You've tagged this post gcc, so the relevant details ARE available, however this falls into the 'not recommended' and 'not guaranteed to be the same between compiler versions' territory.
Assuming you have a function f() from which you want to know the caller.
Rename that function to f_func() and define a macro f() that prints __func__ and then calls f_func(). Example:
void
f_func()
{
do something;
}
#define f() \
do { \
printf("f called from %s\n", __func__); \
f_func(); \
} while (0)
void
a()
{
f();
}
void
b()
{
f();
}
int
main(int argc, char **argv)
{
a();
b();
return(0);
}
There's no way to get a function name in the runtime. The only way is the preprocessor but it's very limited in its capabilities.
In case you have debug information available, you could walk the stack and get the function names from the debugging information. This is, however, neither a robust nor a portable solution.
There are couple of GNU functions that allow you to get function addresses and names from backtrace - backtrace() and backtrace_symbols(), but you need to compile your binary with -rdynamic flag
NO
The short answer is NO
but with preprocessor it can be done like this
Getting the name of the calling function in C (using the preprocessor)
Assuming you have a function f() from which you want to know the caller only for debugging purpose.
Rename that function to f_func() and define a macro f() that calls a version of f that prints func and then calls f_func() when DEBUG is defined.
In the final release the information is removed by calling the real function f_func()
Example
#ifdef DEBUG
#define f(a,b,c) f_debug(a,b,c, __func__)
#else
#define f(a,b,c) f_func(a,b,c)
#endif
bool f_func(int par1, int par2, int par3)
{
do_somthing();
}
bool f_debug((int par1, int par2, int par3, const char calling_func_name[])
{
printf("f called from %s\n", calling_func_name);
f_func();
}
void a()
{
f();
}
void b()
{
f();
}
int main(int argc, char **argv)
{
a();
b();
return(0);
}
Result is:
when DEBUG is defined
f called from a
f called from b
Use the __func__ identifier. The standard (section 6.4.2.2) requires that it be present for precisely this purpose:
The identifier __func__ shall be implicitly declared by the translator as if, immediately following the opening brace of each function definition, the declaration
static const char __func__[] = "function-name";
appeared, where function-name is the name of the lexically-enclosing function.
As Steve Jessop notes in a comment, this isn't part of the preprocessor as such, but an intrinsic part of the compiler.
There may well be ways of finding out this name by walking the stack and looking at debugging symbols. Cute, but insane.