Re: -fno-exceptions and libgcc.a

Re: -fno-exceptions and libgcc.a

[Jason Merrill]

>>>>> H J Lu <hjl@lucon.org> writes:

> To save disk space, I use -fno-exceptions to compile egcs. But the
> resuled egcs binary fails most of exception handling tests. Taking
> out -fno-exceptions fixes it. I suspect part of libgcc.a should be
> compiled with -fexceptions even if -fno-exceptions is used. Any ideas?

_eh.o and the C++ pieces need to be compiled with -fexceptions.

Jason

Re: -fno-exceptions and libgcc.a

[Richard Henderson]

On Mon, Oct 06, 1997 at 01:14:04PM -0700, Per Bothner wrote:
> 6) The proposed solutions are more work than implementing *what people
> expect* - i.e. no exception handling support for C, unless requested.

I will note for the record that both Digital Unix and Irix 6 both
generate frame-unwind info for all functions all of the time.  There
is no option to turn it off, and no option to strip it.

IMO we should figure out how to make the info smaller for the common
case, but to generate the info by default, whatever the language. 
People are only bitching now because it is apparently 1/3 the size of
the text on i386.  If the overhead were more like 32 bytes / function,
I seriously doubt they'd care or notice.

There are useful things one can do with that info, even from C, if
you can be resonably sure that everything will have that info.  If
libc and libX11 are built without it, it makes it significantly less
useful.  Now you are going to either force a second copy of the 
library on the system, or throw up your hands in dispair.


r~

Re: -fno-exceptions and libgcc.a

[Per Bothner]

I don't the any of the suggestions for having the linker drop
the .eh_frame section will work:

1) Many people are still using old-fashioned object-file formats without
named sections.
2) Even if you are using C++ and throwing exceptions, you don't want
your C library, your X libraries, etc to waste a lot of space on .eh_frame.
Educating everyone people to use -fno-exceptions for their C code
is difficult, unproductive, and will rightfully get people annoyed
at unexpected G++ behavior.
3) The .o files will still be large, and people will notice (and complain).
4) Gnerating and throwing .eh_frame sections wastes time and space.
5) In a world with dynamically loaded libraries, you cannot reliably tell
if an application might contain a throw.  Hence the static linker cannot
reliably determine of .eh_frame is unneeded.
6) The proposed solutions are more work than implementing *what people
expect* - i.e. no exception handling support for C, unless requested.

	--Per Bothner
Cygnus Solutions     bothner@cygnus.com     http://www.cygnus.com/~bothner

Re: -fno-exceptions and libgcc.a

[Mike Stump]

> Date: Sun, 5 Oct 1997 21:28:20 -0500 (CDT)
> From: Oleg Krivosheev <kriol@fnal.gov>
> To: Joe Buck <jbuck@synopsys.com>

> On Sat, 4 Oct 1997, Joe Buck wrote:

> The most interesting situation will be when Kenner will choose
> another EH approach as base in gcc installation.

If/when that happens, we can worry about it.  If he comes up with
something better than ours, I don't have a problem adding it.  I don't
think that is going to happen, but I would love to see it happen.

Re: -fno-exceptions and libgcc.a

[Mark Mitchell]

>>>>> "Joe" == Joe Buck <jbuck@synopsys.com> writes:

    Mark> I suggest a different scheme:
    >>
    Mark> o The default remains -fno-exceptions when compiling.
    >>
    Mark> o At link-time, if gcc is used to link the executable, we
    Mark> remove the .eh_frame section.  If g++/c++ is used, we keep
    Mark> it.
    >>  Hm. I tend to forget "g++" even exists -- I always compile
    >> everything by calling "gcc" and letting it sort out what to do
    >> with the file.

    Joe> All g++ and c++ do is invoke gcc with the right options, so
    Joe> what Mark is really saying is that there is a flag that tells
    Joe> the linker (or some program that is run just before the
    Joe> linker, like collect) to remove the .eh_frame section.  My
    Joe> counter-proposal was to have the linker remove the .eh_frame
    Joe> section if and only if no code in the executable throws an
    Joe> exception (meaning that there is some flag in the object file
    Joe> indicating this).  Of course this can only be an
    Joe> optimization; some users will have collect + the native
    Joe> linker.

