Cross-Linkage in interactive_ui_tests for Component Builds |
||
Issue descriptionFor component builds, interactive_ui_tests seems to statically link in base. 1:010> x base!base::MessageLoop::`* 0c6917a4 base!base::MessageLoop::`vftable' = <function> *[4] 0c69178c base!base::MessageLoop::`vftable' = <function> *[5] 0c3e9ee0 base!base::MessageLoop::`scalar deleting destructor' (void) 0c3a1360 base!base::MessageLoop::`default constructor closure' (void) 0c3e9d80 base!base::MessageLoop::`vector deleting destructor' (void) 0c3e9e08 base!base::MessageLoop::`vector deleting destructor' (<no parameter info>) 1:010> x interactive_ui_tests!base::MessageLoop::`* 02b66510 interactive_ui_tests!base::MessageLoop::`scalar deleting destructor' (void) 07d3a5e8 interactive_ui_tests!base::MessageLoop::`local vftable' = <no type information> 02b661f9 interactive_ui_tests!base::MessageLoop::`vector deleting destructor' (<no parameter info>) 07d3a5d0 interactive_ui_tests!base::MessageLoop::`local vftable' = <no type information> This is all fine and well, but it also means if something in base changes, the build system needs to link both base.dll as well as interactive_ui_tests.exe. Ideally, interactive_ui_tests types just reference base. Fortunately, the implementation code does get imported from base.dll. 1:010> dps 07d3a5e8 l5 07d3a5e8 008281dd interactive_ui_tests!ILT+4354520(??_EMessageLoopbaseW3AEPAXIZ) 07d3a5ec 02c7cf82 interactive_ui_tests!base::MessageLoop::Run 07d3a5f0 02c7cf7c interactive_ui_tests!base::MessageLoop::Quit 07d3a5f4 02c7cf70 interactive_ui_tests!base::MessageLoop::EnsureWorkScheduled 07d3a5f8 00000000 1:010> u 02c7cf82 l1 interactive_ui_tests!base::MessageLoop::Run: 02c7cf82 ff25dc92af08 jmp dword ptr [interactive_ui_tests!_imp_?RunMessageLoopbaseEAEX_NZ (08af92dc)] 1:010> dps 08af92dc l1 08af92dc 0c2c58da base!ILT+18645(?RunMessageLoopbaseEAEX_NZ) 1:010> u 0c2c58da l1 base!ILT+18645(?RunMessageLoopbaseEAEX_NZ): 0c2c58da e9c16f1200 jmp base!base::MessageLoop::Run (0c3ec8a0)
,
Feb 1 2018
I'm confused by this bug. I assume that this is in component builds. In component builds I don't think it is *possible* to statically link base. That said this may be a real issue, I just think it is slightly mischaracterized. I think you are seeing an artifact of how exported classes are handled on Windows. If a translation unit creates an object then, IIRC, it also creates a v-table for that object. Or maybe this only happens if it instantiates a constructor. Basically, the compiler needs some way of knowing when to generate a v-table (so that it doesn't generate one in every translation units that includes the header file) and it looks like we are not making ideal use of this heuristic. For the question of whether interactive_ui_tests.exe needs to be rebuilt when base.dll is rebuilt the answer is complex and fluid. Basically, if doing incremental linking (the default with component builds) then most changes to base.dll will not modify base.lib (if using link.exe rather than use_lld=true) and therefore interactive_ui_tests.exe will not relink. Exceptions would include changes to base that force modifications of the base.lib import library, and changes to header files in base that force recompilation. Technically this not-writing-base.lib optimization is incorrect as it means that a change to, for instance, how base.dll does printing could fail to have an effect on code-generation when it technically could. However the tradeoff is far faster builds in most cases. So... Are you actually seeing interactive_ui_tests.exe rebuild after a modification to base.dll? If so then: a) what gn args are you using? b) what change to base.dll are you making? As a separate issue, if we can avoid replicating the v-tables in binaries that depend on base.dll then that would be a binary-size/link-time benefit.
,
Jan 11
Available, but no owner or component? Please find a component, as no one will ever find this without one. |
||
►
Sign in to add a comment |
||
Comment 1 by robliao@chromium.org
, Jan 23 2018