egcs and exceptions

egcs and exceptions

[Andris Pavenis]

Hi!

When I found problems with exceptions with DJGPP port of egcs-1.1
I tried to study more detailed what works and what fails. 

I used for tests:
	egcs-1.1:
		native compiler for Linux (i586-pc-linux-gnulibc1)
		native compiler for DJGPP (i386-pc-msdosdjgpp)
		cross-compiler from Linux to DJGPP

	egcs-2.92.16 19981019 
		native compiler for Linux
		cross-compiler from Linux to DJGPP (it was more easy
                      for me to build cross-compiler than the native
                      one) 

Here are some results:

with -fsjlj-exceptions : I was not able to get exceptions working
	for both Linux and DJGPP and with stable release (egcs-1.1)
	and with later development snapshot of egcs (egcs-2.92.16).
	Only thing I get from throwing exception is SIGABRT

	So it's seems that -fsjlj-exceptions is broken with egcs-1.1
	and later snapshots

without -fsjlj-exceptions

	Linux (i586-pc-linux-gnulibc1) and egcs-1.1 release

		works. No evident problems

	Linux (i586-pc-msdos-gnulibc1) and snapshot egcs-2.92.16
	
		works when -fomit-frame-pointer is not specified
		SIGABRT with -fomit-frame-pointer

	DJGPP and egcs-1.1 release (both native compiler for DJGPP 
	and cross-compiler from Linux)

		generally works but there are serious problems.
		I have send messages about them egcs mailing list
		and these problems are already discussed in djgpp
		mailing lists

	DJGPP and egcs-2.92.16 (cross-compiler from Linux only)

		does not work at all. I'm getting only SIGABRT


	DJGPP and gcc-2.8.1

		works without problems.

Here is example I used for tests:

-----------------------------------------------------------
#include <iostream>
#include <string>

// Test example for exceptions problem with DJGPP port of egcs-1.1

// If the next line is uncommented all 4 exceptions are catched
//#define  D(x)  x

// If the next line is uncommented only first 3 exceptions are catched.
// The last one ends with abort
#define  D(x)

// With gcc-2.8.1 both tests works Ok

class xx {};

class test
  {
  public:
         string text;

         test (const char * x) : text(x)
           {
               cout << "test::test(\"" << text << "\")\n";
           }

         ~test ()
           {
               cout << "test::~test() : \"" << text << "\"\n";
           }
  };

void  touch ( test & x ); /* Let's fool gcc to think this object is 
                             really used */

void x1 (void) throw (xx)
  {
     D(test w1 ("void x1 (void) throw (xx)"));
     D(touch (w1));
     xx a;
     throw(a);
  }

void x2 (void)
  {
     D(test w2 ("void x2 (void)"));
     D(touch (w2));
     xx a;
//   #ifdef __MSDOS__
//     if (biostime(0,0L)!=0)
//   #endif
        throw(a);
     return;
  }

void x1a (void)
  {
     D(test w3 ("void x1a (void)"));
     D(touch (w3));
     x1 ();
  }

void x1b (void) throw (xx)
  {
     D(test w3 ("void x1b (void)"));
     D(touch (w3));
     x1 ();
  }

int main (void)
{
   try { x1(); } catch (xx w) { cout << "catched from x1()\n"; }
   cout << "----------------\n";
   try { x1b(); } catch (xx w) { cout << "catched from x1b()\n"; }
   cout << "----------------\n";
   try { x1a(); } catch (xx w) { cout << "catched from x1a()\n"; }
   cout << "----------------\n";
   try { x2(); } catch (xx w) { cout << "catched from x2()\n"; }
   cout << "----------------\n";
   return 0;
}

void  touch ( test & )
{
}


--------------------------------------------------------------

Andris

Re: egcs and exceptions

[Alexandre Oliva]

Andris Pavenis <pavenis@lanet.lv> writes:

> with -fsjlj-exceptions : I was not able to get exceptions working
> 	for both Linux and DJGPP and with stable release (egcs-1.1)

> 	So it's seems that -fsjlj-exceptions is broken with egcs-1.1
> 	and later snapshots

Maybe you have to build libgcc.a and libstdc++.a with this option
enabled.  At least that's my reading from gcc/except.c:

   There are two major codegen options for exception handling.  The
   flag -fsjlj-exceptions can be used to select the setjmp/longjmp
   approach, which is the default.  -fno-sjlj-exceptions can be used to
   get the PC range table approach.  While this is a compile time
   flag, an entire application must be compiled with the same codegen
   option.  

Of course one may argue that libgcc has nothing to do with `the entire 
application', and I'm not really sure you must really choose sjlj at
build time, but if you have spare CPU cycles to try that, it would be
nice to know...

-- 
Alexandre Oliva
mailto:oliva@dcc.unicamp.br mailto:oliva@gnu.org mailto:aoliva@acm.org
http://www.dcc.unicamp.br/~oliva
Universidade Estadual de Campinas, SP, Brasil

Re: egcs and exceptions

[Mumit Khan]

On 29 Oct 1998, Alexandre Oliva wrote:

> 
> Of course one may argue that libgcc has nothing to do with `the entire 
> application', and I'm not really sure you must really choose sjlj at
> build time, but if you have spare CPU cycles to try that, it would be
> nice to know...

