From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 108348 invoked by alias); 10 Feb 2017 07:22:16 -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 108338 invoked by uid 89); 10 Feb 2017 07:22:15 -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=U*dje.gcc, sk:djegcc, sk:dje.gcc, djegccgmailcom X-HELO: mail-yw0-f196.google.com Received: from mail-yw0-f196.google.com (HELO mail-yw0-f196.google.com) (209.85.161.196) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 10 Feb 2017 07:22:13 +0000 Received: by mail-yw0-f196.google.com with SMTP id v73so2007366ywg.1 for ; Thu, 09 Feb 2017 23:22:13 -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=JlRNsiZNYY/fHaqTXB4tmTqraAmZxQEHhYhepe4ULNA=; b=qZ2UdS6RvksM2bPVoHCqZZifX4y8b0mP4ebBc+tlr3YKNRKGz5SvnD1XI/bzq3PFA8 pFawkL8CuOB/noO5hW9+gzqcGsfAqGczLHo+qAakfD96p/R9SEl6eMOJ9GqaYWtIFhhQ NpVtxNH6MqGYiaLZGbcl0DhRhWh2XLOa9P0YhVsFKlB+QaTQiksJXQOcY1G880pOouLQ UT1/GQ6ilSnnXXwpEuX4q4ngQnDeOp7blhFgk45UQpl4ykQ9tq1FwJCarpBJHTMqbtmR c0nYdoFLfHn6JM8YgxnWcSbjA+XNDpxPN00DYZatjjetO1yBR9/XaWWBTknKduT+BZDY ckxQ== X-Gm-Message-State: AMke39k9U/n49/HOPFPq4+qBMSJ7hqP3zRffQiCD3WThudu64unJAmxYptzwkAh3agM/wjlsL8ToJ6yGKMLTXw== X-Received: by 10.129.48.2 with SMTP id w2mr5262396yww.295.1486711332316; Thu, 09 Feb 2017 23:22:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.164.199 with HTTP; Thu, 9 Feb 2017 23:22:11 -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: Fri, 10 Feb 2017 07:22: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/msg00024.txt.bz2 Hi All, > 3. GDB with GCC-6.1, 64 bit mode, with static options : NOT WORKING > 4. GDB with GCC-6.1, 64 bit mode, without static options : COMPILATION ERROR. > > P.S.: Static options means: -static-libstdc++ -static-libgcc >What is the compilation error? With GCC-6.1, 64 bit mode, WITHOUT static option, below is the output of the compilation error: ld: 0711-317 ERROR: Undefined symbol: ._Unwind_Resume ld: 0711-317 ERROR: Undefined symbol: .__cxa_atexit ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information. collect2: error: ld returned 8 exit status > Does GCC 4.8.5 and GCC 6.1 fail in the same manner? Neither catch the exception? Yes, by NOT WORKING, I meant, niether catching the exception and process is getting terminated. Thanks, Nitish On Thu, Feb 9, 2017 at 9:20 PM, David Edelsohn wrote: > On Thu, Feb 9, 2017 at 7:15 AM, Nitish Kumar Mishra > wrote: >> Hi all, >> While sending the previous mail the statements got broken. >> I am not sure if it is understandable. So, trying again :) >> >> 1. GDB with GCC-4.8.5, 32 bit mode, with or without static >> options : NOT WORKING. >> 2. GDB with GCC-4.8.5, 64 bit mode, with or without static >> options : WORKING FINE > > Okay. This is why I was confused about GCC 4.8.5. I don't have any > immediate intuition why 64 bit mode would have an effect on GCC. To > me this implies a subtle AIX linker issue. I have experienced AIX ld > behaving differently in 32 bit mode and 64 bit mode. > >> 3. GDB with GCC-6.1, 64 bit mode, with static options : NOT WORKING >> 4. GDB with GCC-6.1, 64 bit mode, without static options : COMPILATION ERROR. >> >> P.S.: Static options means: -static-libstdc++ -static-libgcc > > What is the compilation error? > > Does GCC 4.8.5 and GCC 6.1 fail in the same manner? Neither catch the > exception? > > GCC EH on AIX was improved (for GCC 6) to place EH tables in the > read-only section so that they could be shared and not bloat the data > section. This also changed the data encoding. But this change should > not have affected the algorithm to find an exception handler. > > If it fails for both GCC 4.8 and GCC 6.1, that implies the problem is > not a recent GCC change. > > It's possible that there is something wrong with the GCC code and it > accidentally works sometime, or it's possible that there is some bad > interaction between GCC and the AIX linker (like relocations or > ordering of symbols). > > Because of the limited GDB functionality on AIX, debugging is > difficult. We need some more information about exactly why the EH > walker is failing to find the relevant EH frame. What is wrong with > the table in the executable or in memory? > > Thanks, David