I have a problem where I need to know the filesystem path of the current binary, as well as those of any loading (as opposed to loaded) binaries. Here is an example (for Windows): Say we have an executable A.exe, which dynamically binds to B.dll, which in turn binds to C.dll. How could code executing in C.dll get the file paths of C.dll, B.dll, and A.exe?
Oh, and I need to be able to do it on Linux, Mac, and Windows.
On Linux, the closest thing I've found is dl_iterate_phdr, but the who-loaded-who info is missing.
On Windows, The Dynamic-Link functions don't have quite the right functionality.
On Mac, all I can find is what's in dlfcn.h, which is rather pithy for this purpose.
Thanks.
Related
There is a ncurses6 originally installed in a user home dir, let's say "/home/test", so a test environment was built over this ncurses path, a lot of (in development) apps were compiled and is working now, depending only of the current HOME env variable.
But, because of a purpose beyond our control, we have to change the user home dir. And now it's anything different from "/home/test".
The external apps and ncurses tools still working, we need just point the libraries with LD_LIBRARY_PATH and use a more specific path like we used before for ncurses tools:
LD_LIBRARY_PATH=~/bin/ncurses-6.0/lib ~/bin/ncurses-6.0/bin/tic
But now, after changing the user home dir, we need to point also the terminfo database:
TERMINFO=~/bin/ncurses-6.0/share/terminfo LD_LIBRARY_PATH=~/bin/ncurses-6.0/lib ~/bin/ncurses-6.0/bin/tic
But, is there any way to make the TERMINFO database path permanent without recompiling and reinstalling the ncurses ? Is it hard code in ncurses during compilation ?
The default values are compiled-in. You can override those with environment variables (TERMINFO is standard, TERMINFO_DIRS is an extension). That's not new with ncurses6 (it predates ncurses4, twenty years ago).
The most practical "permanent" change would be to put the overrides in your shell initialization.
It's possible to modify an ELF binary (there's no checksums), but the resulting path couldn't be longer. It could be shorter, since the strings are null-terminated. Since your example adds to the path, that wouldn't work for you, anyway.
I have a need to debug into some calls in system libraries, to understand how the calls differ, and why one or another would be failing.
It is now common for Linux distros to provide stripped system libraries and separate debug symbol files. For example, /lib/libc-2.8.so is stripped of symbols, leaving behind a section named .gnu_debuglink that contains info to find a separate debug file. The separate debug files are installable through a debug package, and contain symbolic info needed by gdb. It's well described here http://www.technovelty.org/code/debug-info-symbols.html and http://sourceware.org/gdb/onlinedocs/gdb/Separate-Debug-Files.html
After installing the debug package and the sources, I was expecting that GDB would find the symbols and sources and I would be able to view listings and step into the calls. Instead, gdb tells me "no line number known for xyz"
I've verified that debug-file-location is correct, and directories is set to the source directories.
Is it even possible to do what I want? Am I going about this the wrong way? Is there a simpler way?
Did you try to set the debug-file-directory parameter in GDB? As per the documentation you pointed out, it should do what you want:
set debug-file-directory directories
Set the directories which gdb searches for separate debugging
information files to directory. Multiple directory components can be
set concatenating them by a directory separator.
show debug-file-directory
Show the directories gdb searches for separate debugging
information files.
For instance in my Fedora distribution, the directory is /usr/lib/debug.
You can also define it at compile time with
configure --with-separate-debug-dir=/usr/lib/debug ...
I'm working on a Firefox plugin that uses external libraries to render 3D graphics on the browser.
The problem is that I want the plugin to use external libraries packed with it without changing the LD_LIBRARY_PATH variable.
The libraries are installed in a position relative to the plugin (a shared library too), while the actual executable (i.e. the browser) can be located somewhere entirely else.
I'm testing it on Ubuntu (no problem at Windows version of the plugin)
My dependencies are OpenSceneGraph libraries and static compilation will make the plugin really big (not an option if there is another one).
Use the rpath option when linking and specify the 'special' path $ORIGIN.
Example:
-Wl,-R,'$ORIGIN/../lib'
Here's a site that elaborates on using $ORIGIN:
http://www.itee.uq.edu.au/~daniel/using_origin/
You could maybe use the -L flag during the compilation to specify the relative path where the linker can find your shared objects.
If you have already generated your lib, you can link by directly invoking the ldcommand.
Tips : You can easily check if some symbols are defined in a lib using the unix command nm. This is a useful way to check that the linking is well-done.
(If I were you, I would just change temporaly the LD_LIBRARY_PATH as you said in your post. Why don't you want to do this ?)
It's wrong to use relative rpath for security reason,
You should use libdl functions (dlopen, etc)
I love cygwin and the native windows version of gvim and I use them together all the time. The only problem I have is with cygwin path names. Gvim for windows doesn't understand them so I have to resort to typing things like:
gvim `cygpath -wa ~/scripts/myscript.pl`
Which is annoying!
I was wondering if there's a neat way of using autocmds to detect if a cygwin path has been provided and, if so, convert it to a windows path on the FileReadPre event. Does anyone know if/how this can be acomplished?
There exist several solutions (see vim.wikia.com, cygwin category).
I'm maintaining the more flexible one: cyg-wrapper.sh (flexible in the sense it knows that (vim) flags are not pathnames, and it can even be told that "binary" flags like -c expect another argument that is not a pathname, and in the sense that it is not vim specific)
Regarding the invocation of cygwin executables from win32-vim, you won't have any troubles ... as long as the executable won't return pathnames expressed in *nix format.
For all compilation related executables (gcc/make/doxygen/...) I also have a solution. In the past it was a simple standalone perl script (still available on vim.org). Now I have a full solution that does other compilation related stuff: BuildToolsWrapper (that requires lh-vim-lib on the same site)
Regarding things like :e /etc/hosts, I have no solutions. A long time ago, I've tried to play with FileReadPre & co, but I gave up along the way, and I don't remember why ^^'.
You can point a single symbol file to gdb with command the:
symbol-file /usr/lib/debug/symbolfile.so
But how to tell gdb to load all symbol-files from given path including subdirectories?
On a Linux system, you should never have to use symbol-file GDB command in the first place.
The trick is to prepare your binaries in such a way that GDB will find the symbol file automatically. This is surprisingly easy to do. Detailed instructions are here.
Use following command:
set solib-search-path path
The solution is to add-symbol-file. For instance, if symbol file is called lib.out:
add-symbol-file lib.out 0
This is particularly useful on embedded system where application developers use a library stored in ROM. The debugger needs the symbol file to reconstruct the stack if execution stops in the middle of a library function call.
This works even if the library was generated on a separate system to which the developers have no access.