By the way, I never replied to this suggestion.  I think it may be a good
one, but seems harder than mine, so I still think mine might be a good
place to start.

    >> Conversely, you also need a solution for those who invoke "ld"
    >> directly (as opposed to indirectly via gcc or g++).

    Joe> Those who invoke ld directly, unless they are using the GNU
    Joe> linker, won't get correct C++ programs (since constructors
    Joe> for file-scope objects won't be called).

-- 
Mark Mitchell		mmitchell@usa.net
Stanford University	http://www.stanford.edu

Re: -fno-exceptions and libgcc.a

[Mark Mitchell]

>>>>> "Paul" == Paul Koning <pkoning@xedia.com> writes:

>>>>> "Mark" == Mark Mitchell <mmitchell@usa.net> writes:

>>>>> "Per" == Per Bothner <bothner@cygnus.com> writes:

    >>>> It is reasonable to either change the default for exception
    >>>> handling to off for C,

    Per> I don't understand why there is even any discussion of this.
    Per> The default for C *has* to -fno-exceptions, unless there is
    Per> *no* cost for code that does not use the exceptions.
    Per> Anything else is a public relations disaster in terms of the
    Per> perceived code quality of gcc.  This *must* be fixed before
    Per> egcs (or gcc 2.8) is released.

    Mark> I suggest a different scheme:

    Mark> o The default remains -fno-exceptions when compiling.

    Mark> o At link-time, if gcc is used to link the executable, we
    Mark> remove the .eh_frame section.  If g++/c++ is used, we keep
    Mark> it.

    Paul> Hm. I tend to forget "g++" even exists -- I always compile
    Paul> everything by calling "gcc" and letting it sort out what to
    Paul> do with the file.  That's the whole point of the existence
    Paul> of the gcc front end driver, isn't it?

    Paul> So if I say "gcc foo.cc" it would be nice to have the Right
    Paul> Thing happen.  It is undesirable to have to change
    Paul> makefiles.

I'm a little confused.  You're correct that "gcc foo.cc" knows that
foo.cc is C++, but it doesn't link with the C++ standard library.
But, I agree, in this case, we should leave the .eh_frame section in.
So, consider that a modification to my suggestion.

    Paul> Conversely, you also need a solution for those who invoke
    Paul> "ld" directly (as opposed to indirectly via gcc or g++).

Well, we're going to need a means of dropping the entire .eh_frame
section at link-time in my scheme.  This means that ld will have to do
this for us, and that we'll have to tell it to do so.  Therefore,
there's a way for a user to do this when invoking ld directly.

    Paul> 	paul

-- 
Mark Mitchell		mmitchell@usa.net
Stanford University	http://www.stanford.edu

Re: -fno-exceptions and libgcc.a

[Joe Buck]

>  Mark> I suggest a different scheme:
> 
>  Mark> o The default remains -fno-exceptions when compiling.
> 
>  Mark> o At link-time, if gcc is used to link the executable, we
>  Mark> remove the .eh_frame section.  If g++/c++ is used, we keep it.
> 
> Hm. I tend to forget "g++" even exists -- I always compile everything
> by calling "gcc" and letting it sort out what to do with the file.

All g++ and c++ do is invoke gcc with the right options, so what Mark
is really saying is that there is a flag that tells the linker (or some
program that is run just before the linker, like collect) to remove
the .eh_frame section.  My counter-proposal was to have the linker
remove the .eh_frame section if and only if no code in the executable
throws an exception (meaning that there is some flag in the object
file indicating this).  Of course this can only be an optimization;
some users will have collect + the native linker.

> Conversely, you also need a solution for those who invoke "ld"
> directly (as opposed to indirectly via gcc or g++).

Those who invoke ld directly, unless they are using the GNU linker,
won't get correct C++ programs (since constructors for file-scope
objects won't be called).

Re: -fno-exceptions and libgcc.a

[Paul Koning]

>>>>> "Mark" == Mark Mitchell <mmitchell@usa.net> writes:

