Re: Problem w/PIC and C++ exceptions in 2.95 on IA-32

Re: Problem w/PIC and C++ exceptions in 2.95 on IA-32

[Phil Edwards]

> The only reasons I see for things not to be so are:
> * working on 2.97 already (hum, one can hope).

Is that a typo, or is 2.96 being skipped for some reason?


> Out of curiosity, what schedule would you consider reasonable for bug-fixed
> releases ?
>
> Personnally, I would tend to say 2~3 months is about right...

This is about what the new Solaris does.  Three or four releases of
Solaris7, spaced a few months apart and dated as such, containing
(nearly) all the bugfixes up to that point.  Works out pretty well so far.

Phil

Re: Problem w/PIC and C++ exceptions in 2.95 on IA-32

[Marc Lehmann]

On Thu, Jan 27, 2000 at 09:28:20PM +0100, Marc Espie <espie@quatramaran.ens.fr> wrote:
> 2.95.2 is already 3 months old.   If those bug-fixes are serious enough
> to be in the 2.92 branch, I'd say this is old enough.

Seconded. There is no 2.96+ release in sight, and the bugs were serious
enough.

-- 
      -----==-                                             |
      ----==-- _                                           |
      ---==---(_)__  __ ____  __       Marc Lehmann      +--
      --==---/ / _ \/ // /\ \/ /       pcg@opengroup.org |e|
      -=====/_/_//_/\_,_/ /_/\_\       XX11-RIPE         --+
    The choice of a GNU generation                       |
                                                         |

Re: Problem w/PIC and C++ exceptions in 2.95 on IA-32

[Marc Espie]

In article < 10001271231.AA17582@vlsi1.ultra.nyu.edu > you write:
>    > 	FreeBSD and others actually track the gcc-2.95 release branch of
>    > CVS, so it matters to people even if we do not produce a formal release.
>
>    IMHO, the GCC Project may find that more and more people do this also.
>
>To me, this seems a bad thing to do.  If we don't actually produce a formal
>release, that branch isn't going to get much testing, so I'd be very dubious
>about people using it as the base for other releases.

I agree.
Now, let's sum things up.

On the one hand, only important bug-fixes are put on the old release branch.

On the other hand, this branch does not get serious testing if no release
is produced with it.


Well, for me, the conclusion is obvious:
the presence of new fixes on the 2.95 branch since 2.95.2 means 2.95.3
should go out, and soon !

The only reasons I see for things not to be so are:
* working on 2.97 already (hum, one can hope).

