We call this "tree shaking" when compiling to JavaScript. The biggest downside is compile time. Your linker is doing more work and it can't easily be distributed.
The assumptions with inlineing virtual functions seem flawed to me. What if the program loads a plugin that defines (and returns an instance of) a class that overloads said function?
I dread the day someone figures out a way to weaponize this in practical fashion. I'd be astounded to learn that not-very-practical attacks don't already exist.
You can't really weaponize this, because if you're controlling the source code to a program written in C or C++ on a victim's computer, you've basically already won.
What I'd expect is that some loads / stores get optimized out across modules, causing bugs in multithreaded programs that were living the high life in x86 memory model land. Of course, these programs probably already have other bugs.
To be honest, I'm not so sure about that. Two attack surfaces I can think of off the top of my head where that could be leveraged are dynamic plugin loading, a-la old school ActiveX, and LD_LIBRARY_PATH attacks on ld.so based platforms.
One might say that both of these vectors are obsolete, but anytime you have a dynamic coding situation, that is one more term which is added to the equation of how one can interact with a system, regardless of its legitimacy.
Or perhaps another example involving attacks which use many vectors, a dual action bytecode verifier & x86 shellcode attack:
http://www.securityfocus.com/blogs/746
If you can convince any piece of code to do the unintended, that can be a constructive attack vector. Sure, we can harken back to the old days when code only did simple parsing and stayed away from data parsed in multiple contexts. I doubt that will be a sellable market proposition in the age of the Internet of Advertising, however!
I think you are confused between what linking and DLL loading are. They are different things. Linking is a step done during program development on object code by a compiler toolchain program to produce an executable. DLL loading is a step done by the OS on a user's machine at runtime to load an executable. Most non-developer Windows user machines will not even have a linker installed on the system.
Terminology warfare is so tedious. Whatever it is, it isn't going to flip one bit of it for us sitting here and arguing about what word best describes it, and the space of possible practical compilers is so, so much larger than the space of words we might have for them that it's not even funny. That is to say, it's not like there is a word for this, so why argue about whether it's "linking"? (It's not like looking at a functional language and calling it OO, where even if the all the terms involved are fuzzy, it's still clearly wrong.)
If compilers were somehow first developed on machines with the resources we have today, I bet we wouldn't even have a "link" step in practice. It's an artifact of having to break compilation up into little units that fit into small-numbers-of-kilobytes. Linkers inevitably fading into the background of just general "partial compilation" and "final compilation" steps is pretty inevitable, and that only as a form of caching the compilation rather than any sort of theoretically necessary step.
"direct to exe" perhaps. Of course things like dynamic link libraries screw up your assumptions about what the things you call actually do. And that can bite you, hence the previous model where you had 3, 4, even 6 copies of the C run time on your windows machine loaded into memory. Thank heaven they are dumping that model.
