From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 64303 invoked by alias); 25 Jan 2017 13:52:57 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 64289 invoked by uid 89); 25 Jan 2017 13:52:56 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-5.1 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=DEL, uncomfortable, client_data, RETURN_MASK_ALL X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 25 Jan 2017 13:52:55 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 048873D952; Wed, 25 Jan 2017 13:52:55 +0000 (UTC) Received: from [127.0.0.1] (ovpn04.gateway.prod.ext.phx2.redhat.com [10.5.9.4]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id v0PDqoc8018711; Wed, 25 Jan 2017 08:52:54 -0500 Subject: Re: Issue with Latest GDB on AIX with GCC-6.12 To: Nitish Kumar Mishra , gdb@sourceware.org References: From: Pedro Alves Message-ID: <12a05075-3783-9d3f-1d3c-81931ea91f47@redhat.com> Date: Wed, 25 Jan 2017 13:52:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2017-01/txt/msg00046.txt.bz2 On 01/25/2017 11:12 AM, Pedro Alves wrote: > On 01/25/2017 10:54 AM, Nitish Kumar Mishra wrote: >> Hi, >> >> The latest community gdb is not working with gcc 6.12, however, it >> works expectedly fine with GCC-4.8.5 on AIX platform. > > What is gcc 6.12 ? > >> #12 0x000000010007d994 in _ZL23gdb_rl_callback_handlerPc >> (rl=0x1100e92b0 "") at event-top.c:213 > > I only saw C++ frames up to here, and the exception should > be caught here. I don't immediately see why that wouldn't > be working, though maybe it's the "noexcept"? If you remove > that, does it fix it? Maybe we need a level of indirection > here too, like in gdb_rl_callback_read_char_wrapper_noexcept > / gdb_rl_callback_read_char_wrapper. I could reproduce this on gcc119 on the compile farm (AIX 7.2), which has GCC 6.1. I tried the workaround suggested above, but that didn't work. TBC, it's perfectly valid for a noexpect function to try/catch inside as long as no exception escapes out, but, compiler bugs are not unheard-of. I also tried replacing the TRY/CATCH macros with try/catch(...) thinking that it could be something with broken type info, and the runtime somehow not figuring out that that catch should really catch the exception. Same thing, doesn't work for me. So I'm out of ideas. It looks like a toolchain/runtime bug to me. TBC, I'm not going to be looking at this further. It's very uncomfortable for me to use that machine --- I get a bit too high latency, and emacs doesn't work. I even tried to survive with vi, but then DEL/BS didn't work for me. :-P Here's what I had tried. >From 968f6a4e0744f06f011ab585930dbd4d9cf5b8d6 Mon Sep 17 00:00:00 2001 From: Pedro Alves Date: Wed, 25 Jan 2017 13:15:04 +0000 Subject: [PATCH] AIX --- gdb/event-top.c | 33 ++++++++++++++++++++++----------- 1 file changed, 22 insertions(+), 11 deletions(-) diff --git a/gdb/event-top.c b/gdb/event-top.c index ae4f704..789d419 100644 --- a/gdb/event-top.c +++ b/gdb/event-top.c @@ -196,27 +196,38 @@ gdb_rl_callback_read_char_wrapper (gdb_client_data client_data) throw_exception (gdb_expt); } -/* GDB's readline callback handler. Calls the current INPUT_HANDLER, - and propagates GDB exceptions/errors thrown from INPUT_HANDLER back - across readline. See gdb_rl_callback_read_char_wrapper. This must - be noexcept in order to avoid problems with mixing sjlj and - (sjlj-based) C++ exceptions. */ +/* Calls the current INPUT_HANDLER, and returns any GDB + exceptions/errors thrown from INPUT_HANDLER as a normal return. + See gdb_rl_callback_handler. */ -static void -gdb_rl_callback_handler (char *rl) noexcept +static struct gdb_exception +input_handler_wrapper (char *rl) { struct gdb_exception gdb_rl_expt = exception_none; struct ui *ui = current_ui; - TRY + try { ui->input_handler (rl); } - CATCH (ex, RETURN_MASK_ALL) + catch (...) { - gdb_rl_expt = ex; } - END_CATCH + + return gdb_rl_expt; +} + +/* GDB's readline callback handler. Calls the current INPUT_HANDLER, + and propagates GDB exceptions/errors thrown from INPUT_HANDLER back + across readline. See gdb_rl_callback_read_char_wrapper. This must + be noexcept in order to avoid problems with mixing sjlj and + (sjlj-based) C++ exceptions. */ + +static void +gdb_rl_callback_handler (char *rl) noexcept +{ + struct gdb_exception gdb_rl_expt + = input_handler_wrapper (rl); /* If we caught a GDB exception, longjmp out of the readline callback. There's no other way for the callback to signal to -- 2.5.5