>>>>> "Per" == Per Bothner <bothner@cygnus.com> writes:

 >>> It is reasonable to either change the default for exception
 >>> handling to off for C,

 Per> I don't understand why there is even any discussion of this.
 Per> The default for C *has* to -fno-exceptions, unless there is *no*
 Per> cost for code that does not use the exceptions.  Anything else
 Per> is a public relations disaster in terms of the perceived code
 Per> quality of gcc.  This *must* be fixed before egcs (or gcc 2.8)
 Per> is released.

 Mark> I suggest a different scheme:

 Mark> o The default remains -fno-exceptions when compiling.

 Mark> o At link-time, if gcc is used to link the executable, we
 Mark> remove the .eh_frame section.  If g++/c++ is used, we keep it.

Hm. I tend to forget "g++" even exists -- I always compile everything
by calling "gcc" and letting it sort out what to do with the file.
That's the whole point of the existence of the gcc front end driver,
isn't it?

So if I say "gcc foo.cc" it would be nice to have the Right Thing
happen.  It is undesirable to have to change makefiles.

Conversely, you also need a solution for those who invoke "ld"
directly (as opposed to indirectly via gcc or g++).

	paul

Re: -fno-exceptions and libgcc.a

[Oleg Krivosheev]

Hi,

On Sat, 4 Oct 1997, Joe Buck wrote:

> > It will expose g++ specific EH in the libc. What Linux people
> > with KAI C++ or Comeau C++ supposed to do if glibc
> > will be compiled with g++ exceptions? looks like
> > linker modifications a la Mark Mitchel is required.
> 
> If I were a strict GNUist, I'd have to answer that it isn't out job to
> make life easier for those who don't provide source.  But seriously, it
> will be up to KAI or Comeau to provide workarounds; it was never in the
> egcs charter to support linking with other compilers.

well, i was talking about GNU libc where qsort
belongs. The most interesting situation will be 
when Kenner will choose another EH approach as
base in gcc installation. Just imagine, Redhat will
have their libc compiled by gcc, while debian
choose egcs.

For glibc probably the best approach to compile 
all library without any EH info and
ask compiler writers to provide their
own implementations for qsort, bsearch etc.
i don't think there is much code to add.

But i cannot think about what to do with X and
related stuff, for example

regards

OK

Re: -fno-exceptions and libgcc.a

[Joe Buck]

> I suggest a different scheme: 
> 
>   o The default remains -fno-exceptions when compiling.
> 
>   o At link-time, if gcc is used to link the executable, we remove
>     the .eh_frame section.  If g++/c++ is used, we keep it.

Why distinguish among languages?  Why not distinguish on the basis
of whether any code is linked in that actually throws an exception?
That is, flag any .o file where an exception is thrown; remove all
the exception-handling sections in the executable if no one uses them.

Re: -fno-exceptions and libgcc.a

[Joe Buck]

> It will expose g++ specific EH in the libc. What Linux people
> with KAI C++ or Comeau C++ supposed to do if glibc
> will be compiled with g++ exceptions? looks like
> linker modifications a la Mark Mitchel is required.

If I were a strict GNUist, I'd have to answer that it isn't out job to
make life easier for those who don't provide source.  But seriously, it
will be up to KAI or Comeau to provide workarounds; it was never in the
egcs charter to support linking with other compilers.

> Well, published Linux C++ ABI will be the best solution IMHO.

This can't happen yet.  The C++ ABI can't be stable until we have
a complete ANSI compiler (including namespaces).  Besides, thre
are still more improvements to be had.  The current name mangling
scheme could stand improvements so that templat class names don't
come out so huge; egcs should not give up the right to makes such
improvements.

Re: -fno-exceptions and libgcc.a

[Oleg Krivosheev]

hi,

On Sat, 4 Oct 1997, Per Bothner wrote:

> I don't understand why there is even any discussion of this.
> The default for C *has* to -fno-exceptions, unless there is
> *no* cost for code that does not use the exceptions.
> Anything else is a public relations disaster in terms
> of the perceived code quality of gcc.  This *must* be
> fixed before egcs (or gcc 2.8) is released.
> 
> There should be a #pragma or __sttribute__ to specify that
> "this code needs to be robost in the presence of exceptions."
> This could be turned on for qsort (the canonical example of
> possibly throwing exceptions through C code), but off for
> the rest of the C library.  Similar for libgcc.

