Starting a new thread, based on the discussion from [PATCH/Merge Request] Vtable Verification feature
I would like to start a new thread to discuss some of the issues here (see snip from old thread below). On Thu, Aug 8, 2013 at 4:01 PM, Joseph S. Myers <jos...@codesourcery.com> wrote: > On Thu, 8 Aug 2013, Caroline Tice wrote: > >> Actually if you ever want to use the feature with your compiler you >> should build your compiler with --enable-vtable-verify. This will, as >> you noted, insert calls in libstdc++ to build the verification data >> structures and to verify the virtual calls in libstdc++ itself. >> However libstdc++ itself contains 'stub' (do-nothing) versions of the >> functions that build the data structures and perform the verification. >> So if you want to turn on verification with libstdc++, you link it >> with libvtv (which contains the "real" versions of those functions) >> and if you don't want verification with libstdc++ you just don't link >> in libvtv. There is no need to multiple versions of libstdc++. > > But presumably libstdc++ with the extra calls is less efficient than > libstdc++ without them, even if the calls are just to stub functions? > > A GNU/Linux distributor would likely want to enable their users to use > this functionality, meaning distributing a GCC build with libvtv included > and a version of libstdc++ with the calls present for users who wish to > build programs (linking with libstdc++ and libvtv) for which the calls in > libstdc++ are checked. But they might not want to have even the stub > calls executed for all installed C++ programs. So it would seem natural > to provide both copies of libstdc++ - and desirable for this to be > possible without needing separate GCC builds. > >> I supposed the libgcc files could be built all the time (on systems >> that support libvtv). Would there be any down side to this? > > In my model, it's appropriate to build those independent of the libstdc++ > configure option - and likewise to build everything in libvtv independent > of the configure option. There should be no need for the configure option > to affect anything other than, at most, libstdc++ - that is, the handling > of the option in other configure scripts should be removed, with the case > where the relevant support is built being enabled by default. > > -- > Joseph S. Myers > jos...@codesourcery.com Currently the there are two relevant flags, --enable-libvtv (--disable-libvtv) and --enable-vtable-verify (--disable-vtable-verify). --enable-libvtv is the default. This will cause libvtv.so to be built, as long as the underlying system is one that supports VTV (currently only linux systems). --enable-vtable-verify controls whether or not the vtv_* files get built, in libgcc, and also whether or not libstdc++ is built with calls to the vtv functions embedded or not. We can remove references to --enable-vtable-verify from libvtv, but it still needs to be there (or something similiar) in libgcc, because the vtv_* files in libgcc contain system-specific references (section names) that are not valid on all systems. And --enable-vtable-verify is necessary in libstdc++, because you definitely want to be able to control whether or not libstdc++ is built with its virtual calls verifiable. What do other people believe is the right thing to do here? -- Caroline Tice cmt...@google.com
