From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 1514B3858C74 for ; Mon, 15 Aug 2022 11:10:48 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 1514B3858C74 Received: from mail-wm1-f69.google.com (mail-wm1-f69.google.com [209.85.128.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-556-AFYtZMxhMqS3zP-0LrIXxA-1; Mon, 15 Aug 2022 07:10:46 -0400 X-MC-Unique: AFYtZMxhMqS3zP-0LrIXxA-1 Received: by mail-wm1-f69.google.com with SMTP id b4-20020a05600c4e0400b003a5a96f1756so8572540wmq.0 for ; Mon, 15 Aug 2022 04:10:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:message-id:date:references:in-reply-to:subject:to:from :x-gm-message-state:from:to:cc; bh=nzd8N4wOJPEpqIy/ilckOnnFv2cOD0ljaEJYuashNsI=; b=upVqoXCUj8v5M27Q9Ln9KraBw2IdEQKC4PWe6U2Eu2+pOUUU1BAuOq7/Znq+1FWsUx CH136TuLQphabasqfhcNmCxgJFyLnRsav5JwwDLv/7lzedqSEg9HCpsWop41kb1bISWu jCNSZNemzAXODKLZW0EtCiEo5+0WeHWxj8090lLSiQpfyQH9J8nSlx88ZQjQ2DnIpwtU 5e8uwzNzbyabCXRoMOYZCbMsaYqfW3YDe7JSTRTqA9jmxnrRxACA1phW+c95XWGxePX7 EOka1X8lpYYENiOA0nH2fuZYVjwxglkig/VRan56i6IA0vyih9c03ajwC6qAof9IFx8r 2lFA== X-Gm-Message-State: ACgBeo3mJAvekIa6a8gl/kYUMIf11ihF3w4/RMI4+nuuvsp48eVSbeIu uMFTWIlz+vipEDNp1YtFvXSPj5ym33Vb6iYkoqSWuBfzWrxLiDFyXrRfRsnGVx6D8iiZw9JKOUc pMo4rYGunXP8= X-Received: by 2002:a05:600c:a199:b0:3a5:dddf:ac6d with SMTP id id25-20020a05600ca19900b003a5dddfac6dmr6220850wmb.44.1660561845588; Mon, 15 Aug 2022 04:10:45 -0700 (PDT) X-Google-Smtp-Source: AA6agR4/N45q8dJ2KPOnDoDj0FVGoDaPkB8sxQC3OTp0iv/eKkMcSP8evIZoYHPemL52BPxkEKpiVQ== X-Received: by 2002:a05:600c:a199:b0:3a5:dddf:ac6d with SMTP id id25-20020a05600ca19900b003a5dddfac6dmr6220844wmb.44.1660561845429; Mon, 15 Aug 2022 04:10:45 -0700 (PDT) Received: from localhost (15.72.115.87.dyn.plus.net. [87.115.72.15]) by smtp.gmail.com with ESMTPSA id g14-20020adff3ce000000b0022069ccb6a1sm6990669wrp.94.2022.08.15.04.10.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 15 Aug 2022 04:10:45 -0700 (PDT) From: Andrew Burgess To: Tom Kacvinsky , gdb@sourceware.org Subject: Re: "catch throw" vs. "b __cxa_throw" In-Reply-To: References: Date: Mon, 15 Aug 2022 12:10:44 +0100 Message-ID: <87mtc5zrrf.fsf@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_BARRACUDACENTRAL, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gdb@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2022 11:10:49 -0000 Tom Kacvinsky via Gdb writes: > We happened to notice that with gdb 7.6.1, "catch throw" caught an exception > (a logic_error exception from initializing a std::string with nullptr). > However, with > GDB 11.1 and 12.1 (I have not tested earlier versions than that), we did > not break > on the exception when using "catch throw". However, I was able to break > when > I used "b __cxa_throw" > > I looked in sourceware's bugzilla for a report on this, but I didn't see > anything. > I also perused the code and from what I could gather, "catch throw" > basically > mapped to setting a breakpoint on __cxa_throw. I did not figure out the > logic > for "catch throw" in the GDB 12.1 source. > > What is really odd is that "catch throw" works fine for some small examples, > but the use case I have where it is not working is our full blown project > (a mix > of C, C++ and Ada) and I wouldn't know where to begin constructing an MRE. > > Any ideas as to what is going on with this? No clue what's going wrong here, but you could use 'maint info breakpoints' to discover the exact address where the 'catch throw' has placed a breakpoint. >From that you might be able to figure out why you're hitting your breakpoint, but not the 'catch throw' breakpoint. Thanks, Andrew