dbx
and Solaris' link-edit tracing facility.Let us start with the obligatory example first.
% cat dummy.c
#include <stdio.h>
void compare (int x, int y)
{
printf("\ndummy.c: compare(int, int)");
}
void Comparable (int a, int b)
{
printf("\nNext line should print \"dummy.c: compare(int, int)\". It you see something
else, it must be a symbol collision.");
compare (a, b);
}
% cc -G -o libdummy.so dummy.c
% cat thirdparty.c
#include <stdio.h>
int compare (char x, char y)
{
printf("\nthirdparty.c: compare(char, char)");
return (0);
}
% cc -G -o lib3rdparty.so thirdparty.c
% export LD_LIBRARY_PATH=.:$LD_LIBRARY_PATH
% cat test.c
void Comparable(int, int);
int main()
{
Comparable(1, 2);
return (0);
}
% cc -o test -l3rdparty -ldummy test.c
% ./test
Next line should print "dummy.c: compare(int, int)". It you see something else, it must be a symbol collision.
thirdparty.c: compare(char, char)
1) Using
dbx
to detect symbol collision% dbx test
For information about new features see `help changes'
To remove this message, put `dbxenv suppress_startup_message 7.5' in your .dbxrc
Reading test
Reading ld.so.1
Reading lib3rdparty.so
Reading libdummy.so
Reading libc.so.1
(dbx) stop in compare
More than one identifier 'compare'.
Select one of the following:
0) Cancel
1) `lib3rdparty.so`compare
2) `libdummy.so`compare
a) All
> a
dbx: warning: 'compare' has no debugger info -- will trigger on first instruction
dbx: warning: 'compare' has no debugger info -- will trigger on first instruction
Will create handlers for all 2 hits
(2) stop in compare
(3) stop in compare
(dbx) run
Running: test
(process id 4404)
Next line should print "dummy.c: compare(int, int)". It you see something else, it must be a symbol collision.stopped in compare at 0xd27a0240
0xd27a0240: compare : pushl %ebp
(dbx) where
=>[1] compare(0x1, 0x2), at 0xd27a0240
[2] Comparable(0x1, 0x2), at 0xd27702d9
[3] main(0x1, 0x8047324, 0x804732c), at 0x80506f8
proc -map
shows the list of objects loaded with addresses.(dbx) proc -map
Loadobject mappings for Process ID: 4404
0x08050000 /export/home/techno/C/test
0xd27a0000 /export/home/techno/C/lib3rdparty.so
0xd2770000 /export/home/techno/C/libdummy.so
0xd2690000 /lib/libc.so.1
0xd27c8000 /lib/ld.so.1 [LM_ID_LDSO]
From the above mappings, it appears that the symbol
compare
was bound to the definition in lib3rdparty.so
. However it should really be bound to the definition in libdummy.so
. Other way to check the mappings is by getting the process id with
proc -pid
command, and using pmap <pid>
command in dbx
environment.(dbx) proc -pid
4404
(dbx) pmap 4404
4404: /export/home/techno/C/test
08046000 8K rwx-- [ stack ]
08050000 4K r-x-- /export/home/techno/C/test
08060000 4K rwx-- /export/home/techno/C/test
D261E000 384K rw--- [ anon ]
D2680000 24K rwx-- [ anon ]
D2690000 764K r-x-- /lib/libc.so.1
D275F000 24K rw--- /lib/libc.so.1
D2765000 8K rw--- /lib/libc.so.1
D2770000 4K r-x-- /export/home/techno/C/libdummy.so
D2780000 4K rwx-- /export/home/techno/C/libdummy.so
D2790000 4K rwx-- [ anon ]
D27A0000 4K r-x-- /export/home/techno/C/lib3rdparty.so
D27B0000 4K rwx-- /export/home/techno/C/lib3rdparty.so
D27BA000 4K rwxs- [ anon ]
D27C8000 140K r-x-- /lib/ld.so.1
D27FB000 4K rwx-- /lib/ld.so.1
D27FC000 8K rwx-- /lib/ld.so.1
total 1396K
The following outputs in
dbx
env. confirm that the symbol compare
was actually resolved in lib3rdparty.so
rather than libdummy.so
.(dbx) which compare
`lib3rdparty.so`compare
which
command prints the full qualification of a given name.(dbx) scopesThe
Function compare
File "(unknown OF)"
Loadobject /export/home/techno/C/lib3rdparty.so
scopes
command prints a list of active scopes.(dbx) statusThe
*(2) stop in compare
(3) stop in compare
status
prints the stop breakpoints in effect. In the above output we do not know which compare belong to which library. -s
option of status
will show the information we need.(dbx) status -s
stop in `lib3rdparty.so`#compare
stop in `libdummy.so`#compare
2) Using Solaris' link-edit tracing to detect symbol collision
Setting the run-time linker (
ld.so.1
) env variable LD_DEBUG
to the token bindings
causes the run-time linker to show the binding of a symbol reference to a symbol definition. Usually the output from run-time linker will be overwhelming if the application is big with a handful of symbols. By default, all this output will be displayed on stdout; so, it might be a little inconvenient to read all the output on stdout. However the tracing data from run-time linker can be redirected to a file using LD_DEBUG_OUTPUT
env variable as shown below.eg.,
% export LD_DEBUG=bindingsObserve that the call to symbol (function or method)
% export LD_DEBUG_OUTPUT=/tmp/bindings.log
% ./test
Next line should print "dummy.c: compare(int, int)". It you see something else, it must be a symbol collision.
thirdparty.c: compare(char, char)
% grep compare /tmp/bindings.log.0443*
/tmp/bindings.log.04436:04436: binding file=./libdummy.so to file=./lib3rdparty.so: symbol `compare'
compare
in libdummy.so
was resolved in lib3rdparty.so
. It confirms the symbol conflict. This problem arises when the symbols are left in default global scope. Use elfdump
tool to check the scope and attribute of the symbol of interest (compare
in this example).% /usr/ccs/bin/elfdump -sN.symtab libdummy.so | grep compare
[40] 0x00000280 0x00000027 FUNC GLOB D 0 .text compare
% /usr/ccs/bin/elfdump -sN.symtab lib3rdparty.so | grep compare
[41] 0x00000240 0x00000036 FUNC GLOB D 0 .text compare
Symbols with global default scope are always vulnerable to symbol conflicts, as seen in the above example. The primary reason being any one can interpose upon these global default symbols. To prevent others from interposing on the symbols that are completely useless outside the defining component (executables or shared objects), make them protected with Sun Studio's
-xldscope=symbolic
compiler option or __symbolic
attribute. Note that these language extensions were introduced in Sun Studio 8. Refer to Reducing Symbol Scope with Sun Studio C/C++ article for detailed information about global, symbolic scopes and also about the linker scoping language extension. If you are using any older compiler, use -Bsymbolic
linker option to build your executables and shared libraries there by making the symbols protected.eg.,
% cc -G -o libdummy.so -xldscope=symbolic dummy.c
% /usr/ccs/bin/elfdump -sN.symtab libdummy.so | grep compare
[40] 0x00000280 0x00000027 FUNC GLOB P 0 .text compare
% cc -G -o lib3rdparty.so -xldscope=symbolic thirdparty.c
% /usr/ccs/bin/elfdump -sN.symtab lib3rdparty.so | grep compare
[41] 0x00000240 0x00000036 FUNC GLOB P 0 .text compare
% cc -o test -l3rdparty -ldummy test.c
% ./test
Next line should print "dummy.c: compare(int, int)". It you see something else, it must be a symbol collision.
dummy.c: compare(int, int)
Note that the compiler option
-xldscope=symbolic
and the linker option -Bsymbolic
make all the symbols protected - so, it is not possible for others to interpose upon the symbols of such libraries or executables. For some reason if you have to leave some symbols in global default scope, use __symbolic
specifier for those symbols which must be protected from interposers.eg.,
% cat dummy.c
#include <stdio.h>
__symbolic void compare (int x, int y)
{
printf("\ndummy.c: compare(int, int)");
}
void Comparable (int a, int b)
{
printf("\nNext line should print \"dummy.c: compare(int, int)\". It you see something
else, it must be a symbol collision.");
compare (a, b);
}
% cc -G -o libdummy_.so dummy.c
% /usr/ccs/bin/elfdump -sN.symtab libdummy_.so | grep -i compar
[40] 0x00000280 0x00000027 FUNC GLOB P 0 .text compare
[45] 0x000002b0 0x00000037 FUNC GLOB D 0 .text Comparable
Observe that the symbol
compare
is protected (although global in scope); and hence cannot be overridden by another global symbol with name compare
. However Comparable
can still be overridden by a different implementation, due to its global default scope.Just to make sure that the symbol was bound to the definition in the right library, you can check the mappings, scope etc., again with
dbx
. Link-edit tracing won't show any binding information when it gets resolved within the same library._______________
Technorati tags: Sun Studio | Solaris | linker | Programming
No comments:
Post a Comment