Is is possible to list all the library functions available in any library/headers in GCC command line?
Anything similar to program like JAVAP which is available for Java?
Thanks.
You can use objdump to list symbols in a shared libraries (or executables):
$objdump -T /usr/lib/libclang.so
<...snipped...>
0000000000124150 g DF .text 00000000000000c1 Base clang_reparseTranslationUnit
000000000010fe40 g DF .text 0000000000000021 Base clang_getNullRange
0000000000135760 g DF .text 000000000000009f Base clang_getPointeeType
0000000000124290 g DF .text 0000000000000289 Base clang_parseTranslationUnit
000000000012b790 g DF .text 0000000000000935 Base clang_findReferencesInFile
0000000000110b80 g DF .text 000000000000001c Base clang_getRangeEnd
0000000000127d20 g DF .text 0000000000000022 Base clang_disposeCodeCompleteResults
0000000000135e10 g DF .text 0000000000000037 Base clang_isPODType
000000000010f870 g DF .text 0000000000000025 Base clang_getTranslationUnitCursor
0000000000129b50 g DF .text 00000000000002c1 Base clang_getDiagnosticOption
As you can see it lists the different symbols and their relative address.
Related
I would like to add a linker symbol in an llvm pass that I can access later in a linker script.
For example, to show what I'd like to see in the resulting object file, here is an assembly file that creates a linker symbol with a given value.
$ cat sym.s
asdf = 0x1234
.global asdf
$ clang -c sym.s && readelf --symbols sym.o
Symbol table '.symtab' contains 2 entries:
Num: Value Size Type Bind Vis Ndx Name
0: 0000000000000000 0 NOTYPE LOCAL DEFAULT UND
1: 0000000000001234 0 NOTYPE GLOBAL DEFAULT ABS asdf
I could not see how to do this in the llvm library (c++ api), as I do not see how to interact with the symbol table given a handle to a Module when my pass is called via runOnModule(Module &M).
I'm not even sure the correct way to do this from an llvm source file.
Here is my best attempt exploring in that direction
$ cat attempt.ll
target triple = "x86_64-pc-linux-gnu"
#asdf = global i8 1234, !absolute_symbol !0
!0 = !{ i64 1234, i64 1234 }
$ clang -c attempt.ll && readelf --symbols attempt.o
Symbol table '.symtab' contains 3 entries:
Num: Value Size Type Bind Vis Ndx Name
0: 0000000000000000 0 NOTYPE LOCAL DEFAULT UND
1: 0000000000000000 0 FILE LOCAL DEFAULT ABS attempt.ll
2: 0000000000000000 1 OBJECT GLOBAL DEFAULT 3 asdf
The !absolute_symbol does not actually create an absolute symbol in the object file. It instead still creates a variable (of size 1 in this case), and apparently the variable (not the symbol) has an associated value. So this way of approaching it may be a dead end.
So getting back on track:
How to I add a symbol given a handle to an llvm::Module?
I have a case where g++ refuses to load a library. I have a file deps/lib/libskgxp11.so. I place -L deps/lib and -lskgxp11 on the g++ command. I get the following error:
error while loading shared libraries: libskgxp11.so: cannot open shared object file: No such file or directory
My overall purpose is to get a test to run with gtest that connects to Oracle, executes select * from dual, and compares the result.
I have the following in Makefile:
g++ -m32 -o $(test_target) -L deps/lib -Wl,--start-group $(dep_libs) -lpthread -ldl -lskgxpr -lskgxp11 -locrb11 -locr11 -lhasgen11 -lnnz11 -lskgxn2 -locrutl11 -lclntsh $(test_objects) -Wl,--end-group
I have used the same basic sequence of -Wl,--start group, all dependent static libraries, all dependent shared libaries, all object files, -Wl,--end-group on other projects and it works just fine.
Notice the -m32, we're doing everything in 32 bits right now. All the other shared libraries load fine, and are all in the same dir:
ls deps/lib/libskgxpr.so deps/lib/libskgxp11.so deps/lib/libocrb11.so deps/lib/libocr11.so deps/lib/libhasgen11.so deps/lib/libnnz11.so deps/lib/libskgxn2.so deps/lib/libocrutl11.so deps/lib/libclntsh.so | cat
deps/lib/libclntsh.so
deps/lib/libhasgen11.so
deps/lib/libnnz11.so
deps/lib/libocr11.so
deps/lib/libocrb11.so
deps/lib/libocrutl11.so
deps/lib/libskgxn2.so
deps/lib/libskgxp11.so
deps/lib/libskgxpr.so
I do notice one strange thing, it seems that the following group of libraries are somehow related:
deps/lib/libskgxp11.so
deps/lib/libskgxpcompat.so
deps/lib/libskgxpd.so
deps/lib/libskgxpg.so
deps/lib/libskgxpr.so
They each seem to define the same functions. The other 4 seem to depend on libskgxp11, in the sense that if I link any of the other 4 by themselves with a -l option, g++ complains that it can't load libskgxp11.
I have a command sequence that can tell me for each remaining function I need to get from some shared lib, which shared lib(s) contain it. It gives the following:
skgxpcdel
deps/lib/libskgxp11.so
deps/lib/libskgxpcompat.so
deps/lib/libskgxpd.so
deps/lib/libskgxpg.so
deps/lib/libskgxpr.so
skgxpcini_with_stats
deps/lib/libskgxp11.so
deps/lib/libskgxpcompat.so
deps/lib/libskgxpd.so
deps/lib/libskgxpg.so
deps/lib/libskgxpr.so
skgxpcon_with_stats
deps/lib/libskgxp11.so
deps/lib/libskgxpcompat.so
deps/lib/libskgxpd.so
deps/lib/libskgxpg.so
deps/lib/libskgxpr.so
...
where skgxpcdel is a func I'm looking for. All of the outstanding functions I need give the same list of the same 5 libraries.
If I run objdump -T on the 5 libraries, they all seem to be 32-bit shared libs, I don't see anything special about the one that doesn't load compared to the ones that do:
for i in deps/lib/libskgxp11.so deps/lib/libskgxpcompat.so deps/lib/libskgxpd.so deps/lib/libskgxpg.so deps/lib/libskgxpr.so; do objdump -T $i | head; done
deps/lib/libskgxp11.so: file format elf32-i386
DYNAMIC SYMBOL TABLE:
0000380c l d .init 00000000 .init
00003b90 l d .text 00000000 .text
00008cc4 l d text.unlikely 00000000 text.unlikely
000a719c l d .fini 00000000 .fini
000a71c0 l d .rodata 00000000 .rodata
000bbe80 l d .eh_frame 00000000 .eh_frame
deps/lib/libskgxpcompat.so: file format elf32-i386
DYNAMIC SYMBOL TABLE:
00000ca0 l d .init 00000000 .init
00000d18 l d .text 00000000 .text
00000e04 l d text.unlikely 00000000 text.unlikely
00001618 l d .fini 00000000 .fini
00001640 l d .rodata 00000000 .rodata
0000188c l d .eh_frame 00000000 .eh_frame
deps/lib/libskgxpd.so: file format elf32-i386
DYNAMIC SYMBOL TABLE:
00000ca0 l d .init 00000000 .init
00000d18 l d .text 00000000 .text
00000e04 l d text.unlikely 00000000 text.unlikely
00001618 l d .fini 00000000 .fini
00001640 l d .rodata 00000000 .rodata
0000188c l d .eh_frame 00000000 .eh_frame
deps/lib/libskgxpg.so: file format elf32-i386
DYNAMIC SYMBOL TABLE:
0000380c l d .init 00000000 .init
00003b90 l d .text 00000000 .text
00008cc4 l d text.unlikely 00000000 text.unlikely
000a719c l d .fini 00000000 .fini
000a71c0 l d .rodata 00000000 .rodata
000bbe80 l d .eh_frame 00000000 .eh_frame
deps/lib/libskgxpr.so: file format elf32-i386
DYNAMIC SYMBOL TABLE:
0000380c l d .init 00000000 .init
00003b90 l d .text 00000000 .text
00008cc4 l d text.unlikely 00000000 text.unlikely
000a719c l d .fini 00000000 .fini
000a71c0 l d .rodata 00000000 .rodata
000bbe80 l d .eh_frame 00000000 .eh_frame
I'm scratching my head wondering why I can't link the libskgxp11.so, and what is the relationship between this group of 5 libs.
Any help would be greatly appreciated.
For reference, here are some command sequences I ran to get the list of problem functions and track down the libs:
# Get what project needs
make run-tests 2>&1 | grep -Po '(?<=undefined reference to ).*' | tr -d "\`'" | sort -u > undefined.txt
# Complete content of undefined.txt
skgxpcdel
skgxpcini_with_stats
skgxpcon_with_stats
skgxpdis
skgxpdmpctx
skgxpdmpobj
skgxp_get_epid
skgxpgettabledef
skgxpmmap
skgxpnetmappush
skgxppost
skgxprqhi
skgxpsz
skgxptrace
skgxpunmap
skgxpveri
skgxpvrpc
skgxpwait
# Get what deps provide, for comparison to what project needs
(for i in deps/lib/*.so;do objdump -TC $i | grep -E '^...............F';done) | grep -v '[*]UND[*]' | awk '{print $NF}' | sort -u > have.txt
# First few lines of have.txt
_A_BSafeError
AddCRLBerToList
add_error_table
afidrv
AHChooseRandomConstructor2
AHSecretCBCConstructor2
AHSecretCBCPadConstructor2
AI_AES_CBC
# See what is common between what project needs and what deps provide
comm -12 have.txt undefined.txt > left.txt
# A diff of undefined.txt and left.txt indicates they are identical
# Get what deps provide, in a way searchable by a person
(for i in deps/lib/*.so;do echo "====$i"; objdump -TC $i | grep -E '^...............F';done) | grep -v '[*]UND[*]' | awk '{print $NF}' > have-files.txt
# Here's a sample of first two shared libs and some of their funcs, from have-files.txt
====deps/lib/libagfw11.so
clsagfw_get_check_type
clsagfw_exit
clsagfw_get_attrvalue
====deps/lib/libagtsh.so
naecsn
lmsapbn
kokogtv
# for each func left, try to find lib that contains it
(for i in `cat left.txt`;do echo $i; for j in deps/lib/*.so;do (objdump -TC $j | grep -E '^...............F' | grep -v '[*]UND[*]' | grep -q $i) && echo " $j"; done; done) 2>&1 | more
# Output for first two missing funcs:
skgxpcdel
deps/lib/libskgxp11.so
deps/lib/libskgxpcompat.so
deps/lib/libskgxpd.so
deps/lib/libskgxpg.so
deps/lib/libskgxpr.so
skgxpcini_with_stats
deps/lib/libskgxp11.so
deps/lib/libskgxpcompat.so
deps/lib/libskgxpd.so
deps/lib/libskgxpg.so
deps/lib/libskgxpr.so
As helpfully suggested in the comments, the problem was occurring trying to run the program. I just needed to use the env command to set LD_LIBRARY_PATH to include the deps/lib dir where all the shared libs are stored:
run-tests: $(test_target)
env "LD_LIBRARY_PATH=deps/lib:$$LD_LIBRARY_PATH" $(test_target)
Thanks.
I am trying to debug into OpenCV code but gdb fails to load the OpenCV source file.
Checking for the source file existence:
$ls -l /home/rui/DriveSo/opencv/modules/core/src/matrix.cpp
-rw-r--r-- 1 rui rui 156046 May 11 21:46 /home/rui/DriveSo/opencv/modules/core/src/matrix.cpp
After linking with OpenCV Debug mode libraries I start dbg and add this to the list of source directories:
$gdb DriveSo
GNU gdb (Debian 7.7.1+dfsg-5) 7.7.1
....
Reading symbols from DriveSo...done.
(gdb) directory /home/rui/DriveSo/opencv/modules/core/src
Source directories searched: /home/rui/DriveSo/opencv/modules/core/src:$cdir:$cwd
(gdb) break matrix.cpp:2349
No source file named matrix.cpp.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (matrix.cpp:2349) pending.
Even after starting the session gdb still does not find the source file:
(gdb) start
Temporary breakpoint 2 at 0x41d2cf: file ../../DriveSo.dkt/main.cpp, line 11.
Starting program: /home/rui/DriveSo/repositories/trunk/builds/build-DriveSo-Desktop_Qt_5_5_0_GCC_64bit-Debug/DriveSo
....
Temporary breakpoint 2, main (argc=1, argv=0x7fffffffe5a8) at ../../DriveSo.dkt/main.cpp:11
11 QCoreApplication::setApplicationName(QString("DriveSo"));
(gdb)
What can be causing this (to me) unexpected behavior?
Following up on the suggestion by iksajotien, as far as I see the executable has debug information...
$ objdump --syms DriveSo | grep debug
0000000000000000 l d .debug_aranges 0000000000000000 .debug_aranges
0000000000000000 l d .debug_info 0000000000000000 .debug_info
0000000000000000 l d .debug_abbrev 0000000000000000 .debug_abbrev
0000000000000000 l d .debug_line 0000000000000000 .debug_line
0000000000000000 l d .debug_str 0000000000000000 .debug_str
0000000000000000 l d .debug_ranges 0000000000000000 .debug_ranges
...and the shared libraries opened by it...
$ lsof -p 12159
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
...
DriveSo 12159 rui mem REG 8,6 20289800 26740265 /usr/local/lib/libopencv_core.so.3.1.0
...
... also have debug information.
$ objdump --syms /usr/local/lib/libopencv_core.so.3.1.0 | grep debug
0000000000000000 l d .debug_aranges 0000000000000000 .debug_aranges
0000000000000000 l d .debug_info 0000000000000000 .debug_info
0000000000000000 l d .debug_abbrev 0000000000000000 .debug_abbrev
0000000000000000 l d .debug_line 0000000000000000 .debug_line
0000000000000000 l d .debug_str 0000000000000000 .debug_str
0000000000000000 l d .debug_ranges 0000000000000000 .debug_ranges
gdb info shared:
$gdb DriveSo
GNU gdb (Debian 7.7.1+dfsg-5) 7.7.1
...
Reading symbols from DriveSo...done.
(gdb) run
Starting program: /home/rui/DriveSo/repositories/trunk/builds/build-DriveSo-Desktop_Qt_5_5_0_GCC_64bit-Debug/DriveSo
...
^C
Program received signal SIGINT, Interrupt.
...
(gdb) info shared
From To Syms Read Shared Object Library
0x00007ffff7ddcae0 0x00007ffff7df5130 Yes /lib64/ld-linux-x86-64.so.2
No linux-vdso.so.1
0x00007ffff7158860 0x00007ffff794a910 Yes /usr/local/lib/libopencv_core.so.3.1
0x00007ffff6e5d880 0x00007ffff6e63a0b Yes /usr/local/lib/libopencv_highgui.so.3.1
0x00007ffff5493840 0x00007ffff690ce00 Yes /usr/local/lib/libopencv_imgproc.so.3.1
0x00007ffff50aa6f0 0x00007ffff5158bd1 Yes /usr/local/lib/libopencv_features2d.so.3.1
0x00007ffff4db8640 0x00007ffff4e3de75 Yes /usr/local/lib/libopencv_imgcodecs.so.3.1
0x00007ffff4b72a80 0x00007ffff4b931b0 Yes /usr/local/lib/libopencv_videoio.so.3.1
0x00007ffff47b7d40 0x00007ffff4920f80 Yes /usr/local/lib/libopencv_calib3d.so.3.1
...
---Type <return> to continue, or q <return> to quit---
Looking at gdb source code solib.c has the following at line 1053:
if (! ui_out_is_mi_like_p (interp_ui_out (top_level_interpreter ()))
&& so->symbols_loaded
&& !objfile_has_symbols (so->objfile))
{
so_missing_debug_info = 1;
ui_out_field_string (uiout, "syms-read", "Yes (*)");
}
else
ui_out_field_string (uiout, "syms-read",
so->symbols_loaded ? "Yes" : "No");
I therefore assume symbols are loaded and debug info exists otherwise libraries would be listed with Yes (*) or No
I faced the exact same issue and fixed it by appending an rpath to my makefile.
g++ -o $# $< -L$(LIBS) -lmylib -Wl,-rpath,$(LIBS)
I used dumpbin /symbols to see the library I created. Some functions have UNDEF notype in the output. What does that mean? Is there any link to study the structure of dumpbin output?
We can take a look at the MSDN documentation for dumpbin /SYMBOLS:
This option displays the COFF symbol table. Symbol tables exist in all
object files. A COFF symbol table appears in an image file only if it
is linked with /DEBUG.
The following is a description of the output for /SYMBOLS. Additional
information on the meaning of /SYMBOLS output can be found by looking
in winnt.h (IMAGE_SYMBOL and IMAGE_AUX_SYMBOL), or COFF documentation.
Given the following sample dump:
Dump of file main.obj
File Type: COFF OBJECT
COFF SYMBOL TABLE
000 00000000 DEBUG notype Filename | .file
main.cpp
002 000B1FDB ABS notype Static | #comp.id
003 00000000 SECT1 notype Static | .drectve
Section length 26, #relocs 0, #linenums 0, checksum 722C964F
005 00000000 SECT2 notype Static | .text
Section length 23, #relocs 1, #linenums 0, checksum 459FF65F, selection 1 (pick no duplicates)
007 00000000 SECT2 notype () External | _main
008 00000000 UNDEF notype () External | ?MyDump##YAXXZ (void __cdecl MyDump(void))
String Table Size = 0x10 bytes
Summary
26 .drectve
23 .text
The following description, for lines that begin with a symbol number,
describes columns that have information relevant to users:
The first three-digit number is the symbol index/number.
If the third column contains SECTx, the symbol is defined in that
section of the object file. But if UNDEF appears, it is not defined in
that object and must be resolved elsewhere.
The fifth column (Static, External) tells whether the symbol is
visible only within that object, or whether it is public (visible
externally). A Static symbol, _sym, wouldn't be linked to a Public
symbol _sym; these would be two different instances of functions named
_sym.
The last column in a numbered line is the symbol name, both
decorated and undecorated.
And notype() means exactly what it says on the tin: it has no type.
I have a bunch of flows and data processing applications that I occasionally need to spy on, meaning I need to know what files they read. This is mostly to aid in packaging testcases, but can also be useful when debugging.
Is there a way to run the executables in such a way that produces such a list?
I have two thoughts on this:
There is a command that I can invoke and that command invokes my apps. Something along the lines of GDB. I call GDB, give it a path to the executable and some arguments and GDB calls it for me. Perhaps there's something similar to telling me how system resources are used.
Maybe the more interesting (but unnecessary side path) solution.
create library called libc.so which implements fopen (and some others)
change LD_LIBRARY_PATH to point at the new library
make a copy of the real libc.so and rename fopen (nepof, perhaps) in an editor
my library loads the copy and calls the renamed function as necessary to provide fopen functionality.
call the app which then calls my proxy fopen.
Alternative #1 would certainly be the preferable one but comments on how to do #2 more easily are welcome too.
One option is to use strace:
strace -o logfile -eopen yourapp
This will log all file-open events, but it will impose a performance penalty that may be significant. It has the advantage of being easy to use however.
Another option is to use LD_PRELOAD. This corresponds to your option #2. The basic idea is to do something like this:
#define _GNU_SOURCE
#include <stdio.h>
#include <dlfcn.h>
int open(const char *fn, int flags) {
static int (*real_open)(const char *fn, int flags);
if (!real_open) {
real_open = dlsym(RTLD_NEXT, "open");
}
fprintf(stderr, "opened file '%s'\n", fn);
return real_open(fn, flags);
}
Then build with:
gcc -fPIC -shared -ldl -o preload-example.so preload-example.c
And run your program with eg:
$ LD_PRELOAD=$PWD/preload-example.so cat /dev/null
opened file '/dev/null'
This has much less overhead.
Note, however, that there are other entry points for opening files - eg, fopen(), openat(), or one of the many legacy compatibility entry points:
00000000000747d0 g DF .text 000000000000071c GLIBC_2.2.5 _IO_file_fopen
0000000000068850 g DF .text 000000000000000a GLIBC_2.2.5 fopen
000000000006fe60 g DF .text 00000000000000e2 GLIBC_2.4 open_wmemstream
00000000001209c0 w DF .text 00000000000000ec GLIBC_2.2.5 posix_openpt
0000000000069e50 g DF .text 00000000000003fb GLIBC_2.2.5 _IO_proc_open
00000000000dcf70 g DF .text 0000000000000021 GLIBC_2.7 __open64_2
0000000000068a10 g DF .text 00000000000000f5 GLIBC_2.2.5 fopencookie
000000000006a250 g DF .text 000000000000009b GLIBC_2.2.5 popen
00000000000d7b10 w DF .text 0000000000000080 GLIBC_2.2.5 __open64
0000000000068850 g DF .text 000000000000000a GLIBC_2.2.5 _IO_fopen
00000000000d7e70 w DF .text 0000000000000020 GLIBC_2.7 __openat64_2
00000000000e1ef0 g DF .text 000000000000005b GLIBC_2.2.5 openlog
00000000000d7b10 w DF .text 0000000000000080 GLIBC_2.2.5 open64
0000000000370c10 g DO .bss 0000000000000008 GLIBC_PRIVATE _dl_open_hook
0000000000031680 g DF .text 0000000000000240 GLIBC_2.2.5 catopen
000000000006a250 g DF .text 000000000000009b GLIBC_2.2.5 _IO_popen
0000000000071af0 g DF .text 000000000000026a GLIBC_2.2.5 freopen64
00000000000723a0 g DF .text 0000000000000183 GLIBC_2.2.5 fmemopen
00000000000a44f0 w DF .text 0000000000000088 GLIBC_2.4 fdopendir
00000000000d7e70 g DF .text 0000000000000020 GLIBC_2.7 __openat_2
00000000000a3d00 w DF .text 0000000000000095 GLIBC_2.2.5 opendir
00000000000dcf40 g DF .text 0000000000000021 GLIBC_2.7 __open_2
00000000000d7b10 w DF .text 0000000000000080 GLIBC_2.2.5 __open
0000000000074370 g DF .text 00000000000000d7 GLIBC_2.2.5 _IO_file_open
0000000000070b40 g DF .text 00000000000000d2 GLIBC_2.2.5 open_memstream
0000000000070450 g DF .text 0000000000000272 GLIBC_2.2.5 freopen
00000000000318c0 g DF .text 00000000000008c4 GLIBC_PRIVATE __open_catalog
00000000000d7b10 w DF .text 0000000000000080 GLIBC_2.2.5 open
0000000000067e80 g DF .text 0000000000000332 GLIBC_2.2.5 fdopen
000000000001e9b0 g DF .text 00000000000003f5 GLIBC_2.2.5 iconv_open
00000000000daca0 g DF .text 000000000000067b GLIBC_2.2.5 fts_open
00000000000d7d60 w DF .text 0000000000000109 GLIBC_2.4 openat
0000000000068850 w DF .text 000000000000000a GLIBC_2.2.5 fopen64
00000000000d7d60 w DF .text 0000000000000109 GLIBC_2.4 openat64
00000000000d6490 g DF .text 00000000000000b6 GLIBC_2.2.5 posix_spawn_file_actions_addopen
0000000000121b80 g DF .text 000000000000008a GLIBC_PRIVATE __libc_dlopen_mode
0000000000067e80 g DF .text 0000000000000332 GLIBC_2.2.5 _IO_fdopen
You may need to hook all of these for completeness - at the very least, the ones not prefixed with _ should be hooked. In particular, be sure to hook fopen seperately, as the libc-internal call from fopen() to open() is not hooked by a LD_PRELOAD library.
A similar caveat applies to strace - there is the 'openat' syscall as well, and depending on your architecture there may be other legacy syscalls as well. But not as many as with LD_PRELOAD hooks, so if you don't mind the performance hit, it may be an easier option.
man strace
example (assume 2343 is the process id):
# logging part
strace -p 2343 -ff -o strace_log.txt
# displaying part
grep ^open strace_log.txt
What I use is something like:
strace -o file.txt ./command
You can then
cat file.txt | grep open
to get a list of all the files that the program opened.