g++ Bug? use of alloca in a function prevents exception handler walkback on ppc linux

g++ Bug? use of alloca in a function prevents exception handler walkback on ppc linux

[Kevin B. Hendricks]

Hi,

Please cc any replies directly to me at: khendricks@ivey.uwo.ca

With a lot of help from Philipp Lohmann from Sun Germany, we have tracked the 
problem on ppc linux exception handling to the use of alloca in any function 
in the path back to the exception handler.

This is what causes the "pc" in throw_helper to point out into the weeds.

Is this a g++ bug?

Should dynamic allocation of stack space prevent the search back through the 
function by throw_helper?

Here is the test program and the results when run under gdb:

[kbhend@localhost kbhend]$ cat test_case.cxx
#include <malloc.h>
#include <stdio.h>
#include <string.h>

struct Exc
{
         int n;
};

void thrower()
{
         Exc aExc;
         throw aExc;
}

void caller( int n )
{
         void* pSpace = NULL;
         for( int i = 0; i < n; i++ )
         {
                 pSpace = alloca( n*(i+1) );
                 memset( pSpace, 0, n*(i+1) );
         }
         thrower();
}

int main( int argc, char** argv )
{
         try
         {
                 caller( 15 );
         }
         catch( Exc& )
         {
                 fprintf( stderr, "caught struct Exc&\n");
         }
         catch( ... )
         {
                 fprintf( stderr, "caught something\n");
         }
         return 0;
}


Note: I have compiled with -fPIC here since that is what is used for the 
openoffice bridge library but the same problem happens without -fPIC and when 
compiled at -O0 instead of -O2.  Also if you remove the alloca bits, the 
program actually catches the exception properly.

[kbhend@localhost kbhend]$ g++ -O2 -fexceptions -fPIC -o test_case 
test_case.cxx[kbhend@localhost kbhend]$ ./test_case
Aborted (core dumped)

[kbhend@localhost kbhend]$ gdb ./test_case
GNU gdb 5.0
Copyright 2000 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "powerpc-unknown-linux-gnu"...
(gdb) b main     
Breakpoint 1 at 0x100008c4
(gdb) run
Starting program: /home/kbhend/./test_case 

Breakpoint 1, 0x100008c4 in main ()
(gdb) c
Continuing.

Program received signal SIGABRT, Aborted.
0xfe4eea0 in kill () at soinit.c:59
59	soinit.c: No such file or directory.
(gdb) bt
#0  0xfe4eea0 in kill () at soinit.c:59
#1  0xfe4eb68 in raise (sig=6) at ../sysdeps/posix/raise.c:27
#2  0xfe50400 in abort () at ../sysdeps/generic/abort.c:88
#3  0xffbbd08 in __default_terminate () from /usr/lib/libstdc++-libc6.1-2.so.3
#4  0xffbbd40 in __terminate () from /usr/lib/libstdc++-libc6.1-2.so.3
#5  0xffbcb70 in throw_helper (eh=0xffefc9c, pc=0xffffffff, 
    my_udata=0x7fffef38, offset_p=0x7ffff0d8)
   from /usr/lib/libstdc++-libc6.1-2.so.3
#6  0xffbcdc8 in __throw () from /usr/lib/libstdc++-libc6.1-2.so.3
#7  0x10000820 in caller ()
#8  0x10000884 in caller ()
#9  0x100008d4 in main ()
#10 0xfe4773c in __libc_start_main (argc=1, argv=0x7ffffa94, envp=0x7ffffa9c, 
    auxvec=0x7ffffb0c, rtld_fini=0, stinfo=0x10000af4, 
    stack_on_entry=0x7fffe860) at ../sysdeps/powerpc/elf/libc-start.c:106
(gdb)


Any guidance about how to deal with this would be greatly appreciated.

Thanks,

Kevin
---
Kevin B. Hendricks, Associate Professor
Operations and Information Technology
Richard Ivey School of Business, UWO, London ON, CANADA
(519) 661-3874

Re: g++ Bug? use of alloca in a function prevents exception handler walkback on ppc linux

[Geoff Keating]

> From: "Kevin B. Hendricks" <kevin.hendricks@sympatico.ca>
> Reply-To: khendricks@ivey.uwo.ca
> Date: Thu, 14 Dec 2000 11:40:27 -0500

