V3 PATCH to __verbose_terminate_handler

V3 PATCH to __verbose_terminate_handler

[Jason Merrill]

[-- Attachment #1: Type: text/plain, Size: 187 bytes --]

The other printfs in this function were changed earlier.

2002-12-18  Jason Merrill  <jason@redhat.com>

	* src/vterminate.cc (__verbose_terminate_handler): Send
	diagnostics to stderr.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-patch, Size: 754 bytes --]

*** libstdc++-v3/src/vterminate.cc.~1~	2002-12-18 11:23:35.000000000 -0500
--- libstdc++-v3/src/vterminate.cc	2002-09-13 10:23:31.000000000 -0400
*************** namespace __gnu_cxx
*** 55,65 ****
  	  int status = -1;
  	  char *dem = 0;
  	  
- 	  // Disabled until __cxa_demangle gets the runtime GPL exception.
  	  dem = __cxa_demangle(name, 0, 0, &status);
  
! 	  printf("terminate called after throwing a `%s'\n", 
! 		 status == 0 ? dem : name);
  
  	  if (status == 0)
  	    free(dem);
--- 55,64 ----
  	  int status = -1;
  	  char *dem = 0;
  	  
  	  dem = __cxa_demangle(name, 0, 0, &status);
  
! 	  fprintf(stderr, "terminate called after throwing a `%s'\n", 
! 		  status == 0 ? dem : name);
  
  	  if (status == 0)
  	    free(dem);

Re: V3 PATCH to __verbose_terminate_handler

[Gabriel Dos Reis]

Jason Merrill <jason@redhat.com> writes:

| 2002-12-18  Jason Merrill  <jason@redhat.com>
| 
| 	* src/vterminate.cc (__verbose_terminate_handler): Send
| 	diagnostics to stderr.

Hi Jason, 

  Is there a way to way this sort of message printed by default, instead of
having the  unfriendly "zsh: ./a.out: abort" when ./a.out is
terminated because of uncaught exception?

-- Gaby

Re: V3 PATCH to __verbose_terminate_handler

[Jason Merrill]

On 18 Dec 2002 17:37:32 +0100, Gabriel Dos Reis <gdr@integrable-solutions.net> wrote:

> Jason Merrill <jason@redhat.com> writes:
>
> | 2002-12-18  Jason Merrill  <jason@redhat.com>
> | 
> | 	* src/vterminate.cc (__verbose_terminate_handler): Send
> | 	diagnostics to stderr.
>
>   Is there a way to way this sort of message printed by default, instead of
> having the  unfriendly "zsh: ./a.out: abort" when ./a.out is
> terminated because of uncaught exception?

Well, the standard (18.6.3.1) says that the default terminate handler just
calls abort().  I suppose that if we're not -ansi, we could link in
something like

  #include <exception>

  namespace __gnu_cxx
  {
    extern void __verbose_terminate_handler ();
  }

  struct preload_terminate_dummy
  {
    preload_terminate_dummy()
    { std::set_terminate (__gnu_cxx::__verbose_terminate_handler); }
  };

  static preload_terminate_dummy dummy;

to override it; what do you think?

Jason

Re: V3 PATCH to __verbose_terminate_handler

[Gabriel Dos Reis]

Jason Merrill <jason@redhat.com> writes:

| On 18 Dec 2002 17:37:32 +0100, Gabriel Dos Reis <gdr@integrable-solutions.net> wrote:
| 
| > Jason Merrill <jason@redhat.com> writes:
| >
| > | 2002-12-18  Jason Merrill  <jason@redhat.com>
| > | 
| > | 	* src/vterminate.cc (__verbose_terminate_handler): Send
| > | 	diagnostics to stderr.
| >
| >   Is there a way to way this sort of message printed by default, instead of
| > having the  unfriendly "zsh: ./a.out: abort" when ./a.out is
| > terminated because of uncaught exception?
| 
| Well, the standard (18.6.3.1) says that the default terminate handler just
| calls abort().  I suppose that if we're not -ansi, we could link in
| something like
| 
|   #include <exception>
| 
|   namespace __gnu_cxx
|   {
|     extern void __verbose_terminate_handler ();
|   }
| 
|   struct preload_terminate_dummy
|   {
|     preload_terminate_dummy()
|     { std::set_terminate (__gnu_cxx::__verbose_terminate_handler); }
|   };
| 
|   static preload_terminate_dummy dummy;
| 
| to override it; what do you think?

Terrific!  I'm for it.

Hmm, do you think it will work with separately compiled files
with/without -ansi? 

What do others think?

-- Gaby

Re: V3 PATCH to __verbose_terminate_handler

[Phil Edwards]

