Relocations - careful with that debugging flag
Rod Evans Monday August 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
I thought an ild() expert might have answered this, guess none of them read my blog.
I don't know all that much about ild(), as it's delivered by the compiler folks. ld(1) comes with the OS. I know it leaves large holes in the object being created, which allow new .o's to be stitched in later. I'm not sure that the symbol table is polluted with promoted local symbols to accomplish this. I think there's a host of other metadata maintained to support the process.
But, ild() might not be around much longer. From the Studio 9 Release notes:
The Incremental Link Editor (ILD) is a special-purpose linker that can, in limited situations, perform program linkage faster than the general-purpose system linker ld. This feature might be removed in a future release. When ILD is no longer available, ld will be used instead.
| Dynamic Object Versioning|| Tracing a link-edit|