> With a lot of help from Philipp Lohmann from Sun Germany, we have
> tracked the problem on ppc linux exception handling to the use of
> alloca in any function in the path back to the exception handler.
> 
> This is what causes the "pc" in throw_helper to point out into the weeds.
> 
> Is this a g++ bug?

It's a libgcc bug.

> Should dynamic allocation of stack space prevent the search back through the 
> function by throw_helper?

No.

> Any guidance about how to deal with this would be greatly appreciated.

It's a known bug.  The following workaround is a temporary patch, but
it causes a performance regression for C++.  The correct fix is to
improve libgcc so that it can deal with this case.

-- 
- Geoffrey Keating <geoffk@geoffk.org>

===File ~/patches/cygnus/gcc-ehbug.patch====================
2000-12-07  Geoffrey Keating  <geoffk@redhat.com>

	* config/rs6000/rs6000.c (first_reg_to_save): Always save
	the frame pointer register in functions that can throw.
	(rs6000_emit_prologue): Save the frame pointer register
	even if it is never live.

Index: config/rs6000/rs6000.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/config/rs6000/rs6000.c,v
retrieving revision 1.156
diff -u -p -r1.156 rs6000.c
--- rs6000.c	2000/11/19 18:49:31	1.156
+++ rs6000.c	2000/12/08 01:36:02
@@ -4705,6 +4705,11 @@ first_reg_to_save ()
 	}
     }
 
+  if (first_reg == 32
+      && flag_exceptions
+      && (asynchronous_exceptions || ! current_function_is_leaf))
+    first_reg = 31;
+
   return first_reg;
 }
 
