From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 89177 invoked by alias); 6 Jul 2015 16:18:22 -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 89161 invoked by uid 89); 6 Jul 2015 16:18:21 -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_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: relay1.mentorg.com Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 06 Jul 2015 16:18:20 +0000 Received: from svr-orw-fem-06.mgc.mentorg.com ([147.34.97.120]) by relay1.mentorg.com with esmtp id 1ZC961-0001WU-0L from Luis_Gustavo@mentor.com ; Mon, 06 Jul 2015 09:18:17 -0700 Received: from [172.30.7.214] (147.34.91.1) by SVR-ORW-FEM-06.mgc.mentorg.com (147.34.97.120) with Microsoft SMTP Server id 14.3.224.2; Mon, 6 Jul 2015 09:18:16 -0700 Message-ID: <559AAA46.3010607@codesourcery.com> Date: Mon, 06 Jul 2015 16:18:00 -0000 From: Luis Machado Reply-To: Luis Machado User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Pedro Alves , Subject: Re: [PATCH] Fix problems with finishing a dummy function call on simulators. References: <1433862056-18237-1-git-send-email-lgustavo@codesourcery.com> <55772797.802@redhat.com> <55805F52.20805@codesourcery.com> <55816AD5.6020605@redhat.com> <55817569.7060704@codesourcery.com> <5581798B.5080207@redhat.com> <5581D5A9.3070706@codesourcery.com> <559A998E.6010500@redhat.com> <559A9FCE.5070908@codesourcery.com> <559AA992.2020004@redhat.com> In-Reply-To: <559AA992.2020004@redhat.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2015-07/txt/msg00127.txt.bz2 On 07/06/2015 01:15 PM, Pedro Alves wrote: > On 07/06/2015 04:33 PM, Luis Machado wrote: > >> I'll take a look at it. I suppose this will block the branching? > > I think so, or at least the release. Broken infcalls seems > pretty nasty. > Indeed. >> Then again, simply reverting this will still have bad results with some >> simulators. > > True. Might be the fix is simple though. I'm seeing this: > > (gdb) PASS: gdb.base/shlib-call.exp: step out of shr2 to main (stopped in shr2 epilogue) > step > main () at /home/pedro/gdb/mygit/build/../src/gdb/testsuite/gdb.base/shmain.c:37 > 37 g = mainshr1(g); > (gdb) PASS: gdb.base/shlib-call.exp: step out of shr2 epilogue to main > print mainshr1(1) > > Program received signal SIGSEGV, Segmentation fault. > mainshr1 (g=1) at /home/pedro/gdb/mygit/build/../src/gdb/testsuite/gdb.base/shmain.c:29 > 29 } > The program being debugged was signaled while in a function called from GDB. > GDB remains in the frame where the signal was received. > To change this behavior use "set unwindonsignal on". > Evaluation of the expression containing the function > (mainshr1) will be abandoned. > When the function is done executing, GDB will silently stop. > (gdb) FAIL: gdb.base/shlib-call.exp: print mainshr1(1) > step > That's what i see too. > The SIGSEGV look scary until one remembers that the dummy breakpoints > are placed on the stack, which is non-executable. gdb translates those > SIGSEGVs back to SIGTRAPs, provided it knows there's a breakpoint at that > address. > > Looking a bit at breakpoint.c, I notice that a few ->permanent > checks seem to have been left behind, and as result we don't actually > remove from the target the breakpoints that were placed on top of the > permanent breakpoints? > > This seems to fix the FAILs here, but I didn't run full regression > testing. Could you take this, test it on qemu, and and finish it off? > Yes, of course. Thanks for having a go at it. Luis