From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 44512 invoked by alias); 9 Jun 2015 17:51:25 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 44502 invoked by uid 89); 9 Jun 2015 17:51:24 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 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 (AES256-GCM-SHA384 encrypted) ESMTPS; Tue, 09 Jun 2015 17:51:23 +0000 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (Postfix) with ESMTPS id D46D8550BE; Tue, 9 Jun 2015 17:51:21 +0000 (UTC) Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t59HpJO3019895; Tue, 9 Jun 2015 13:51:20 -0400 Message-ID: <55772797.802@redhat.com> Date: Tue, 09 Jun 2015 17:51:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Luis Machado , gdb-patches@sourceware.org Subject: Re: [PATCH] Fix problems with finishing a dummy function call on simulators. References: <1433862056-18237-1-git-send-email-lgustavo@codesourcery.com> In-Reply-To: <1433862056-18237-1-git-send-email-lgustavo@codesourcery.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2015-06/txt/msg00138.txt.bz2 On 06/09/2015 04:00 PM, Luis Machado wrote: > This is in line with what was done by Joel's patch here: > > https://sourceware.org/ml/gdb-patches/2014-11/msg00478.html > > And it also answers Pedro's question about whether this is specific to SPARC > QEMU or not. This indeed seems to affect multiple QEMU targets and also other > simulators (proprietary). Sounds like a different issue, although related. > > I ran into this weird issue of not being able to "finish" an inferior function > call. It looks as if the program is running away, but it really is stuck > somewhere. "finish" still works fine for regular functions not called manually > by GDB. Sounds like that would fail on SPARC qemu as well. > > I tracked this failure down to GDB having both a bp_call_dummy and bp_finish in > its breakpoint list. As a result of one not being considered permanent and the > other considered permanent, GDB will not issue a Z packet to force the insertion > of that location's breakpoint, confusing the simulator that does not know how > to deal properly with these permanent breakpoints that GDB inserted beforehand. > > The attached patch fixes this, though i'm inclined to say we could probably > check if both bp_call_dummy and bp_finish are present and force the > insertion of that location's breakpoint. It isn't clear to me where exactly that > check would go or if it would be cleaner than checking that information in > the same function Joel used. > > I see no regressions on x86-64 and it fixes a bunch of failures for simulator > targets we use (MIPS and PowerPC to name two). If it happens that you "finish" from a normal function, and the finish breakpoint ends up on top of a real permanent breakpoint, then this patch will make us end up inserting a breakpoint on top of that permanent breakpoint. I don't see what's special about finish breakpoints; it's the address (dummy breakpoint location) that is special. It very much sounds like that any kind of breakpoint that is placed on top of the dummy breakpoint ends up with the same issue. E.g., if you stepi out of the called function, with a software single-step breakpoint, sounds like GDB will miss inserting the software step breakpoint because that's at the same address as the dummy breakpoint. As a data point, I assume that GDB is considering the non-permanent dummy breakpoint a duplicate of the permanent finish breakpoint and then none ends up inserted. Is that right? Not exactly sure what to do here. Maybe we should stop considering permanent and non-permanent breakpoints at the same address as duplicates. That should result in GDB inserting the non-permanent one, I think. Or we could get stop marking permanent breakpoints as always inserted, and let normal breakpoints insert on top of permanent breakpoints normally. See also: https://sourceware.org/ml/gdb-patches/2015-03/msg00174.html Thanks, Pedro Alves