On Thu, Dec 19, 2002 at 11:14:18AM +0100, Gabriel Dos Reis wrote:
> Jason Merrill <jason@redhat.com> writes:
> | 
> | Well, the standard (18.6.3.1) says that the default terminate handler just
> | calls abort().  I suppose that if we're not -ansi, we could link in
> | something like
> | 
> |   #include <exception>
> | 
> |   namespace __gnu_cxx
> |   {
> |     extern void __verbose_terminate_handler ();
> |   }
> | 
> |   struct preload_terminate_dummy
> |   {
> |     preload_terminate_dummy()
> |     { std::set_terminate (__gnu_cxx::__verbose_terminate_handler); }
> |   };
> | 
> |   static preload_terminate_dummy dummy;
> | 
> | to override it; what do you think?
> 
> Terrific!  I'm for it.
> 
> Hmm, do you think it will work with separately compiled files
> with/without -ansi? 

With the code as above, it would only take a single file including
<exception> and compiled without -ansi to turn on verbose-mode.  That seems
a bit too fast and loose.  I really like this idea, but perhaps the user
should still be required to explicitly request it (even if he isn't required
to actually write the code in his program).  Alternatives such as having
the ctor do

    if (getenv("GCC_VERBOSE_TERMINATE"))
        std::set_terminate (__gnu_cxx::__verbose_terminate_handler);

would seem to have too much of a speed impact on startup, I would think.


> What do others think?

I've been thinking about having some ancilliary .so's around, so that

    % LD_PRELOAD=..../verbose_terminate.so a.out

would be possible.

Anybody else?


Phil

-- 
I would therefore like to posit that computing's central challenge, viz. "How
not to make a mess of it," has /not/ been met.
                                                 - Edsger Dijkstra, 1930-2002

Re: V3 PATCH to __verbose_terminate_handler

[Gabriel Dos Reis]

Phil Edwards <phil@jaj.com> writes:

| On Thu, Dec 19, 2002 at 11:14:18AM +0100, Gabriel Dos Reis wrote:
| > Jason Merrill <jason@redhat.com> writes:
| > | 
| > | Well, the standard (18.6.3.1) says that the default terminate handler just
| > | calls abort().  I suppose that if we're not -ansi, we could link in
| > | something like
| > | 
| > |   #include <exception>
| > | 
| > |   namespace __gnu_cxx
| > |   {
| > |     extern void __verbose_terminate_handler ();
| > |   }
| > | 
| > |   struct preload_terminate_dummy
| > |   {
| > |     preload_terminate_dummy()
| > |     { std::set_terminate (__gnu_cxx::__verbose_terminate_handler); }
| > |   };
| > | 
| > |   static preload_terminate_dummy dummy;
| > | 
| > | to override it; what do you think?
| > 
| > Terrific!  I'm for it.
| > 
| > Hmm, do you think it will work with separately compiled files
| > with/without -ansi? 
| 
| With the code as above, it would only take a single file including
| <exception> and compiled without -ansi to turn on verbose-mode.  That seems
| a bit too fast and loose.

Well, here is the typical scenario I had in mind:

  1) Suppose Programmer has files nifty.C main.C

  2) 
     a) Programmer compiles nifty.C without -ansi
  
     b) Programmer compiles main.C (which contains ::main) with -ansi

     c) Programmer links without -ansi

What should happen?  Should we nevertheless be verbose about program
termination?  What if in step 2c) Programmer specified -ansi?

Put differently, should -ansi also be a "link-time" switch?

| I really like this idea, but perhaps the user
| should still be required to explicitly request it (even if he isn't required
| to actually write the code in his program).

Yeah, I now realize that the user may have his/her own terminate
handler. Well, I spoke too soon; never mind :-(

-- Gaby

Re: V3 PATCH to __verbose_terminate_handler

[Theodore Papadopoulo]

gdr@integrable-solutions.net said:
> What should happen?  Should we nevertheless be verbose about program
> termination?  What if in step 2c) Programmer specified -ansi?
> Put differently, should -ansi also be a "link-time" switch? 

I may be wrong but the choice of the default terminate handler is 
only a link time flag. It should boil down to linking with one object 
with default behavior or another one with the non-ansi version.

I have been surprised by this abort too often for not considering 
this as a useful extension.

	Theo.

--------------------------------------------------------------------
Theodore Papadopoulo
Email: Theodore.Papadopoulo@sophia.inria.fr Tel: (33) 04 92 38 76 01
 --------------------------------------------------------------------

Re: V3 PATCH to __verbose_terminate_handler

[Gabriel Dos Reis]

Theodore Papadopoulo <Theodore.Papadopoulo@sophia.inria.fr> writes:

| gdr@integrable-solutions.net said:
| > What should happen?  Should we nevertheless be verbose about program
| > termination?  What if in step 2c) Programmer specified -ansi?
| > Put differently, should -ansi also be a "link-time" switch? 
| 
| I may be wrong but the choice of the default terminate handler is 
| only a link time flag. It should boil down to linking with one object 
| with default behavior or another one with the non-ansi version.

In that case I would rather see a switch distinct from -ansi.  
-ansi is too bloated, IMHO.

| I have been surprised by this abort too often for not considering 
| this as a useful extension.

Hmmm, do you mean that a dry "zsh: ./a.out: abort" is clearer and more
useful that a message saying that the program was terminated because
of an uncaught exception?

-- Gaby

Re: V3 PATCH to __verbose_terminate_handler

[Theodore Papadopoulo]