@@ -5665,7 +5670,10 @@ rs6000_emit_prologue()
 	     && ! call_used_regs[info->first_gp_reg_save+i])
 	    || (i+info->first_gp_reg_save == PIC_OFFSET_TABLE_REGNUM
 		&& (DEFAULT_ABI == ABI_V4 || DEFAULT_ABI == ABI_SOLARIS)
-		&& flag_pic == 1))
+		&& flag_pic == 1)
+	    || (i+info->first_gp_reg_save == FRAME_POINTER_REGNUM
+		&& flag_exceptions
+		&& (asynchronous_exceptions || ! current_function_is_leaf)))
 	  {
 	    rtx addr, reg, mem;
 	    reg = gen_rtx_REG (reg_mode, info->first_gp_reg_save + i);
============================================================

Re: g++ Bug? use of alloca in a function prevents exception handler walkback on ppc linux

[Franz Sirl]

On Thursday 14 December 2000 19:12, Geoff Keating wrote:
> > From: "Kevin B. Hendricks" <kevin.hendricks@sympatico.ca>
> > Reply-To: khendricks@ivey.uwo.ca
> > Date: Thu, 14 Dec 2000 11:40:27 -0500
> >
> > With a lot of help from Philipp Lohmann from Sun Germany, we have
> > tracked the problem on ppc linux exception handling to the use of
> > alloca in any function in the path back to the exception handler.
> >
> > This is what causes the "pc" in throw_helper to point out into the weeds.
> >
> > Is this a g++ bug?
>
> It's a libgcc bug.

But hard to fix?

> > Should dynamic allocation of stack space prevent the search back through
> > the function by throw_helper?
>
> No.
>
> > Any guidance about how to deal with this would be greatly appreciated.
>
> It's a known bug.  The following workaround is a temporary patch, but
> it causes a performance regression for C++.  The correct fix is to
> improve libgcc so that it can deal with this case.

Your patch is against the current mainline, but mainline compiles a correctly 
throwing binary with Kevin's testcase. Do you have another testcase or is the 
current mainline already fixed and your patch superflous now? If it is fixed, 
it must have happened recently, since the 20001106 compiler still produced a 
failing binary.

Anyway, Kevin is working with gcc-2.95.3 so I'll look into backporting your 
fix, cause I don't have time to do gcc-2.97 RPM's before xmas.

Franz.

Re: g++ Bug? use of alloca in a function prevents exception handler walkback on ppc linux

[Geoff Keating]

> From: Franz Sirl <Franz.Sirl-kernel@lauterbach.com>
> Date: Thu, 14 Dec 2000 23:31:09 +0100

> > It's a libgcc bug.
> 
> But hard to fix?

It needs some rewriting, but then lots of testing.  Not very hard, but
not easy either.

> Your patch is against the current mainline, but mainline compiles a correctly 
> throwing binary with Kevin's testcase. Do you have another testcase or is the 
> current mainline already fixed and your patch superflous now? If it is fixed, 
> it must have happened recently, since the 20001106 compiler still produced a 
> failing binary.

It worries me that this stopped failing.  It probably indicates we
lost an optimisation.  I don't believe the underlying bug was fixed.

> Anyway, Kevin is working with gcc-2.95.3 so I'll look into backporting your 
> fix, cause I don't have time to do gcc-2.97 RPM's before xmas.

Sure.  As a workaround, this is suitable for 2.95.3.

-- 
- Geoffrey Keating <geoffk@geoffk.org>

Re: g++ Bug? use of alloca in a function prevents exception handler walkback on ppc linux

[Franz Sirl]

At 01:20 2000-12-15, Geoff Keating wrote:
> > From: Franz Sirl <Franz.Sirl-kernel@lauterbach.com>
> > Date: Thu, 14 Dec 2000 23:31:09 +0100
>
> > > It's a libgcc bug.
> >
> > But hard to fix?
>
>It needs some rewriting, but then lots of testing.  Not very hard, but
>not easy either.

Hmm, do you have a testcase that is known to fail because of this bug? 
Kevin's testcase forces the frame_pointer_needed to 1 anyway, and I think 
you mean a testcase where the frame pointer gets eliminated to the stack 
pointer. Hmm, looking at older changelogs, isn't the libgcc2 infrastructure 
already there:

2000-06-26  Andrew Macleod <amacleod@cygnus.com>
             Jason Merrill <jason@redhat.com>

         * dwarf2.h (enum dwarf_call_frame_info): Add
         DW_CFA_def_cfa_expression.
         * dwarf2out.c (union dw_cfi_oprnd_struct): Add a pointer to a
         dw_loc_descr_struct entry.
         (struct cfa_loc): New structure to track a CFA location.
         (lookup_cfa): Take a cfa_loc parameter instead of a reg and an offset.
         (lookup_cfa_1): Take a cfa_loc parameter instead of a reg and an
         offset, plus handle DW_CFA_def_cfa_expression.
         (def_cfa_1): Use to be dwarf2out_def_cfa, only now it uses a
         cfa_loc record.
         (dwarf2out_def_cfa): Entry point maintained for compatability.
         (dwarf_cfi_name): Add DW_CFA_def_cfa_expression.
         (cfa_reg, cfa_offset): Replace with cfa_loc record 'cfa'.
         (cfa_store_reg, cfa_store_offset): Replace with cfa_loc 'cfa_store'.
         (initial_return_save, dwarf2out_stack_adjust): Use cfa.reg, not
         cfa_reg.
         (dwarf2out_frame_debug_expr): Use new cfa_loc records. Recognize rtl
         sequences for the new DW_CFA_def_cfa_expression record.
         (dwarf2out_frame_debug): Use new variables/fields.A
         (output_cfi): Handle DW_CFA_def_cfa_expression.
         (output_cfa_loc): New function to generate a CFI record for
         DW_CFA_def_cfa_expression.
         (get_cfa_from_loc_descr): New function to get a cfa_loc record from
         a dw_loc_descr sequeunce.
         (build_loc_descr): Build a dw_loc_descr from a cfa_loc record.
         (dwarf_stack_op_name, new_loc_descr, add_loc_descr, size_of_loc_descr,
         size_of_locs, output_loc_operands, output_loc_sequence): Move into
         unwind info section.
         * frame.h (frame_state): Add base_offset and indirect fields.
         * frame-dwarf2.c (decode_stack_op): New function to interpret a
         dw_loc_descr operation.
         (execute_cfa_insn): Add support for DW_CFA_def_cfa_expression.
         (struct frame_state): Add base offset and indirect fields.
         * libgcc2.c (next_stack_level): Support indirect loading for CFA.


Do we need even more?

> > Your patch is against the current mainline, but mainline compiles a 
> correctly
> > throwing binary with Kevin's testcase. Do you have another testcase or 
> is the
> > current mainline already fixed and your patch superflous now? If it is 
> fixed,
> > it must have happened recently, since the 20001106 compiler still 
> produced a
> > failing binary.
>
>It worries me that this stopped failing.  It probably indicates we
>lost an optimisation.  I don't believe the underlying bug was fixed.

The code is nearly the same (I compared the assembly), I believe this was a 
temporary failure and not related to the bug you are referring to. What 
makes me wonder though is the code generated for "thrower" in Kevin's 
testcase, that looks bogus. It seems to me that the code is using an 
uninitialized and unallocated stackslot for aExc, which overlays (!) with 
the register save area, r31 in this example. The bug is already in the 
initial RTL dump, which would suggest that except.c and cp/except.c have a 
bug here.

> > Anyway, Kevin is working with gcc-2.95.3 so I'll look into backporting 
> your
> > fix, cause I don't have time to do gcc-2.97 RPM's before xmas.
>
>Sure.  As a workaround, this is suitable for 2.95.3.

As this bug turned out to be a different one than you thought (?), the 
solution for gcc-2.95.3 is really simple and related to the unofficial 
DWARF EH patch used on Linux/PPC. It turns out the patch missed to call 
dwarf2out_def_cfa() after the framepointer activating "mr 31,1". Fixing 
this lets the testcase succeed.

Kevin, I'll upload new RPM's as soon as the build finished.

Franz.

Re: g++ Bug? use of alloca in a function prevents exception handler walkback on ppc linux

[Kevin B. Hendricks]

Hi Franz,

> The code is nearly the same (I compared the assembly), I believe this was a 
> temporary failure and not related to the bug you are referring to. What 
> makes me wonder though is the code generated for "thrower" in Kevin's 
> testcase, that looks bogus. It seems to me that the code is using an 
> uninitialized and unallocated stackslot for aExc, which overlays (!) with 
> the register save area, r31 in this example. The bug is already in the 
> initial RTL dump, which would suggest that except.c and cp/except.c have a 
> bug here.
> 
> > > Anyway, Kevin is working with gcc-2.95.3 so I'll look into backporting 
> > your
> > > fix, cause I don't have time to do gcc-2.97 RPM's before xmas.
> >
> >Sure.  As a workaround, this is suitable for 2.95.3.
> 
> As this bug turned out to be a different one than you thought (?), the 
> solution for gcc-2.95.3 is really simple and related to the unofficial 
> DWARF EH patch used on Linux/PPC. It turns out the patch missed to call 
> dwarf2out_def_cfa() after the framepointer activating "mr 31,1". Fixing 
> this lets the testcase succeed.
> 
> Kevin, I'll upload new RPM's as soon as the build finished.

Great, I have a much more complex testcase (the actual bridges code in 
openoffice) which actually works if I change from alloca to malloc based 
versions.  I will convert it back to alloca and test the new compiler.

Thanks!

Kevin


---
Kevin B. Hendricks, Associate Professor
Operations and Information Technology
Richard Ivey School of Business, UWO, London ON, CANADA
(519) 661-3874

Re: g++ Bug? use of alloca in a function prevents exception handler walkback on ppc linux

[Jason Merrill]

>>>>> "Geoff" == Geoff Keating <geoffk@geoffk.org> writes:

> +      && flag_exceptions
> +      && (asynchronous_exceptions || ! current_function_is_leaf))