* wanting to avoid the `release of the day' syndrome.

2.95.2 is already 3 months old.   If those bug-fixes are serious enough
to be in the 2.92 branch, I'd say this is old enough.

Out of curiosity, what schedule would you consider reasonable for bug-fixed
releases ?

Personnally, I would tend to say 2~3 months is about right... considering
that a bug-fixed release is less work than a full release (diminishing
returns: after a while, the number of critical changes will decrease
drastically, as will the likelihood that a bug-fix  triggers other untraceable
bugs.

Re: Problem w/PIC and C++ exceptions in 2.95 on IA-32

[Richard Kenner]

    > 	FreeBSD and others actually track the gcc-2.95 release branch of
    > CVS, so it matters to people even if we do not produce a formal release.

    IMHO, the GCC Project may find that more and more people do this also.

To me, this seems a bad thing to do.  If we don't actually produce a formal
release, that branch isn't going to get much testing, so I'd be very dubious
about people using it as the base for other releases.

    We've found with FreeBSD people that want a stable, dependable version
    of the software will trace the branch the last release came from in
    order to pick up minor (or major) bug 

But if those bugfixes haven't gotten much testing in the context of the
release branch, I would *not* call that a dependable version, especially
if the number of "bug fixes" that go in there gets high, as it seems is
being proposed.  Who has tested that all those patches work well together?

    Trusting your livelihood to the HEAD branch (of either FreeBSD or GCC)
    isn't wise.  :-)

That's perhaps true, but I think trusting your livelihood to a branch that
has received even *less* testing is even less wise.

Re: Problem w/PIC and C++ exceptions in 2.95 on IA-32

[Richard Henderson]

On Fri, Jan 21, 2000 at 12:27:32AM -0600, Clinton Popetz wrote:
> > 2000-01-18  Clinton Popetz  <cpopetz@cygnus.com>
> >  
> >         * loop.c (check_dbra_loop): When checking a loop for
> >         reversability, check the source of any stores to ensure they
> >         don't depend on an initial value. 
> 
> Actually, this one was never approved for the mainline...

Ok.


r~

Re: Problem w/PIC and C++ exceptions in 2.95 on IA-32

[Clinton Popetz]

Franz Sirl <Franz.Sirl-kernel@lauterbach.com> writes:

> >  > This only matters if we plan on issuing 2.95.3.  Do we have sufficient
> >  > minor bugs to justify that?
> >We should seriously consider it given the number of bugfixes I've pulled
> >into that branch "just in case" and the fact that we haven't set a release
> >schedule for the next major release.
> 
> I agree, though I have some suggestions for additional patches to backport:
> 
> - Clinton Popetz recent one-liner loop fix
> 2000-01-18  Clinton Popetz  <cpopetz@cygnus.com>
>  
>         * loop.c (check_dbra_loop): When checking a loop for
>         reversability, check the source of any stores to ensure they
>         don't depend on an initial value.                                                                                              

Actually, this one was never approved for the mainline; I think it was
missing a CC to gcc-patches, as I can't find it in the archives.
The patch is at:

	http://gcc.gnu.org/ml/gcc-bugs/2000-01/msg00463.html

and is appended here for reference.

				-Clint

===================================================================
RCS file: /cvs/gcc/egcs/gcc/loop.c,v
retrieving revision 1.217
diff -c -2 -p -r1.217 loop.c
*** loop.c      2000/01/15 03:01:49     1.217
--- loop.c      2000/01/18 06:53:21
*************** check_dbra_loop (loop, insn_count)
*** 8035,8039 ****
                  if (v->giv_type == DEST_REG
                      && reg_mentioned_p (v->dest_reg,
!                                         XEXP (loop_store_mems, 0))
                      && loop_insn_first_p (first_loop_store_insn, v->insn))
                    reversible_mem_store = 0;
--- 8035,8039 ----
                  if (v->giv_type == DEST_REG
                      && reg_mentioned_p (v->dest_reg,
!                                        PATTERN (first_loop_store_insn)) 
                      && loop_insn_first_p (first_loop_store_insn, v->insn))
                    reversible_mem_store = 0;

Re: Problem w/PIC and C++ exceptions in 2.95 on IA-32

[Franz Sirl]

Am Don, 20 Jan 2000 schrieb Jeffrey A Law:
>In message < 200001201810.KAA13183@atrus.synopsys.com >you write:
>  > > > > 2000-01-03  Anthony Green  <green@cygnus.com>
>  > > > > 	
>  > > > > 	* config/i386/i386.md (builtin_setjmp_receiver): New pattern.
>  > > > > 	Restore the pic register if required.
>  > 
>  > On Thu, Jan 20, 2000 at 09:37:25AM -0800, David O'Brien wrote:
>  > > > Would it *PLEASE* :-)) be possible to commit it to the 2.95 branch?
>  > 
>  > Richard Henderson writes:
>  > > Done.
>  > 
>  > This only matters if we plan on issuing 2.95.3.  Do we have sufficient
>  > minor bugs to justify that?
>We should seriously consider it given the number of bugfixes I've pulled
>into that branch "just in case" and the fact that we haven't set a release
>schedule for the next major release.

I agree, though I have some suggestions for additional patches to backport:

- Clinton Popetz recent one-liner loop fix
2000-01-18  Clinton Popetz  <cpopetz@cygnus.com>
 
        * loop.c (check_dbra_loop): When checking a loop for
        reversability, check the source of any stores to ensure they
        don't depend on an initial value.                                                                                              

- the loop fix (if it is OK, it looks a bit invasive) from Jose Luu posted today

- Andrew Haley's and Bernd Schmidts reload fix for inline asms (to get rid of
the damned "may break the Linux/x86 kernel" label?)

Thu Nov  4 15:52:35 1999  Andrew Haley  <aph@cygnus.com>

        * reload1.c (reload_reg_free_for_value_p): Don't use a register
        that is in reload_reg_used.
2000-01-05  Bernd Schmidt  <bernds@cygnus.co.uk>

        * reload1.c (choose_reload_regs): When disabling a reload, also
        set reload_spill_index to -1.


- my not-yet-approved stack alignment fix for platforms with
REG_PARM_STACK_SPACE=0

- a backport of a rs6000 backend fix by Geoff (can't find the ChangeLog entry
right now)

- constructor ordering fix for rs6000
Tue Oct 12 09:45:19 1999  Jonathan Larmour  <jlarmour@cygnus.co.uk>

        * config/rs6000/eabi-ctors.c (__do_global_ctors): Run through
        __CTOR_LIST__ in opposite order, which is the correct order for sorted
        constructors.
        (__do_global_dtors): similarly for __DTOR_LIST__.


If you approve one or more of them, I'll take care to check them into the
branch. All but Jose's patch are tested on Linux/PPC (no compile regressions
for the whole RH6.1 kernel, working kernel, working glibc, etc).

Franz.

Re: Problem w/PIC and C++ exceptions in 2.95 on IA-32

[Jeffrey A Law]

  In message < 200001201810.KAA13183@atrus.synopsys.com >you write:
  > > > > 2000-01-03  Anthony Green  <green@cygnus.com>
  > > > > 	
  > > > > 	* config/i386/i386.md (builtin_setjmp_receiver): New pattern.
  > > > > 	Restore the pic register if required.
  > 
  > On Thu, Jan 20, 2000 at 09:37:25AM -0800, David O'Brien wrote:
  > > > Would it *PLEASE* :-)) be possible to commit it to the 2.95 branch?
  > 
  > Richard Henderson writes:
  > > Done.
  > 
  > This only matters if we plan on issuing 2.95.3.  Do we have sufficient
  > minor bugs to justify that?
We should seriously consider it given the number of bugfixes I've pulled
into that branch "just in case" and the fact that we haven't set a release
schedule for the next major release.

I'd like to have the vtable thunks stuff fixed (without breaking binary
compatibility), but I wouldn't consider it an absolute requirement.

jeff

RE: Problem w/PIC and C++ exceptions in 2.95 on IA-32

[Eric Dana]

I've been trying to build 2.95.2 for the Sequent (Dynix 4.4.2-4.4.6)
and it fails to build when it encounters class ios.

In class ios, any member function that is defined in the class and
then subsequently used in the class is not found in the class.
This occurs when, in stage 3, libio/builtinbuf.h is referenced.

This has occured since egcs 1.1.2 (1.1.1 and earlier built just fine
after makaing sure follwing was defined [xm-siglist.h is included
by default and is incorrect]:

/* DYNIX/ptx provides no sys_siglist.  */
#undef SYS_SIGLIST_DECLARED
#define NO_SYS_SIGLIST 1

so collect2.c builds correctly.

And gcc 2.96 snapshots segfault while building, a gcc 2.95.3 would be
of use to my company (unless a working, released version 2.96 is coming
soon).

Eric Dana
BMC Software Inc.

> -----Original Message-----
> From: gcc-owner@gcc.gnu.org [ mailto:gcc-owner@gcc.gnu.org]On Behalf Of
> Marc Espie
> Sent: Thursday, January 20, 2000 1:36 PM
> To: jbuck@synopsys.COM
> Cc: egcs@egcs.cygnus.com
> Subject: Re: Problem w/PIC and C++ exceptions in 2.95 on IA-32
>
>
> In article <867j5t$hh2$1@clipper.ens.fr> you write:
> >> > > 2000-01-03  Anthony Green  <green@cygnus.com>
> >> > >
> >> > > 	* config/i386/i386.md (builtin_setjmp_receiver):
> New pattern.
> >> > > 	Restore the pic register if required.
>
> >On Thu, Jan 20, 2000 at 09:37:25AM -0800, David O'Brien wrote:
> >> > Would it *PLEASE* :-)) be possible to commit it to the 2.95 branch?
>
> >Richard Henderson writes:
> >> Done.
>
> >This only matters if we plan on issuing 2.95.3.  Do we have sufficient
> >minor bugs to justify that?
>
> I can understand not wanting to ship `release of the day', but this
> single bug does look obnoxious enough to justify 2.95.3.
>
> Of course, this does depend heavily on what plans there are to go ahead
> and manufacture a new release in the reasonable future... so far,
> I haven't
> seen any hint that things are going to stabilize over the next
> three months.
>
> Upgrades should go like this, in my opinion: decide on a minimum interval
> between releases (say, two months).
>
> Each time the interval has elapsed, if you've got any real bugs, then you
> should crank out a new release.
>
> I don't know about you, but a bug which thoroughly breaks any real world
> C++ application on any i386 platform with sj-lj exceptions is real enough.
>

