From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27191 invoked by alias); 22 May 2006 13:56:28 -0000 Received: (qmail 27161 invoked by alias); 22 May 2006 13:56:21 -0000 Date: Mon, 22 May 2006 13:56:00 -0000 Message-ID: <20060522135621.27160.qmail@sourceware.org> From: "drow at sources dot redhat dot com" To: glibc-bugs@sources.redhat.com In-Reply-To: <20060521225027.2682.jsm28@gcc.gnu.org> References: <20060521225027.2682.jsm28@gcc.gnu.org> Reply-To: sourceware-bugzilla@sourceware.org Subject: [Bug ports/2682] On ARM EABI, exit should be marked EXIDX_CANTUNWIND X-Bugzilla-Reason: CC Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Post: List-Help: , Sender: glibc-bugs-owner@sourceware.org X-SW-Source: 2006-05/txt/msg00126.txt.bz2 List-Id: ------- Additional Comments From drow at sources dot redhat dot com 2006-05-22 13:56 ------- Subject: Re: On ARM EABI, exit should be marked EXIDX_CANTUNWIND On Mon, May 22, 2006 at 11:33:55AM -0000, jsm28 at gcc dot gnu dot org wrote: > Yes, it's a general C++ requirement from 18.3 [lib.support.start.term] paragraph 5. > > If on a given platform you can tell that there isn't unwind information for the > stack frame for exit, then the unwinding will stop there; it's a peculiarity of > ARM unwind information that you can't tell that and need unwind information all > the way up the stack until explicitly marked to stop unwinding. I don't know > how or whether this (avoiding unwinding through exit) works on IA64 where > everything has unwind information by default. x86-64 also produces unwind tables by default; and my system libc has one for exit. Here's a modified testcase: #include extern "C" int puts(const char *); struct S { int i; S() : i(0) { } ~S() { puts("dtor"); throw "s"; // no handler anywhere } }; S xo; int main(int argc, char *argv[]) { puts("main"); try { exit (0); } catch (...) { puts ("caught"); abort (); } } It generates: #0 0x00002aaaf66e8770 in std::terminate () from /usr/lib/libstdc++.so.6 #1 0x00002aaaf66e886a in __cxa_throw () from /usr/lib/libstdc++.so.6 #2 0x00000000004007b8 in ~S (this=0x500d54) at exit-exc2.cc:12 #3 0x0000000000400712 in __tcf_0 () at exit-exc2.cc:16 #4 0x00002aaaf6af257d in exit () from /lib/libc.so.6 #5 0x00000000004006fb in main (argc=1, argv=0x7fffb4593918) at exit-exc2.cc:22 ~S has unwind info. __tcf_0 has unwind info. exit has unwind info. Yet somehow, terminate gets called anyway. I do not have a debuggable libgcc handy; I have not yet managed to work out why this happens. There's nothing obviously special in exit to account for this. As far as I can tell it ought to have no 'L' augmentation, and thus no LSDA, and thus fall through... ahh! 000000b0 0000002c 000000b4 FDE cie=00000000 pc=00400878..00400890 Augmentation data: 00 00 00 00 00 00 00 00 That is an empty augmentation entry for __tcf_0, which causes __cxa_throw to call terminate. You might want to check what the ARM compiler and runtime do for this case, for compatibility, but it looks to me as if the g++-generated stubs which call destructors ought to be marked .cantunwind if anything should. // If ip is not present in the table, call terminate. This is for // a destructor inside a cleanup, or a library routine the compiler // was not expecting to throw. found_type = found_terminate; goto do_something; There has to be an unwind entry for these functions anyway, or we wouldn't have a hope of reaching exit, so I hope ARM didn't try to save space by consolidating the can't unwind marker into exit. -- http://sourceware.org/bugzilla/show_bug.cgi?id=2682 ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.