From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 49386 invoked by alias); 9 Feb 2017 12:05:32 -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 49376 invoked by uid 89); 9 Feb 2017 12:05:31 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=2.4 required=5.0 tests=AWL,BAYES_50,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,KAM_ASCII_DIVIDERS,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 spammy=djegccgmailcom, U*dje.gcc, sk:djegcc, dje.gcc@gmail.com X-HELO: mail-yw0-f194.google.com Received: from mail-yw0-f194.google.com (HELO mail-yw0-f194.google.com) (209.85.161.194) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 09 Feb 2017 12:05:29 +0000 Received: by mail-yw0-f194.google.com with SMTP id l16so110109ywb.2 for ; Thu, 09 Feb 2017 04:05:29 -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=9uq3zN+0F8qvR1tA/guDeXjM/PNxiLGiJBfw7WP9IH0=; b=WKF68w8MH8/r3ukR3akTDNr5aCmwTPi6LuKO19EN4+6XbYiiqtAk/H4SQDpPszmBG+ ZB2SksaOJBXkHEynkpb7U+zQ7ZYkm8Lj8S7eERdzhLa5G8zx7eVkK0BbhD/pr0knI7jG A4S75wlANUxZYsSNJetrRNrTKg6MmKdJ/7FHa6cmZyYVSMdZpcIW5Epsh/uBXKbPfW4J 9WtwwIquS/PTAgoVhLSwY8DjSzMzBJXdFTBTfHUFT5vjVpgbgrkVCz6FIMXMdpT12spm vF2YVaNoq/t9AGeWHGkswc8ajV7shupZUwUlB0TNE0jWd3SpqG59oT5sWoAUSIMsja8d vOyQ== X-Gm-Message-State: AMke39kVXC2m057yK8cPSYaNyY1iUgkUWxapCskeiHclXuAFbKvNDOfOD5Aph4m9W43XTtgKbt1MzTofkmGRWA== X-Received: by 10.129.48.2 with SMTP id w2mr1785074yww.295.1486641928524; Thu, 09 Feb 2017 04:05:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.164.199 with HTTP; Thu, 9 Feb 2017 04:05:28 -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: Thu, 09 Feb 2017 12:05: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/msg00018.txt.bz2 Hi All ! Here is my findings about GCC- 4.8.5 and 6.1: GCC-4.8.5 : 32 bit :::: (a) static linking to libstdc++ -----------------> [process getting terminated (not working)] (b) dynamic linking ------------------------------> [process getting terminated (not working)] 64 bit :::: (a) static linking to libstdc++ -----------------> [working fine] (b) dynamic linking -------------------------------> [working fine] GCC-6.1: 64 bit :::: (a) static linking to libstdc++ ---------------------> [process getting terminated (not working)] (b) dynamic linking ----------------------------------> [Unable to compile (compilation error)] Above, static linking meant WITH option -static-libstdc++ -static-libgcc and dynamic meant WITHOUT those options. -------------------------------------------- Thanks, Nitish On Thu, Feb 9, 2017 at 10:21 AM, Nitish Kumar Mishra wrote: > Hi David ! > >>>GDB is linked with static libstdc++ and libgcc. >>>-static-libstdc++ -static-libgcc >>>Is your small test using those options? > > Yes, I used those static options. I am using readline library in my > test program and compiling it with gcc-6.1 > like this: > g++ -g test.c -o test -static-libstdc++ -static-libgcc > -I/opt/freeware/include -lreadline > and the binary is working fine means I am able to catch the exceptions. > >>>Can you try linking GDB and testing GDB *without* those options? > ----Today I will be working on this--- > > Thanks, > Nitish > > > On Wed, Feb 8, 2017 at 7:02 PM, David Edelsohn wrote: >> On Wed, Feb 8, 2017 at 7:06 AM, Pedro Alves wrote: >>> On 02/08/2017 06:16 AM, Nitish Kumar Mishra wrote: >>> >>>> 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. >>> >>> Eh, it sounds like _no_ exception catching works then? I just >>> confirmed now that at least on GNU/Linux, GDB does not throw any >>> exception internally during startup. This backtrace in question may >>> well not be special at all, and may be that _all_ exception catching >>> is broken. I'd try experimenting with simple things like: >>> >>> try >>> { >>> throw 1; >>> } >>> catch (...) >>> { >>> printf (....); >>> } >>> >>> right at the start of gdb's main(). Not in a separately >>> compiled test program, but really inside gdb, to avoid >>> differences in how gdb vs the test program is built. >>> >>> It could also be that this is only triggered due to >>> GDB's binary size, hence not triggered in a small program -- I >>> recall that there was some trouble with the size of some sessions >>> and the linker in the AIX 7.1 box couldn't link gdb, or something >>> like that? Maybe that's not fully/correctly sorted out. >> >> Nitish, >> >> GDB is linked with static libstdc++ and libgcc. >> >> -static-libstdc++ -static-libgcc >> >> Is your small test using those options? >> >> Can you try linking GDB and testing GDB *without* those options? >> >> Thanks, David