Translating address to function name - linux

Say I have an address acquired by __builtin_return_address(0).
Sometime later I want to translate it to a coreesponding function name.
There's dladdr(3) which works only for dynamic libraries.
Is there any way to receive function of any symbol (maybe by libunwind, backrace_symbol() etc.)?

Compile all your code (and perhaps even some shared libraries that you use) with debug info (-g). Notice that GCC enables to use both -g and some optimization flag like -O2 (of course, in that case, the debug info is "approximate"). So you can compile code with gcc -Wall -g -O2 etc....
Then use perhaps Ian Taylor's libbacktrace which is included in recent versions of GCC.
BTW, dladdr or backtrace_symbol might also work (but I recommend using libbacktrace because it is parsing DWARF info). And dladdr(3) does work on symbols from the executable itself. You may need to link your executable with -rdynamic flag.
Notice also that static symbols (notably  static functions) "don't really exist" in the ELF executable (only global symbols are kept in it) so dladdr cannot give them. Be also aware of the visibility function attribute and pragma.

Related

Conditionally finding dependencies of shared library in CMake

In Linux I have a shared library somelib.so, which could be optionally compiled against several other shared libs, say, dep1 and dep2. Now I'm writing a client application which uses somelib, but I don't now in advance if somelib was compiled with dep1 and dep2 or not until I get a linker error.
Is there a way to find this out using CMake? I need something like
IF somelib DEPEND ON dep1 THEN...
... client application which uses somelib, but I don't now in advance
if somelib was compiled with dep1 and dep2 ... I need something like
IF somelib DEPEND ON dep1 THEN...
On Linux I believe the way to solve it is using LD linker options -Wl,--exclude-libs,ALL and -Wl,--as-needed.
Always include -ldep1 and -ldep2 as library options. Then use -Wl,--as-needed to exclude the libraries if unneeded.
If I recall correctly, this trick dates back 20 or 30 years or so for the math library -lm. Sometimes math symbols were included in glibc and other times they were included in -lm. So you always linked against -lm and allowed the linker to discard the -lm library with -Wl,--as-needed.
In fact the ld(1) man page says to push and pop state when using the trick:
One target for this option are specifications for pkg-config.
When used with the --libs option all possibly needed libraries
are listed and then possibly linked with all the time. It is
better to return something as follows:
-Wl,--push-state,--as-needed -libone -libtwo -Wl,--pop-state
-Wl,--exclude-libs,ALL is an option to keep you from re-exporting symbols from -ldep1 and -ldep2. If the libraries are not used then you should not need -Wl,--exclude-libs,ALL.
I believe the two CMake settings for a static library and shared object when building somelib.so are:
set(OUR_LINKER_FLAGS "-Wl,--exclude-libs,ALL -Wl,--as-needed -ldep1 -ldep2")
set(CMAKE_MODULE_LINKER_FLAGS "${CMAKE_MODULE_LINKER_FLAGS} ${OUR_LINKER_FLAGS}")
set(CMAKE_SHARED_LINKER_FLAGS "${CMAKE_SHARED_LINKER_FLAGS} ${OUR_LINKER_FLAGS}")
Also see ld(1) man page, CMAKE_MODULE_LINKER_FLAGS and CMAKE_SHARED_LINKER_FLAGS in the CMake docs. You might also be interested in CMAKE_EXE_LINKER_FLAGS if you are building executables.

How to keep a specific symbol in binary file?

I have a static lib (my_static_lib) which I link to an executable binary file. Some of the symbols, but not all, are used in my binary.
A second library, dynamically loaded(my_shared_lib), is expecting to receive some symbols from my_static_lib through symbol injection from the binary. But those symbols are not used by my_binary, so they are stripped off the final bin file.
So, at runtime, my_shared_lib complains that it cannot find __my_stripped_symbols__ and crashes.
Is there a way to force the linker to keep __my_stripped_symbols__? I would prefer something that can be cleanly written in a Makefile.am (autotools)
(-binary file makefile)
-L$(top_builddir)/static_lib -lmy_static_lib --magic-flag-to-keep-stripped-symbol
I do not want to link my_static_lib with my_shared_lib because it will generate strange conflicts in other parts of a rather complex group of executables/shared libraries.
When you link my_static_lib to your application, you want to use the --whole-archive option. It's documented in the ld options docs.
If you're linking with gcc, it looks something like this:
-L$(top_builddir)/static_lib -Wl,-whole-archive -lmy_static_lib -Wl,-no-whole-archive
That will make sure the entire library is kept, and not just the specific functions that your executable uses.
You also need to make sure that the symbols get exported. If the symbols from your static library aren't being exported already, you make need a combination of -fvisibility=hidden and use __attribute__ ((visibility("default"))) to mark up the ones you want exported. You can read a little more about it in the gcc docs

How to restrict access to symbols in shared object?