Re: Problem w/PIC and C++ exceptions in 2.95 on IA-32

[Marc Espie]

In article <867j5t$hh2$1@clipper.ens.fr> you write:
>> > > 2000-01-03  Anthony Green  <green@cygnus.com>
>> > > 	
>> > > 	* config/i386/i386.md (builtin_setjmp_receiver): New pattern.
>> > > 	Restore the pic register if required.

>On Thu, Jan 20, 2000 at 09:37:25AM -0800, David O'Brien wrote:
>> > Would it *PLEASE* :-)) be possible to commit it to the 2.95 branch?

>Richard Henderson writes:
>> Done.

>This only matters if we plan on issuing 2.95.3.  Do we have sufficient
>minor bugs to justify that?

I can understand not wanting to ship `release of the day', but this
single bug does look obnoxious enough to justify 2.95.3.

Of course, this does depend heavily on what plans there are to go ahead
and manufacture a new release in the reasonable future... so far, I haven't
seen any hint that things are going to stabilize over the next three months.

Upgrades should go like this, in my opinion: decide on a minimum interval
between releases (say, two months).

Each time the interval has elapsed, if you've got any real bugs, then you
should crank out a new release.

I don't know about you, but a bug which thoroughly breaks any real world
C++ application on any i386 platform with sj-lj exceptions is real enough.

Re: Problem w/PIC and C++ exceptions in 2.95 on IA-32

[David O'Brien]

> 	FreeBSD and others actually track the gcc-2.95 release branch of
> CVS, so it matters to people even if we do not produce a formal release.

IMHO, the GCC Project may find that more and more people do this also.

We've found with FreeBSD people that want a stable, dependable version of
the software will trace the branch the last release came from in order to
pick up minor (or major) bug fixes.  Trusting your livelihood to the HEAD
branch (of either FreeBSD or GCC) isn't wise.  :-)

-- 
-- David    (obrien@NUXI.com)

Re: Problem w/PIC and C++ exceptions in 2.95 on IA-32

[David Edelsohn]

>>>>> Joe Buck writes:

Joe> This only matters if we plan on issuing 2.95.3.  Do we have sufficient
Joe> minor bugs to justify that?

	FreeBSD and others actually track the gcc-2.95 release branch of
CVS, so it matters to people even if we do not produce a formal release.

David

Re: Problem w/PIC and C++ exceptions in 2.95 on IA-32

[Joe Buck]

> > > 2000-01-03  Anthony Green  <green@cygnus.com>
> > > 	
> > > 	* config/i386/i386.md (builtin_setjmp_receiver): New pattern.
> > > 	Restore the pic register if required.

On Thu, Jan 20, 2000 at 09:37:25AM -0800, David O'Brien wrote:
> > Would it *PLEASE* :-)) be possible to commit it to the 2.95 branch?

Richard Henderson writes:
> Done.

This only matters if we plan on issuing 2.95.3.  Do we have sufficient
minor bugs to justify that?

Re: Problem w/PIC and C++ exceptions in 2.95 on IA-32

[Richard Henderson]

On Thu, Jan 20, 2000 at 09:37:25AM -0800, David O'Brien wrote:
> > 2000-01-03  Anthony Green  <green@cygnus.com>
> > 	
> > 	* config/i386/i386.md (builtin_setjmp_receiver): New pattern.
> > 	Restore the pic register if required.
> 
> Would it *PLEASE* :-)) be possible to commit it to the 2.95 branch?

Done.


r~

Re: Problem w/PIC and C++ exceptions in 2.95 on IA-32

[David O'Brien]

On Thu, Jan 20, 2000 at 07:45:56AM -0800, Anthony Green wrote:
> > An interested FreeBSD user has analyised the bug as follows and provided
> > a patch.  The patch below also fixed the problem on OpenBSD/i386 as
> > tested by Marc Espie.
> 
> FYI - I put a similar patch into the trunk a few weeks ago:
> 
> 2000-01-03  Anthony Green  <green@cygnus.com>
> 	
> 	* config/i386/i386.md (builtin_setjmp_receiver): New pattern.
> 	Restore the pic register if required.

Would it *PLEASE* :-)) be possible to commit it to the 2.95 branch?
The way FreeBSD works, we really prefer to get changes from vendor code
rather than making our own local modifications, as that takes the files
off the Vendor branch in CVS.

-- 
-- David    (obrien@NUXI.com)

Re: Problem w/PIC and C++ exceptions in 2.95 on IA-32

[Anthony Green]

"David O'Brien" <obrien@FreeBSD.ORG> writes:

> An interested FreeBSD user has analyised the bug as follows and provided
> a patch.  The patch below also fixed the problem on OpenBSD/i386 as
> tested by Marc Espie.

FYI - I put a similar patch into the trunk a few weeks ago:

2000-01-03  Anthony Green  <green@cygnus.com>
	
	* config/i386/i386.md (builtin_setjmp_receiver): New pattern.
	Restore the pic register if required.

AG

-- 
Anthony Green                                                        Red Hat
                                                       Sunnyvale, California

Problem w/PIC and C++ exceptions in 2.95 on IA-32

[David O'Brien]

A FreeBSD user found a bug in the 2.95.2 compiler using the below
program.  When run the program dumps core.  Marc Espie has verified that
the problem exists on OpenBSD/i386 2.6 too which uses 2.95.1.  Since he
provided me with c++filtered assembler of foo.cc for gcc 2.95.2 and for
a recent snapshot that shows the problem on OpenBSD, I've attached them
below too.  

An interested FreeBSD user has analyised the bug as follows and provided
a patch.  The patch below also fixed the problem on OpenBSD/i386 as
tested by Marc Espie.

If this patch is deamed Ok, can it be commited to the 2.95 branch?  The
BSD's track the relase branch and it is very much easier on the CVS
repository to fix problems as vendor imports rather than local changes.

----- Forwarded message from "Alexander N. Kabaev" <ak03@gte.com> -----
The problem is that default builtin_setjmp implementation does not
restore any registers except for stack pointers when doing nonlocal jump.
This means, that every platform, that needs to store/restore some other
state between jumps, has to provide appropriate definitions for
builtin_setjmp_setup and builtin_setjmp_receiver RTL expansions.

Every plaftorm which needs to do some additional processing at setjmp
receive point, such as restoring additional information previously saved
by builtin_setjmp_setup, can provide definition for
builtin_setjmp_receiver RTL expansion. That is exactly what I do in a
patch.  The i386 code compiled with -fpic flag requires the value of PIC
register (EBX) to be restored in order to function properly. I do not
provide expansion for builtin_setjmp_setup because GCC documentation
explicitly states that values should be recalculated if possibe, rather
than stored in setjmp buffer and proper value for EBX can easlity be
determined from the current EIP contents.

Index: config/i386/i386.md
===================================================================
RCS file: /home/ncvs/src/contrib/gcc/config/i386/i386.md,v
retrieving revision 1.5
diff -u -r1.5 i386.md
--- config/i386/i386.md 1999/11/15 04:28:55     1.5
+++ config/i386/i386.md 2000/01/16 04:21:02
@@ -8195,3 +8195,13 @@
   load_pic_register (1);
   DONE;
 }")
+
+(define_expand "builtin_setjmp_receiver"
+  [(label_ref (match_operand 0 "" ""))]
+  "flag_pic"
+  "
+{
+  load_pic_register (1);
+  DONE;
+}")
+
----- End forwarded message -----

=====  old.s  =====

	.file	"foo.cc"
gcc2_compiled.:
___gnu_compiled_cplusplus:
.text
LC0:
	.ascii "Bax thowing...\0"
LC1:
	.ascii "in baz\12\0"
LC2:
	.ascii "baz should not be here.\12\0"
	.align 2,0x90
.globl Baz(void)
	.type	Baz(void) , @function
Baz(void):
	pushl %ebp
	movl %esp,%ebp
	subl $16,%esp
	pushl %esi
	pushl %ebx
	call L10
L10:
	popl %ebx
	addl $__GLOBAL_OFFSET_TABLE_+[.-L10],%ebx
	leal LC0@GOTOFF(%ebx),%esi
	addl $-12,%esp
	leal LC1@GOTOFF(%ebx),%eax
	pushl %eax
	call _printf@PLT
	addl $-4,%esp
	pushl $0
	call ___tfPc@PLT
	pushl %eax
	pushl %esi
	call ___cp_push_exception@PLT
	call ___sjthrow@PLT
	.size	Baz(void) , . - Baz(void)
LC3:
	.ascii "foo caught %s\12\0"
	.align 2,0x90
.globl Foo(void)
	.type	Foo(void) , @function
Foo(void):
	pushl %ebp
	movl %esp,%ebp
	subl $92,%esp
	pushl %edi
	pushl %esi
	pushl %ebx
	call L32
L32:
	popl %ebx
	addl $__GLOBAL_OFFSET_TABLE_+[.-L32],%ebx
	call ___get_eh_context@PLT
	movl %eax,-80(%ebp)
	movl %eax,%edx
	addl $4,%edx
	movl 4(%eax),%eax
	movl %eax,-24(%ebp)
	movl $0,-20(%ebp)
	leal -16(%ebp),%eax
	movl %ebp,-16(%ebp)
	leal L15@GOTOFF(%ebx),%ecx
	movl %ecx,4(%eax)
	movl %esp,8(%eax)
	jmp L14
	.align 2,0x90
L15:
	jmp L29
	.align 2,0x90
L14:
	leal -24(%ebp),%eax
	movl %eax,(%edx)
	call Baz(void)@PLT
	movl -80(%ebp),%edx
	movl 4(%edx),%eax
	movl (%eax),%eax
	movl %eax,4(%edx)
	jmp L27
	.align 2,0x90
L29:
L12:
	addl $-12,%esp
	pushl ___tfPc@GOT(%ebx)
	call ___eh_rtime_match@PLT
	addl $16,%esp
	testl %eax,%eax
	je L17
	call ___start_cp_handler@PLT
	movl %eax,-76(%ebp)
	movl -80(%ebp),%edx
	addl $4,%edx
	movl -80(%ebp),%ecx
	movl 4(%ecx),%eax
	movl %eax,-48(%ebp)
	movl $0,-44(%ebp)
	leal -40(%ebp),%eax
	movl %ebp,-40(%ebp)
	leal L21@GOTOFF(%ebx),%ecx
	movl %ecx,4(%eax)
	movl %esp,8(%eax)
	jmp L20
	.align 2,0x90
L21:
	jmp L30
	.align 2,0x90
L20:
	leal -48(%ebp),%eax
	movl %eax,(%edx)
	addl $-8,%esp
	movl -76(%ebp),%edx
	pushl 8(%edx)
	leal LC3@GOTOFF(%ebx),%eax
	pushl %eax
	call _printf@PLT
	movl -80(%ebp),%ecx
	movl 4(%ecx),%eax
	movl (%eax),%eax
	movl %eax,4(%ecx)
	addl $16,%esp
	addl $-12,%esp
	movl -76(%ebp),%eax
	pushl %eax
	call ___cp_pop_exception@PLT
	jmp L27
	.align 2,0x90
L17:
	call ___sjthrow@PLT
	.align 2,0x90
L30:
L18:
	movl -80(%ebp),%edx
	addl $4,%edx
	movl -80(%ebp),%ecx
	movl 4(%ecx),%eax
	movl %eax,-72(%ebp)
	movl $0,-68(%ebp)
	leal -64(%ebp),%eax
	movl %ebp,-64(%ebp)
	leal L25@GOTOFF(%ebx),%ecx
	movl %ecx,4(%eax)
	movl %esp,8(%eax)
	jmp L24
	.align 2,0x90
L25:
	jmp L31
	.align 2,0x90
L24:
	leal -72(%ebp),%eax
	movl %eax,(%edx)
	addl $-12,%esp
	movl -76(%ebp),%edx
	pushl %edx
	call ___cp_pop_exception@PLT
	movl -80(%ebp),%ecx
	movl 4(%ecx),%eax
	movl (%eax),%eax
	movl %eax,4(%ecx)
	addl $16,%esp
	call ___sjthrow@PLT
	.align 2,0x90
L31:
L22:
	call ___terminate@PLT
	.align 2,0x90
L27:
	leal -104(%ebp),%esp
	popl %ebx
	popl %esi
	popl %edi
	leave
	ret
	.size	Foo(void) , . - Foo(void)
.comm ___tiPc,12
LC4:
	.ascii "Pc\0"
	.align 2,0x90
	.weak	___tfPc
	.type	___tfPc , @function
___tfPc:
	pushl %ebp
	movl %esp,%ebp
	subl $16,%esp
	pushl %esi
	pushl %ebx
	call L37
L37:
	popl %ebx
	addl $__GLOBAL_OFFSET_TABLE_+[.-L37],%ebx
	movl ___tiPc@GOT(%ebx),%esi
	cmpl $0,(%esi)
	jne L34
	call char type_info function@PLT
	addl $-4,%esp
	pushl char type_info node@GOT(%ebx)
	leal LC4@GOTOFF(%ebx),%eax
	pushl %eax
	pushl %esi
	call ___rtti_ptr@PLT
L34:
	movl %esi,%eax
	leal -24(%ebp),%esp
	popl %ebx
	popl %esi
	leave
	ret
	.size	___tfPc , . - ___tfPc


=====  new.s  =====

	.file	"foo.cc"
	.version	"01.01"
gcc2_compiled.:
___gnu_compiled_cplusplus:
.text
LC0:
	.ascii "Bax thowing...\0"
LC1:
	.ascii "in baz\12\0"
LC2:
	.ascii "baz should not be here.\12\0"
	.align 2,0x90
.globl Baz(void)
	.type	Baz(void) , @function
Baz(void):
	pushl	%ebp
	movl	%esp, %ebp
	subl	$16, %esp
	pushl	%esi
	pushl	%ebx
	call	L9
L9:
	popl	%ebx
	addl	$__GLOBAL_OFFSET_TABLE_+[.-L9], %ebx
	leal	LC1@GOTOFF(%ebx), %eax
	subl	$12, %esp
	leal	LC0@GOTOFF(%ebx), %esi
	pushl	%eax
	call	_printf@PLT
	addl	$16, %esp
	subl	$4, %esp
	pushl	$0
	call	___tfPc@PLT
	pushl	%eax
	pushl	%esi
	call	___cp_push_exception@PLT
	addl	$16, %esp
	call	___sjthrow@PLT
	.size	Baz(void) , . - Baz(void)
LC3:
	.ascii "foo caught %s\12\0"
	.align 2,0x90
.globl Foo(void)
	.type	Foo(void) , @function
Foo(void):
	pushl	%ebp
	movl	%esp, %ebp
	subl	$92, %esp
	pushl	%edi
	pushl	%esi
	pushl	%ebx
	call	L27
L27:
	popl	%ebx
	addl	$__GLOBAL_OFFSET_TABLE_+[.-L27], %ebx
	call	___get_eh_context@PLT
	movl	%eax, -64(%ebp)
	movl	%eax, -72(%ebp)
	movl	%eax, %ecx
	movl	%eax, %edx
	movl	4(%edx), %eax
	movl	%eax, -20(%ebp)
	leal	-12(%ebp), %edx
	leal	L13@GOTOFF(%ebx), %eax
	movl	$0, -16(%ebp)
	movl	%ebp, -12(%ebp)
	addl	$4, %ecx
	movl	%eax, 4(%edx)
	movl	%esp, 8(%edx)
	jmp	L12
	.align 2,0x90
L13:
	call	L14
L14:
	popl	%ebx
	addl	$__GLOBAL_OFFSET_TABLE_+[.-L14], %ebx
	jmp	L11
	.align 2,0x90
L12:
	leal	-20(%ebp), %eax
	movl	%eax, (%ecx)
	call	Baz(void)@PLT
	movl	-72(%ebp), %edx
	movl	4(%edx), %eax
	movl	(%eax), %eax
	movl	%eax, 4(%edx)
	jmp	L26
	.align 2,0x90
L21:
	call	___terminate@PLT
	.align 2,0x90
L17:
	movl	-72(%ebp), %edx
	movl	4(%edx), %eax
	movl	-64(%ebp), %ecx
	movl	%eax, -60(%ebp)
	leal	-52(%ebp), %edx
	leal	L23@GOTOFF(%ebx), %eax
	movl	$0, -56(%ebp)
	movl	%ebp, -52(%ebp)
	addl	$4, %ecx
	movl	%eax, 4(%edx)
	movl	%esp, 8(%edx)
	jmp	L22
	.align 2,0x90
L23:
	call	L24
L24:
	popl	%ebx
	addl	$__GLOBAL_OFFSET_TABLE_+[.-L24], %ebx
	jmp	L21
	.align 2,0x90
L22:
	leal	-60(%ebp), %eax
	movl	%eax, (%ecx)
	subl	$12, %esp
	pushl	-68(%ebp)
	call	___cp_pop_exception@PLT
	movl	-72(%ebp), %edx
	movl	4(%edx), %eax
	movl	(%eax), %eax
	movl	%eax, 4(%edx)
	addl	$16, %esp
	call	___sjthrow@PLT
	.align 2,0x90
L11:
	subl	$12, %esp
	pushl	___tfPc@GOT(%ebx)
	call	___eh_rtime_match@PLT
	addl	$16, %esp
	testl	%eax, %eax
	je	L16
	call	___start_cp_handler@PLT
	movl	%eax, -68(%ebp)
	movl	-64(%ebp), %ecx
	movl	-72(%ebp), %edx
	movl	4(%edx), %eax
	movl	%eax, -40(%ebp)
	leal	-32(%ebp), %edx
	leal	L19@GOTOFF(%ebx), %eax
	movl	$0, -36(%ebp)
	movl	%ebp, -32(%ebp)
	addl	$4, %ecx
	movl	%eax, 4(%edx)
	movl	%esp, 8(%edx)
	jmp	L18
	.align 2,0x90
L19:
	call	L20
L20:
	popl	%ebx
	addl	$__GLOBAL_OFFSET_TABLE_+[.-L20], %ebx
	jmp	L17
	.align 2,0x90
L18:
	leal	-40(%ebp), %eax
	movl	%eax, (%ecx)
	subl	$8, %esp
	movl	-68(%ebp), %eax
	pushl	8(%eax)
	leal	LC3@GOTOFF(%ebx), %eax
	pushl	%eax
	call	_printf@PLT
	movl	-72(%ebp), %edx
	movl	4(%edx), %eax
	movl	(%eax), %eax
	addl	$16, %esp
	movl	%eax, 4(%edx)
	subl	$12, %esp
	pushl	-68(%ebp)
	call	___cp_pop_exception@PLT
	jmp	L26
	.align 2,0x90
L16:
	call	___sjthrow@PLT
	.align 2,0x90
L26:
	leal	-104(%ebp), %esp
	popl	%ebx
	popl	%esi
	popl	%edi
	leave
	ret
	.size	Foo(void) , . - Foo(void)
.comm ___tiPc,12
LC4:
	.ascii "Pc\0"
	.align 2,0x90
	.weak	___tfPc
	.type	___tfPc , @function
___tfPc:
	pushl	%ebp
	movl	%esp, %ebp
	subl	$16, %esp
	pushl	%esi
	pushl	%ebx
	call	L31
L31:
	popl	%ebx
	addl	$__GLOBAL_OFFSET_TABLE_+[.-L31], %ebx
	movl	___tiPc@GOT(%ebx), %esi
	movl	(%esi), %eax
	testl	%eax, %eax
	jne	L29
	call	char type_info function@PLT
	subl	$4, %esp
	pushl	char type_info node@GOT(%ebx)
	leal	LC4@GOTOFF(%ebx), %eax
	pushl	%eax
	pushl	%esi
	call	___rtti_ptr@PLT
L29:
	leal	-24(%ebp), %esp
	popl	%ebx
	movl	%esi, %eax
	popl	%esi
	leave
	ret
	.size	___tfPc , . - ___tfPc



===== program showing the bug =====

# This is a shell archive.  Save it in a file, remove anything before
# this line, and then unpack it by entering "sh file".  Note, it may
# create directories; files and directories will be owned by you and
# have default permissions.
#
# This archive contains:
#
#       Makefile
#       foo.cc
#       main.cc
#
echo x - Makefile
sed 's/^X//' >Makefile << 'END-of-Makefile'
XCXX=g++
XLD=ld
XCXXFLAGS=-g -fpic -fexceptions
X
Xall: arf
X
Xarf: main.o foo.so
X       ${CXX} -o arf main.o foo.so
X
X
Xfoo.so: foo.o
X       ${LD} -Bshareable -o foo.so foo.o
X
Xclean:
X       rm -f arf *.o *.so
END-of-Makefile
echo x - foo.cc
sed 's/^X//' >foo.cc << 'END-of-foo.cc'
X#include <stdio.h>
X
Xint Foo ();
X
Xint Baz ()
X{
X    char *msg = "Bax thowing..."; 
X    printf ("in baz\n");
X    throw msg;
X    printf ("baz should not be here.\n");
X}
X
X
Xint Foo ()
X{
X    try {
X        Baz ();
X    } catch (char *msg) {
X        printf ("foo caught %s\n", msg);
X    }
X}
END-of-foo.cc
echo x - main.cc
sed 's/^X//' >main.cc << 'END-of-main.cc'
X#include <stdio.h>
X
Xint Foo ();
X
Xint
Xmain ()
X{
X    try {
X        printf ("calling foo\n");
X        Foo ();
X        printf ("returned from foo\n");
X    } catch (char *msg) {
X        printf ("exception from foo: %s\n", msg);
X    } catch (...) {
X        printf ("unknown exception\n");
X    }
X}
END-of-main.cc
exit