Re: Rationale behind 'extern' on protypes in .h files
Ravi Shekhar Jethani writes: > To check this I installed the libgit2-dev package which installed: > /usr/include/git2/*.h , /usr/lib/libgit2.so > Now, I exported all symbols using: > $ readelf -s /usr/lib/libgit2.so > and tried to match these with 'externed' prototypes in the Git source > directory..no matches. > I am confused!!!. libgit2 is an entirely different package from Git. If you look at the libgit2 sources (https://github.com/libgit2/libgit2), look in include/git2/common.h: /** Declare a public function exported for application use. */ #if __GNUC__ >= 4 # define GIT_EXTERN(type) extern \ __attribute__((visibility("default"))) \ type #elif defined(_MSC_VER) # define GIT_EXTERN(type) __declspec(dllexport) type #else # define GIT_EXTERN(type) extern type #endif I have always used __attribute__((visibility("default"))), but the gcc man page says extern declarations are not affected by -fvisibility, so a lot of code can be recompiled with -fvisibility=hidden with no modifications. However, this means that calls to "extern" functions with no explicit visibility use the PLT, so it is more effective to use "__attribute ((visibility))" and/or "#pragma GCC visibility" to tell the compiler which "extern" declarations should be treated as hidden. However, I don't understand what the first statement means (documentation bug?) since -fvisibility=hidden causes functions declared with 'extern' to be hidden. symbols.c: EXTERN int foo(void); int foo(void) {return 1;} $ gcc -fvisibility=hidden -DEXTERN=extern -shared -o libsymbols.so symbols.c $ nm -D libsymbols.so | grep foo $ meanwhile, $ gcc -fvisibility=hidden -DEXTERN='__attribute((visibility("default")))' -shared -o libsymbols.so symbols.c $ nm -D libsymbols.so | grep foo 055c T foo > Also I checked this: > $ ldd git > There is no 'gitish' .so in the output; it seems everything is packed > inside one executable. > So your second point 'skipping the PLT...' also doesn't seem to apply here. My comment applied to shared libraries in general, not specifically to Git (which isn't a shared library). pgpHYEPGwoA09.pgp Description: PGP signature
Re: Rationale behind 'extern' on protypes in .h files
2013/12/22 Jed Brown : > There is a difference for shared libraries if you would like to control > which symbols are exported. With gcc, for example, you might compile > using -fvisibility=hidden. Any functions explicitly declared with > extern, bearing __attribute__((visibility("default")), or using > visibility pragmas will be exported (similar to __declspec(dllexport) on > Windows). Other functions will be internal to the shared library so you > don't have to worry about callers depending on those symbols and > performance can be a bit better by skipping the PLT and avoiding symbol > relocations at load time. See Drepper's guide for more. > > http://www.akkadia.org/drepper/dsohowto.pdf To check this I installed the libgit2-dev package which installed: /usr/include/git2/*.h , /usr/lib/libgit2.so Now, I exported all symbols using: $ readelf -s /usr/lib/libgit2.so and tried to match these with 'externed' prototypes in the Git source directory..no matches. I am confused!!!. Also I checked this: $ ldd git There is no 'gitish' .so in the output; it seems everything is packed inside one executable. So your second point 'skipping the PLT...' also doesn't seem to apply here. Regards, Ravi Shekhar Jethani -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Rationale behind 'extern' on protypes in .h files
Stefan Beller writes: > From my understanding there is no > difference for functions declarations being set to extern or not, > because extern is the default on functions. There is a difference for shared libraries if you would like to control which symbols are exported. With gcc, for example, you might compile using -fvisibility=hidden. Any functions explicitly declared with extern, bearing __attribute__((visibility("default")), or using visibility pragmas will be exported (similar to __declspec(dllexport) on Windows). Other functions will be internal to the shared library so you don't have to worry about callers depending on those symbols and performance can be a bit better by skipping the PLT and avoiding symbol relocations at load time. See Drepper's guide for more. http://www.akkadia.org/drepper/dsohowto.pdf pgpZa1gqS6XJz.pgp Description: PGP signature
Re: Rationale behind 'extern' on protypes in .h files
On 22.12.2013 16:51, Ravi Shekhar Jethani wrote: > > Now, my real question : > 1) I cannot understand the reason behind making function prototypes as > extern. What purpose does this serve? AFAIK we put definition in a .c > file and the prototype in a .h thats it. > > 2) Why are some prototypes in some of the .h file are extern and > others are not? > > Thank you guys for reading through. Any suggestions are humbly welcome. > Ravi S. Jethani > -- > To unsubscribe from this list: send the line "unsubscribe git" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > That's an interesting question. From my understanding there is no difference for functions declarations being set to extern or not, because extern is the default on functions. It is however important for variables to mark them extern if they're in a header file. After a quick research on the web, it may be there for historical reasons. Back then, when there were one pass compilers, the compiler needed to know where the function is to be found. (extern was not default at these times?) Another reason I could make up, would be to indicate, whether the function is in the c file having the same name as the header file. For example in builtin.h there are all the functions declared extern, as the implementation of the functions are found in builtin/*.c In another header cache-tree.h there are function declarations without explicit extern keyword, and the implementation is found in the cache-tree.c file (${SAME-NAME-AS-HEADER}.C) This is however not always the case as found in archive.{c,h} I'd be also interested in knowing the real reason for this rationale. Thanks, Stefan -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html