I have a plug-in in the form of a shared library (bar.so) that links into a larger program (foo). Both foo and bar.so depend on the same third party library (baz) but they need to keep their implementations of baz completely separate. So when I link foo (using the supplied object files and archives) I need it to ignore any use of baz in bar.so and vice versa.
Right now if I link foo with --trace-symbol=baz_fun where baz_fun is one of the offending symbols I get the following output:
bar.so: definition of baz_fun
foo/src.a(baz.o): reference to baz_fun
I believe this is telling me that foo is referencing baz_fun from bar.so (and execution of foo confirms this).
Solutions that I have tried:
Using objcopy to "localize" the symbols of interest: objcopy --localize-symbols=local.syms bar.so where local.syms contains all of the symbols of interest. I think I might just be confused here and maybe "local" doesn't mean what I think it means. Regardless, I get the same output from the link above. I should note that if I run the nm tool on bar.so prior to using objcopy all of the symbols in question have the T flag (upper-case indicating global) and after objcopy they have a t indicating they are local now. So it appears I am using objcopy correctly.
Compiling with -fvisibility=hidden however due to some other constraints I need to use GCC 3.3 which doesn't appear to support that feature. I might be able to upgrade to a newer version of GCC but would like confirmation that compiling with this flag will help me before heading down that road.
Other things to note:
I do not have access to the source code of either foo or baz
I would prefer to keep all of my plug-in in one shared object (bar.so). baz is actually a licensing library so I don't want it separated
Use dlopen to load your plugin with RTLD_DEEPBIND flag.
(edit)
Please note that RTLD_DEEPBIND is Linux-specific and need glibc 2.3.4 or newer.

Is there an automated way to figure out Shared Object Dependencies?

Short:
I'm looking for something that will list all unresolved dependencies in an SO, taking into account the SOs that are in it's dependencies.
Long:
I'm converting a lot of static-compiled code to Shared Objects in Linux- is there an easy way to determine what other SOs my recently compiled SO is dependent on besides trial & error while trying to load it?
I'm sure there is a better way, but I haven't been able to find it yet.
I've found "ldd", but that only lists what the SO says it's dependent on.
I've also used "nm" to figure out once an SO fails to load to verify what other SO contains it.
I don't have code for you, but I can give pointers:
It's just a graph problem. You should use objdump -T to dump the dynamic symbol table for a given binary or shared object. You'll see many lines of output, and the flags can be a little confusing, but the important part if that symbols will either be *UND* or they'll have a segment name (.text etc).
Any time you see *UND*, that means that it's an undefined symbol which has to be resolved. Defined symbols are the targets of resolution.
With that, and a little Python, you should be able to find what you need.
"ldd -r foo.so" should print the set of symbols which foo.so needs but which aren't provided by its direct dependencies.
Alternatively, link foo.so like this:
gcc -shared -o foo.so foo.o bar.o -ldep1 -ldep2 -Wl,--no-undefined
This should fail (to link) if foo.o or bar.o uses something not provided by libdep1 or libdep2 or libc.

Receive "undefined symbol" error when loading library with dlopen

I'm writing some code that uses dynamic shared libraries as plugins.
My command line for building the shared libraries looks like:
cc -shared -fPIC -o module.so -g -Wall module.c
Within the module, I can call functions that are in any other shared library that has been loaded within the main executable.
However I cannot access (exported) functions that are in the executable itself (I get undefined symbol errors).
My call to dlopen looks like this:
void *handle = dlopen(plugin, RTLD_NOW);
Can anyone please advise how my module can call back to my executable, without having to put all of the executable's utility functions into yet another shared library?
Correct solution is to add -rdynamic to the link command of the main executable. This will add appropriate option to ld (which, when using GNU ld, happens to be --export-dynamic).
Adding --export-dynamic directly is technically incorrect: it's a linker option, and so should be added as -Wl,--export-dynamic, or -Wl,-E. This is also less portable than -rdynamic (other linkers have an equivalent, but the option itself is different).
I've found the answer myself.
I had to add the --export-dynamic flags to the link options for the main executable.
When creating a dynamically linked
executable, add all symbols to the
dynamic symbol table. The dynamic
symbol table is the set of symbols
which are visible from dynamic objects
at run time.
If you do not use this option, the
dynamic symbol table will normally
contain only those symbols which are
referenced by some dynamic object
mentioned in the link.
If you use "dlopen" to load a dynamic
object which needs to refer back to
the symbols defined by the program,
rather than some other dynamic object,
then you will probably need to use
this option when linking the program
itself.
When I encountered the same problem, I just used the following solution. Before loading any plugin, just load the program itself, bringing its symbols to dynamic tables:
dlopen(NULL,RTLD_NOW|RTLD_GLOBAL);
I think the solution is better. The reason is that, it also solves the same problem if you
a) your program (or a trird-party module) is linked (not in runtime) against the shared library, which symbols need to be in dynamic table;
b) can not recompile that module with -rdynamic flag.

Resources