------- Comment #3 from oiaohm at gmail dot com 2009-10-13 08:03 -------
Currently for libstdc++ it must be either dynamic or static. This separation
causes some problems.
There need to be two halfway points. The static libs the dynamic both be
there.
Type one halfway is for secuirty reasons. Having access to the bytecode lto of
like libstdc++ and others dynamic libs would allow deep scanning for code
defects like finding allocations of memory that don't get freed and buffer
overflows and others.
To get this advantage lto needs know that the byte code assigned to dynamic
libs is not to integrated since the dynamic libs already contain those
functions.
The second would build on type one. Optimizes would be allowed to look at the
lto code of the dynamic lib if functions can be optimized out it can be done.
If not those functions done by dynamic linking.
This is halfway between static and dynamic linking. Pure dynamic compiler does
not know what is inside the .so or .dll files other than the function
interfaces.
Doing this does raise the question if dynamic and static linking files should
be two different things or should they be basically the same. Static be lto
bytecode. Dynamic be precomplied + the same static lto bytecode.
Allowing full static analyzation inside compiler would be a major gain to
secuirty.
lto closes down cross object flaws from being seen from the compiler. But it
still leaves cross library flaws in dynamic that don't exist when static
linking with lto. Reason static linking with lto all bytecode data can be seen
even inside the libraries.
Lets provide an option to close the flaw. Being able to staticly solve out
with at .so lto bytecode in a lot of cases would give the same results as using
the static .a lto bytecode file.
Halfway could be used to remove duplication of lto bytecode to do either static
or highly audited dynamic linking. 1 copy to do both.
--
oiaohm at gmail dot com changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|WAITING |UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41681
