Sun Studio: symbol collisions revisited

Even though my blog entry C/C++: global const variables, symbol collisions & symbolic scoping and article Reducing Symbol Scope with Sun Studio C/C++ discuss about techniques to avoid symbol collisions in great length with examples, apparently they failed to provide a simple way to detect if the anomalous behavior is due to a symbol conflict. This blog entry tries to fill that gap with the help of Sun Studio debugger 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) scopes
 Function   compare
 File       "(unknown OF)"
 Loadobject /export/home/techno/C/lib3rdparty.so

The scopes command prints a list of active scopes.

 (dbx) status
 *(2) stop in compare
  (3) stop in compare

The 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=bindings
 % 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'

Observe that the call to symbol (function or method) 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