Chris's Wiki :: blog/programming/COptimizerMakingProgramsCompile Commentshttps://utcc.utoronto.ca/~cks/space/blog/programming/COptimizerMakingProgramsCompile?atomcommentsDWiki2016-07-14T11:31:54ZRecent comments in Chris's Wiki :: blog/programming/COptimizerMakingProgramsCompile.By skeeto on /blog/programming/COptimizerMakingProgramsCompiletag:CSpace:blog/programming/COptimizerMakingProgramsCompile:c951e80b73aa691c394701409c284825533f7c5cskeetohttp://nullprogram.com/<div class="wikitext"><p>I've run into a more sinister situation along these lines. My program was dynamically linking against a library libfoo and at runtime was using dlopen(3) to load a library libbar, which itself also linked against libfoo. Throughout the run of the program, it would occasionally dlclose libbar and then dlopen a newly compiled version.</p>
<p>However, with some versions of gcc and compiled with optimization, the program would crash in libfoo due to its internal state being corrupted. It took me awhile to figure it out: the optimizer, both in the compiler and linker, saw that the main program didn't actually make any calls into libfoo from reachable code and so didn't link libfoo at all. Every time the main program used dlclose on libbar, it was also unloading libfoo, and when libbar came up it wasn't reinitializing libfoo, assuming it would keep its global state.</p>
<p>Another note: You'll frequently get additional warnings compiling with optimization since the compiler is doing a more thorough analysis. I think that makes it worth compiling with optimization during development, only turning it off to examine the program from a debugger.</p>
</div>2016-07-14T11:31:54ZBy Aristotle Pagaltzis on /blog/programming/COptimizerMakingProgramsCompiletag:CSpace:blog/programming/COptimizerMakingProgramsCompile:f1b442fd80ae87c0a7f13bcf281c5d75f421d61fAristotle Pagaltzishttp://plasmasturm.org/<div class="wikitext"><p>Well, to be pedantic, the program compiles either way. It’s the linker that errors out when given the unoptimised object.</p>
<p>This matters, because it means that the problem is in the abstraction of separating the compiler and the linker from each other. Given how the compiler’s and the linker’s jobs are defined, what happens here is totally kosher… even though undesirable. And so I cannot think of any way to fix it without piercing this encapsulation.</p>
<p>I guess the simplest way to fit this into the model would be for the compiler to output no-op linker symbols that need to be satisfied but not linked – i.e. by leaking responsibility from the compiler to the linker.</p>
</div>2016-07-14T08:36:33Z