Relocations - careful with that debugging flag
By User12613883-Oracle on Aug 30, 2004
I received an application from a customer the other day. It's quite a big sucker, consisting of the application and over 70 shared objects (that's besides the system objects that also get used).
% size -x main \*.so main: 2df35c + 2675a4 + 80918f8 = 0x85d81f8 libxxx.so: 64d4d9c + 9af9f6 + 19604ba = 0x87e4c4c libyyy.so: 4db7aeb + 76aa4c + 32cc16c = 0x87ee6a3 libzzz.so: 3f347ce + d8ebb1 + 4642a3b = 0x9305dba ....
The customer has complained that it takes a long time to load this
application. In particular, it takes a long time to verify their
The set of shared objects supplied by the customer do not specify any
of their dependencies. In fact, the application seems responsible
for establishing all dependencies, not only those that the application
references, but also those needed to satisfy all dependencies. If
each shared object defined their dependencies, then
A quick poke around with
Looking a little deeper I found that around 2.3 million relocations are RELATIVE relocations. These are relocations that simply need the base offset of the object to be added to the relocation offset. This is a simple operation, involving no symbol lookup, and is only accounting for a few percent of the cost.
The rest of the startup cost stems from the symbolic relocations, of
which there are some 740,000 that needed processing with
I don't have the source for this set of objects to experiment with not using -g. But I'm left concluding that the bulk of the startup cost of this process is due to these $X.... symbols.
If you don't want fix-and-continue, be careful how you use the compiler flags. This overhead in relocation processing probably isn't what you want in production software.
Note, you can also build objects with the -zcombreloc