Sequel to PR40521 -- -g causes GCC to generate .eh_frame

needs an update for the trunk, review still pending

Hasn't landed as at GCC r166920. I've contacted the original author to see if it's been superseded and, if not, if we can take it over.

About the upstream status of
<http://gcc.gnu.org/ml/gcc-patches/2010-04/msg00136.html>:

In September, I re-tried getting it committed:
<http://gcc.gnu.org/ml/gcc-patches/2010-09/msg01551.html>, but in Richard
Henderson's follow-up,
<http://gcc.gnu.org/ml/gcc-patches/2010-09/msg01572.html>, I was pointed
to the new way of how this ougt to be done, so I followed up in that
thread in <http://gcc.gnu.org/ml/gcc-patches/2010-09/msg01860.html>.

So, the original patch has sort-of been superseded / needs to be
re-done, but more easily than before. (That's what ``they'' say,
anyway.) ;-)

I had a look, and this patch can be dropped after merging from upstream;
see <http://gcc.gnu.org/ml/gcc-patches/2010-11/msg02300.html>.

The problem is fixed upstream (GCC 4.6) with a different patch.

The problem is fixed in Linaro GCC 4.5 with Thomas' rejected patch (and was released in September). This doesn't fix it in the most general way, but is not wrong, so I'm going to leave it as is. The patch is here: http://bazaar.launchpad.net/~linaro-toolchain-dev/gcc-linaro/4.5/revision/99352

This was fixed in GCC 4.4 right from the beginning in the initial CodeSourcery mega-patch.

keeping the current fix in gcc-4.5 and gcc-4.4, no more changes needed for the trunk