From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 979 invoked by alias); 25 Aug 2015 22:41:45 -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 965 invoked by uid 89); 25 Aug 2015 22:41:44 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,FROM_12LTRDOM,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; Tue, 25 Aug 2015 22:41:43 +0000 Received: from svr-orw-fem-05.mgc.mentorg.com ([147.34.97.43]) by relay1.mentorg.com with esmtp id 1ZUMuS-0004E8-Bp from Don_Breazeal@mentor.com for gdb-patches@sourceware.org; Tue, 25 Aug 2015 15:41:40 -0700 Received: from build4-lucid-cs (147.34.91.1) by svr-orw-fem-05.mgc.mentorg.com (147.34.97.43) with Microsoft SMTP Server id 14.3.224.2; Tue, 25 Aug 2015 15:41:39 -0700 Received: by build4-lucid-cs (Postfix, from userid 1905) id 8EB9B40FB6; Tue, 25 Aug 2015 15:41:39 -0700 (PDT) From: Don Breazeal To: Subject: [PATCH 0/2] Native follow-exec-mode cleanup Date: Tue, 25 Aug 2015 22:41:00 -0000 Message-ID: <1440542496-14988-1-git-send-email-donb@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain X-IsSubscribed: yes X-SW-Source: 2015-08/txt/msg00744.txt.bz2 This patchset implements a test for follow-exec-mode and addresses several failures in the native implementation of follow-exec-mode. I submitted a patchset several weeks ago that purported to implement exec events and follow-exec-mode for extended-remote Linux targets (https://sourceware.org/ml/gdb-patches/2015-07/msg00923.html). That had an issue with one of the follow-exec-mode cases. As part of working on that I implemented a test for follow-exec-mode (gdb.base/foll-exec.exp doesn't test follow-exec-mode, it only tests exec event handling). When I ran the test against the native x64 Linux debugger, I found several failures. There was no point in submitting updates to the extended-remote exec event patchset until these issues had been dealt with. Issues: --------- First, if there is a breakpoint in the original program that doesn't map to a location in the execd program (e.g. on a line number in a file that doesn't exist in the execd program), GDB gets "Error in re-setting breakpoint". After attempting a fix, I concluded that this error is benign, and actually informative. It lets the user know that a breakpoint did not survive across the exec. So I left this alone. Make sense? Second, with follow-exec-mode == "new" and using 'next' across the exec call, GDB segfaulted. Once that was fixed, there were a couple of other issues to clean up. Finally, I tried using 'next' across a call to exec after deleting all breakpoints. In this case the execed program runs to completion. In breakpoint.c:update_breakpoints_after_exec the comments make it clear that this is not expected to work. It seems like it might be possible to make such a thing work, but it's beyond the scope of what I'm working on now. So ultimately this patchset only implements the test and fixes the segfault. Patch 1/2: Implement gdb.base/foll-exec-2.exp to test follow-exec-mode. Patch 2/2: Fix native follow-exec-mode "new". Tested all on native x86_64 Linux. Thanks --Don