Or you could use !current_function_nothrow.

Jason

Re: g++ Bug? use of alloca in a function prevents exception handler walkback on ppc linux

[Mike Stump]

> From: "Kevin B. Hendricks" <kevin.hendricks@sympatico.ca>
> Date: Thu, 14 Dec 2000 11:40:27 -0500
> To: gcc@gcc.gnu.org
> Cc: dje@watson.ibm.com, geoffk@geoffk.org, Franz.Sirl-kernel@lauterbach.com

> With a lot of help from Philipp Lohmann from Sun Germany, we have
> tracked the problem on ppc linux exception handling to the use of
> alloca in any function in the path back to the exception handler.

Ok.

> Is this a g++ bug?

Yes, I suspect so.  Or, more properly, this seems to be a bug in the
DWARF2 EH bits for the PowerPC.  I tried this on x86 linux, using a
top of tree compiler, and it worked fine, so I believe that the
machine independent code might be fine.

> Should dynamic allocation of stack space prevent the search back
> through the function by throw_helper?

Nope.

> Any guidance about how to deal with this would be greatly appreciated.

If you want to fix it, check out the DWARF2 bits in the rs6000 port.
Jason might be able to give better advice in this area, as he is more
familiar with these bits.  Compile up the libgcc2 bits with debugging
turned on, and then step though it and watch how the EH runtime walks
the frame.  Understand every addition and every fetch it does.  Watch
the registers being restored, and from where they come from, and
ensure that is where the generated code put them.

Oh, I assume that you've already tried the top of the tree.  If not,
please give it a try and see if it works.