gdr@integrable-solutions.net said:
> In that case I would rather see a switch distinct from -ansi.   -ansi
> is too bloated, IMHO.

Agreed...

> Hmmm, do you mean that a dry "zsh: ./a.out: abort" is clearer and more
> useful that a message saying that the program was terminated because
> of an uncaught exception? 

I meant exactly the opposite. A message saying "Uncaught exception" 
would be much better than this "abort".

	Theo.

--------------------------------------------------------------------
Theodore Papadopoulo
Email: Theodore.Papadopoulo@sophia.inria.fr Tel: (33) 04 92 38 76 01
 --------------------------------------------------------------------

Re: V3 PATCH to __verbose_terminate_handler

[Jason Merrill]

On Thu, 19 Dec 2002 18:15:31 +0100, Theodore Papadopoulo <Theodore.Papadopoulo@sophia.inria.fr> wrote:

> gdr@integrable-solutions.net said:
>> In that case I would rather see a switch distinct from -ansi.   -ansi
>> is too bloated, IMHO.
>
> Agreed...

Well, -lverbose_terminate or some such would work.

Jason

Re: V3 PATCH to __verbose_terminate_handler

[Phil Edwards]

On Thu, Dec 19, 2002 at 05:47:23PM +0100, Theodore Papadopoulo wrote:
> gdr@integrable-solutions.net said:
> > What should happen?  Should we nevertheless be verbose about program
> > termination?  What if in step 2c) Programmer specified -ansi?
> > Put differently, should -ansi also be a "link-time" switch? 
> 
> I may be wrong but the choice of the default terminate handler is 
> only a link time flag. It should boil down to linking with one object 
> with default behavior or another one with the non-ansi version.

Well, sort of.

Right now the default is set simply by

    // unwind-cxx.h
    namespace __cxxabiv1
    {
        extern std::terminate_handler __terminate_handler;
    }

    // eh_terminate.cc
    std::terminate_handler __cxxabiv1::__terminate_handler = std::abort;

Let's say that we use a link-time -lverbose_terminate, and/or a runtime
LD_PRELOAD'able library, using the static struct already posted.  Don't we
have race conditions here, with multiple namespace-scope variables in
separate translation units?


Phil

-- 
I would therefore like to posit that computing's central challenge, viz. "How
not to make a mess of it," has /not/ been met.
                                                 - Edsger Dijkstra, 1930-2002

Re: V3 PATCH to __verbose_terminate_handler

[Jason Merrill]

On Thu, 19 Dec 2002 14:38:30 -0500, Phil Edwards <phil@jaj.com> wrote:

> On Thu, Dec 19, 2002 at 05:47:23PM +0100, Theodore Papadopoulo wrote:
>> gdr@integrable-solutions.net said:
>> > What should happen?  Should we nevertheless be verbose about program
>> > termination?  What if in step 2c) Programmer specified -ansi?
>> > Put differently, should -ansi also be a "link-time" switch? 
>> 
>> I may be wrong but the choice of the default terminate handler is 
>> only a link time flag. It should boil down to linking with one object 
>> with default behavior or another one with the non-ansi version.
>
> Well, sort of.
>
> Right now the default is set simply by
>
>     // unwind-cxx.h
>     namespace __cxxabiv1
>     {
>         extern std::terminate_handler __terminate_handler;
>     }
>
>     // eh_terminate.cc
>     std::terminate_handler __cxxabiv1::__terminate_handler = std::abort;
>
> Let's say that we use a link-time -lverbose_terminate, and/or a runtime
> LD_PRELOAD'able library, using the static struct already posted.  Don't we
> have race conditions here, with multiple namespace-scope variables in
> separate translation units?

No.  The above is initialized at compile-time; preload_terminate_dummy
works at runtime.

Jason

Re: V3 PATCH to __verbose_terminate_handler

[Phil Edwards]

On Thu, Dec 19, 2002 at 02:38:30PM -0500, Phil Edwards wrote:
> Don't we
> have race conditions here, with multiple namespace-scope variables in
> separate translation units?

Of course we don't.  My brain kicked in just after typing ":wq".  I'd like
everyone to forget that I wrote that question.  :-)


So, opinions on a [lib]verbose_terminate.so?  Thoughts, dicussion,
suggestions?  I'll start hacking on a patch.


Phil

-- 
I would therefore like to posit that computing's central challenge, viz. "How
not to make a mess of it," has /not/ been met.
                                                 - Edsger Dijkstra, 1930-2002

Re: V3 PATCH to __verbose_terminate_handler

[Gabriel Dos Reis]

Phil Edwards <phil@jaj.com> writes:

| So, opinions on a [lib]verbose_terminate.so?  Thoughts, dicussion,
| suggestions?  I'll start hacking on a patch.

I believe that everyone agrees on -lverbose_terminate.

-- Gaby

Re: V3 PATCH to __verbose_terminate_handler

[Gabriel Dos Reis]

Theodore Papadopoulo <Theodore.Papadopoulo@sophia.inria.fr> writes:

| I meant exactly the opposite.

Thanks. 

[Obviously I needed some sleep]

-- Gaby