From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 53701 invoked by alias); 8 Feb 2017 07:04:31 -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 53689 invoked by uid 89); 8 Feb 2017 07:04:30 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=1.7 required=5.0 tests=AWL,BAYES_50,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 spammy=Nitish, nitish, unwinder, dje.gcc@gmail.com X-HELO: mail-yw0-f178.google.com Received: from mail-yw0-f178.google.com (HELO mail-yw0-f178.google.com) (209.85.161.178) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 08 Feb 2017 07:04:20 +0000 Received: by mail-yw0-f178.google.com with SMTP id l19so80991685ywc.2 for ; Tue, 07 Feb 2017 23:04:20 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=SVK4V6TB+7pb2iIMRhpL3umFnjiby4EFKMlChNQCwGE=; b=cOEaAwEAHYb9Rpc3/R0GEEjcwCbvVdT7vPLzZQZKZi2E5jKlZOrg9O5tFbvtcS10xP o02/IagOxwRP6LTyb5BLKWZ4zmglzXq9DjbIG+gD1j3NHtsbOj30njJNtDRRQf8VRd0v O+NCedOvsp/u2qFB61zoaXHkFssHsWmuzNSc1QLDD4+RA/DtNZ/rc4K1PZ16mOPtyQII vPvgNJbAtPmUzwlSrEHSTFLcu4ETdKdq1ocny9F8MGsWkqAlU/uGc1x8qlDPULTTcV+U zH0wQy4GTMfu8xq0BQEQS43JKZf91RMojSMSpFePna+gNSIz9IPpKgxIA+AzLhroh65w 3k5w== X-Gm-Message-State: AIkVDXIGA3pylTz25Fj2JM7bCn+COQxoHus1kG6DTR5rxFepX5F38Ch4M1lfV89HzkcWoOCSiKmZkiWyz3N2tw== X-Received: by 10.129.74.137 with SMTP id x131mr13452320ywa.219.1486537458872; Tue, 07 Feb 2017 23:04:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.164.199 with HTTP; Tue, 7 Feb 2017 23:04:18 -0800 (PST) In-Reply-To: References: <21a21388-b1d9-816c-377e-d4e084cc399e@redhat.com> <331a72d9-050c-7cd7-adc2-78e5f1ed6f85@redhat.com> <57147db4-83c3-2a8f-0c74-0efc6a94e9f5@redhat.com> From: Nitish Kumar Mishra Date: Wed, 08 Feb 2017 07:04:00 -0000 Message-ID: Subject: Re: Issue with Latest GDB on AIX with GCC-6.12 To: David Edelsohn Cc: Pedro Alves , "gdb@sourceware.org" , Yao Qi Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2017-02/txt/msg00012.txt.bz2 Hi All, >>I'm assuming that we've run into a corner case, and that GDB has thrown other C++ exceptions that were caught successfully before we get to this problematic exception, during gdb startup. I.e., I don't recall whether I confirmed that a simple hello-word that does try{throw 1;}/catch(...){} manages to catch the exception correctly. If it doesn't then there's some fundamental problem with C++ exceptions in this compiler build. We tried simple try/catch program using readline library with GCC-6.1 and it is working perfectly all right. Looking forward to work on this suggestion: >> Alternatively, someone could debug the unwinder itself (libgcc?), which should also reveal why didn't the unwinder find that there's a "catch" in frame #12 in the original backtrace that catches the thrown exception. Thanks and Regards, Nitish On Wed, Feb 8, 2017 at 11:46 AM, Nitish Kumar Mishra wrote: > Hi All, >>> Yes, but I thought that there was a later comment that GCC 4.8 also > showed problems. > GCC-4.8.5 is working correctly, I have pasted the OP in earlier mail. > >>>We know the exception should be caught in frame #12. But somehow, > the run time unwinder doesn't realize this, and calls std::terminate, > meaning it can't find a matching catch for the thrown exception. > This suggests that the unwinder can't unwind some frame from the > set of frames #0 to frame #12. The suggestion was to _add_ try/catch > blocks in some frames between #0 - #12, and do some printing in the > added catch blocks. For example, wrap frame #6, i.e., the > kill_command function, by renaming it to kill_command_org > and add: > > I tried adding try/catch block earlier in throw_it and > throw_exception_cxx functions > but got no significant results. > I had tried adding try catch block in these functions: > kill_command > command_handler > command_line_handler > execute_command > throw_it > throw_exception_cxx, > but no progress. Output is exactly same as we got earlier (Other than > extra frames for new > try catch functions). None of the print statements in catch blocks for > above functions worked. > > > Thanks and Regards, > Nitish > > > On Tue, Feb 7, 2017 at 7:45 PM, David Edelsohn wrote: >> On Tue, Feb 7, 2017 at 8:56 AM, Pedro Alves wrote: >>> On 02/07/2017 01:44 PM, David Edelsohn wrote: >>>> On Tue, Feb 7, 2017 at 5:30 AM, Pedro Alves wrote: >>>> >>>>> Speaking of compilers, we know that building gdb with gcc 4.8.5 >>>>> doesn't run into this. Do we know that changed? Did, for example, >>>>> AIX switch from sjlj to dwarf-based exceptions between gcc 4.8.5 >>>>> and 6.1? Might also be useful to try to build gdb with current >>>>> gcc trunk / gcc 7. >>>> >>>> I cannot tell if some have reported that GCC 4.8.5 works correctly or not. >>> >>> The OP said it works fine on GCC 4.8.5 here: >>> >>> https://sourceware.org/ml/gdb/2017-01/msg00044.html >> >> Yes, but I thought that there was a later comment that GCC 4.8 also >> showed problems. >> >> There was a change in the encoding of data for AIX, but not a change >> to the basic EH frames or handlers. AIX did not change EH mechanisms >> and never used SJLJ -- at least not for a very long time. >> >> One test is to use shared libraries to link GDB. >> >> Another possible contribution is the AIX address space. There have >> been reports in the past of EH frames not sorted correctly and libgcc >> EH not finding exception handlers because it terminated the search >> early. >> >> Thanks, David