hmm...
It will expose g++ specific EH in the libc. What Linux people
with KAI C++ or Comeau C++ supposed to do if glibc
will be compiled with g++ exceptions? looks like
linker modifications a la Mark Mitchel is required.

Well, published Linux C++ ABI will be the best solution IMHO.

regards

OK

Re: -fno-exceptions and libgcc.a

[Mark Mitchell]

>>>>> "Per" == Per Bothner <bothner@cygnus.com> writes:

    >> It is reasonable to either change the default for exception
    >> handling to off for C,

    Per> I don't understand why there is even any discussion of this.
    Per> The default for C *has* to -fno-exceptions, unless there is
    Per> *no* cost for code that does not use the exceptions.
    Per> Anything else is a public relations disaster in terms of the
    Per> perceived code quality of gcc.  This *must* be fixed before
    Per> egcs (or gcc 2.8) is released.

I suggest a different scheme: 

  o The default remains -fno-exceptions when compiling.

  o At link-time, if gcc is used to link the executable, we remove
    the .eh_frame section.  If g++/c++ is used, we keep it.

I see the following benefits:

  o It's easy to build a library of C code that can then be linked
    with C++ code such that exceptions are propogated correctly.
 
  o Pure C binaries are no bigger than they used to be.

Of course, we should have a switch so that the default behavior at
link-time could be overridden.  And, I don't know how well this would
work for platforms using sjlj exceptions.  Comments?

    Per> There should be a #pragma or __sttribute__ to specify that
    Per> "this code needs to be robost in the presence of exceptions."
    Per> This could be turned on for qsort (the canonical example of
    Per> possibly throwing exceptions through C code), but off for the
    Per> rest of the C library.  Similar for libgcc.

    Per> 	--Per Bothner Cygnus Solutions bothner@cygnus.com
    Per> http://www.cygnus.com/~bothner

-- 
Mark Mitchell		mmitchell@usa.net
Stanford University	http://www.stanford.edu

Re: -fno-exceptions and libgcc.a

[Per Bothner]

> It is reasonable to either change the default for exception handling
> to off for C,

I don't understand why there is even any discussion of this.
The default for C *has* to -fno-exceptions, unless there is
*no* cost for code that does not use the exceptions.
Anything else is a public relations disaster in terms
of the perceived code quality of gcc.  This *must* be
fixed before egcs (or gcc 2.8) is released.

There should be a #pragma or __sttribute__ to specify that
"this code needs to be robost in the presence of exceptions."
This could be turned on for qsort (the canonical example of
possibly throwing exceptions through C code), but off for
the rest of the C library.  Similar for libgcc.

	--Per Bothner
Cygnus Solutions     bothner@cygnus.com     http://www.cygnus.com/~bothner

Re: -fno-exceptions and libgcc.a

[Mike Stump]

It is reasonable to either change the default for exception handling
to off for C, or to change autoconf, or gcc'c config scheme to see if
-fno-exceptions works, and if it does, to use it.  And that is the
order I prefer them.

Passing -fexceptions is a reasonable thing to do when compiling L_eh
of libgcc2.c.

> From: hjl@lucon.org (H.J. Lu)
> Date: Fri, 3 Oct 1997 14:17:42 -0700 (PDT)

> To save disk space, I use -fno-exceptions to compile egcs. But the
> resuled egcs binary fails most of exception handling tests. Taking
> out -fno-exceptions fixes it. I suspect part of libgcc.a should be
> compiled with -fexceptions even if -fno-exceptions is used.

-fno-exceptions and libgcc.a

[H.J. Lu]

Hi,

To save disk space, I use -fno-exceptions to compile egcs. But the
resuled egcs binary fails most of exception handling tests. Taking
out -fno-exceptions fixes it. I suspect part of libgcc.a should be
compiled with -fexceptions even if -fno-exceptions is used. Any ideas?

Thanks.


-- 
H.J. Lu (hjl@gnu.ai.mit.edu)