With my stock egcs-1.1b setup on i686-pc-linux-gnu, I can turn on sjlj 
EH with -fsjlj-exceptions flag, at least for the trivial testcases I've 
tried. 

This is the first I've heard of sjlj EH not work on a "well greased"
target like i686-linux. In fact, it's the one that consistently works, 
where dwarf2 requires a *lot* more work, including cooperation from 
the linker. I never did get dwarf2 to work under win32 for example, 
but sjlj worked like a champ out of the box the first time.

Regards,
Mumit

Re: egcs and exceptions

[Jason Merrill]

>>>>> Alexandre Oliva <oliva@dcc.unicamp.br> writes:

 > Maybe you have to build libgcc.a and libstdc++.a with this option
 > enabled.

Yes.  If you want to use sjlj, it makes more sense to change
the default for exceptions_via_longjmp in except.c and rebuild the
compiler, rather than trying to consistently pass the flag.  This is true
for other ABI flags, as well.

 > Of course one may argue that libgcc has nothing to do with `the entire 
 > application'

It absolutely does.  Much of the EH support code is written in C++.

Jason

Re: egcs and exceptions

[Alexandre Oliva]

On Oct 31, 1998, Jason Merrill <jason@cygnus.com> wrote:

>>>>>> Alexandre Oliva <oliva@dcc.unicamp.br> writes:

>> Maybe you have to build libgcc.a and libstdc++.a with this option
>> enabled.

> Yes.  If you want to use sjlj, it makes more sense to change
> the default for exceptions_via_longjmp in except.c and rebuild the
> compiler, rather than trying to consistently pass the flag.  This is true
> for other ABI flags, as well.

But the doubt is: must you do that, or can you just compile and link
foo.cc with -fsjlj-exceptions on Solaris and it will work?  I remember 
it used to work back in the pre-2.8 days, but it may have changed
after dwarf2 exception support was added.

-- 
Alexandre Oliva
mailto:oliva@dcc.unicamp.br mailto:oliva@gnu.org mailto:aoliva@acm.org
http://www.dcc.unicamp.br/~oliva
Universidade Estadual de Campinas, SP, Brasil

Re: egcs and exceptions

[Jason Merrill]

>>>>> Alexandre Oliva <oliva@dcc.unicamp.br> writes:

 > On Oct 31, 1998, Jason Merrill <jason@cygnus.com> wrote:
 >>>>>>> Alexandre Oliva <oliva@dcc.unicamp.br> writes:

 >>> Maybe you have to build libgcc.a and libstdc++.a with this option
 >>> enabled.

 >> Yes.  If you want to use sjlj, it makes more sense to change
 >> the default for exceptions_via_longjmp in except.c and rebuild the
 >> compiler, rather than trying to consistently pass the flag.  This is true
 >> for other ABI flags, as well.

 > But the doubt is: must you do that, or can you just compile and link
 > foo.cc with -fsjlj-exceptions on Solaris and it will work?

It may work, but not reliably.

Jason

Re: egcs and exceptions

[Alexandre Oliva]

On Nov  3, 1998, Jason Merrill <jason@cygnus.com> wrote:

>>>>>> Alexandre Oliva <oliva@dcc.unicamp.br> writes:
>> But the doubt is: must you do that, or can you just compile and link
>> foo.cc with -fsjlj-exceptions on Solaris and it will work?

> It may work, but not reliably.

You know...  The more I think about these options that require the
whole library to be rebuilt, the more I believe we should require them 
to be specified at some point in compile-time in order to enable them
at run-time.  Perhaps some additional configure switch that causes
them to be used to build the library and enables the switch by
default, or something that causes multilibs to be created to support
both variants (enabled and disabled) of the particular flag...

-- 
Alexandre Oliva
mailto:oliva@dcc.unicamp.br mailto:oliva@gnu.org mailto:aoliva@acm.org
http://www.dcc.unicamp.br/~oliva
Universidade Estadual de Campinas, SP, Brasil

Re: egcs and exceptions

[Klaus-Georg Adams]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1469 bytes --]

Alexandre wrote:

> You know...  The more I think about these options that require the
> whole library to be rebuilt, the more I believe we should require them 
> to be specified at some point in compile-time in order to enable them
> at run-time.  Perhaps some additional configure switch that causes
> them to be used to build the library and enables the switch by
> default, or something that causes multilibs to be created to support
> both variants (enabled and disabled) of the particular flag...

I can only support that comment. I have tried to run the bench++ suite
with -sjlj once (maybe Feb-1998) and it was _hard_ to figure out 
- what has to be built with that flag
- and how to reliably do that without having to edit the Makefiles
(that's what I ended up doing).

At one point I had most of the things together, but still some of the
tests crashed (and I wasn't sure if it was another goof of yours truly
or a bug in the EH of egcs).

IMHO things like -fnew-abi or -fsjlj-exceptions should be a
configuretime option (setting them to be the default and building all
the runtime stuff with the Right Flags).

-- kga
-------------------------------------------------------------------------
Klaus-Georg Adams        Email: Klaus-Georg.Adams@chemie.uni-karlsruhe.de
Institut f. Anorg. Chemie, Lehrstuhl II            Tel: 49(0)721 608 3485
Universität Karlsruhe, D-76128 Karlsruhe
-------------------------------------------------------------------------